On Wed, 2024-09-18 at 14:17 +0800, Tiwei Bie wrote:
> The highmem support has been removed by commit a98a6d864d3b ("um:
> Remove broken highmem support"). The 2-level page table is sufficient
> on UML/i386 now. Remove the 3-level page table support on UML/i386
> which is still marked as experimenta
On Wed, 2024-09-04 at 15:50 +0200, Gabriele Monaco wrote:
> While building for KUnit with default settings, the build is generating
> the following compilation warnings.
>
> ```
> $ make ARCH=um O=.kunit --jobs=16
> ../lib/iomap.c:156:5: warning: no previous prototype for
> ‘ioread64_lo_hi’ [-Wmis
On Wed, 2024-09-04 at 15:50 +0200, Gabriele Monaco wrote:
> While building for KUnit with default settings, the build is generating
> the following compilation warnings.
>
> ```
> $ make ARCH=um O=.kunit --jobs=16
> ../lib/iomap.c:156:5: warning: no previous prototype for
> ‘ioread64_lo_hi’ [-Wmis
On Tue, 2024-09-03 at 18:14 +0100, Jiaxun Yang wrote:
>
> --- a/arch/um/Kconfig
> +++ b/arch/um/Kconfig
> @@ -32,6 +32,7 @@ config UML
> select TTY # Needed for line.c
> select HAVE_ARCH_VMAP_STACK
> select HAVE_RUST
> + select HAVE_GENERATE_RUST_TARGET if X86_32 || X86_64
>
On Tue, 2024-09-03 at 18:14 +0100, Jiaxun Yang wrote:
>
> --- a/arch/um/Kconfig
> +++ b/arch/um/Kconfig
> @@ -32,6 +32,7 @@ config UML
> select TTY # Needed for line.c
> select HAVE_ARCH_VMAP_STACK
> select HAVE_RUST
> + select HAVE_GENERATE_RUST_TARGET if X86_32 || X86_64
>
Package: cryptsetup-initramfs
Version: 2:2.7.4-1
Severity: wishlist
Dear Maintainer,
Since I have four devices with the same passphrase (they end
up building a btrfs array, so they're all needed), it'd be
nice to (try) using the passphrase for the first, so I don't
have to enter it four times.
S
On Mon, 2024-08-19 at 11:46 -0700, Maciej Żenczykowski wrote:
> On Mon, Aug 19, 2024 at 5:23 AM Johannes Berg
> wrote:
> >
> > On Tue, 2024-08-13 at 16:47 -0700, Maciej Żenczykowski wrote:
> > > Without this patch:
> > > #!/usr/bin/python3
>
From: Johannes Berg
The schedule() call there really never did anything at
least since the introduction of the EEVDF scheduler,
but now I found a case where we permanently hang in a
loop of -ERESTARTNOINTR (due to locking.) Work around
it by making any syscalls with error return take time
(and
On Tue, 2024-08-06 at 12:08 -0600, Gustavo A. R. Silva wrote:
>
> +++ b/include/net/ieee80211_radiotap.h
> @@ -24,31 +24,36 @@
> * struct ieee80211_radiotap_header - base radiotap header
> */
> struct ieee80211_radiotap_header {
> - /**
> - * @it_version: radiotap version, always 0
>
Hmm.
On Tue, 2024-07-16 at 20:40 +0300, Dmitry Antipov wrote:
> diff --git a/net/wireless/sme.c b/net/wireless/sme.c
> index a8ad55f11133..f5da45331847 100644
> --- a/net/wireless/sme.c
> +++ b/net/wireless/sme.c
> @@ -77,12 +77,16 @@ static int cfg80211_conn_scan(struct wireless_dev *wdev)
>
Hi Steven,
> I finally got around to testing your patches.
>
> I did the following:
>
> # cat /sys/kernel/tracing/events/*/*/format
>
> and hit this:
>
> BUG: unable to handle page fault for address: 8e6333d0
Ugh. That's ... unfortunate.
I couldn't reproduce this so far, do you happ
On Tue, 2024-08-13 at 16:47 -0700, Maciej Żenczykowski wrote:
> Without this patch:
> #!/usr/bin/python3
> import ctypes
> import os
> personality = ctypes.CDLL(None).personality
> personality.restype = ctypes.c_int
> personality.argtypes = [ctypes.c_ulong]
> PER_LINUX32=8
> persona
From: Johannes Berg
There's no such symbol and we currently don't have any of the
mechanisms to make boot-time selection cheap enough, so we can't
have HAVE_PREEMPT_DYNAMIC_CALL or HAVE_PREEMPT_DYNAMIC_KEY.
Remove the select statement.
Reported-by: Lukas Bulwahn
Fixes: cd
On Thu, 2024-07-04 at 21:16 +0100, Anton Ivanov wrote:
> > > - qi->queue_depth = 0;
> > > + wmb(); /* Ensure that RX processing elsewhere sees the changes */
> > > + atomic_set(&qi->queue_depth, 0);
> > > }
> > I don't understand this.
> >
> > prep_queue_for_rx() is called by vector_mmsg_rx(),
On Thu, 2024-07-04 at 18:27 +0200, Benjamin Berg wrote:
> From: Benjamin Berg
>
> With the change to use execve() we can now safely clear the memory up to
> STUB_START as rseq will not be trying to use memory in that region. Also,
> on 64 bit the previous changes should mean that there is no usab
On Thu, 2024-07-04 at 18:27 +0200, Benjamin Berg wrote:
>
> + /* set a nice name */
> + stub_syscall2(__NR_prctl, PR_SET_NAME, (unsigned long)"uml-userspace");
Is that even needed when you're passing it as argv[0] in execve()? But
whatever, it's fine, just wondering.
> + /* setup sig
On Thu, 2024-07-04 at 13:22 +0100, anton.iva...@cambridgegreys.com
wrote:
>
> @@ -675,11 +657,20 @@ static void prep_queue_for_rx(struct vector_queue *qi)
> struct vector_private *vp = netdev_priv(qi->dev);
> struct mmsghdr *mmsg_vector = qi->mmsg_vector;
> void **skbuff_vector =
From: Johannes Berg
When generalizing this, I was in the mindset of this being
"userspace" code, but even there we should not use variable
arrays as the kernel is moving away from allowing that.
Simply reserve (but not use) enough space for the maximum
two descriptors we might nee
On Thu, 2024-07-04 at 11:55 +0200, Johannes Berg wrote:
> On Thu, 2024-07-04 at 10:52 +0100, Anton Ivanov wrote:
> > >
> > > There is an extra issue there - stats. I need to double-check the locking
> > > when
> > > they are being fetched.
> >
>
On Thu, 2024-07-04 at 10:52 +0100, Anton Ivanov wrote:
> >
> > There is an extra issue there - stats. I need to double-check the locking
> > when
> > they are being fetched.
>
> Same story - these need atomics. Otherwise we can potentially get the same
> ABBA
> lock issue when they are being fe
On Thu, 2024-07-04 at 10:45 +0100, Anton Ivanov wrote:
> > (it probably also never even executes twice unless you actually have SMP
> > or preemption?)
>
> It does. If half of the vector is at the end of the array which is used to
> imitate a ring buffer and the other half is at the beginning. Qu
On Thu, 2024-07-04 at 07:58 +0100, Anton Ivanov wrote:
>
> > +__initcall(register_power_off);
>
> Anton Ivanov
Heh, I thought I saw an Acked-by from you but then patchwork didn't seem
to pick it up, I guess I'll treat it as one anyway? :)
johannes
Hi Anton,
Thanks for taking a look! Also thanks for the other explanation.
On Thu, 2024-07-04 at 08:21 +0100, anton.iva...@cambridgegreys.com
wrote:
> From: Anton Ivanov
>
> UML vector drivers use ring buffer structures which map
> preallocated skbs onto mmsg vectors for use with sendmmsg
> and
From: Johannes Berg
If open fails, we have already set vp->opened, but it's
not reset so that any further attempts will just return
-ENXIO. Reset vp->opened even if close has nothing to do.
This helps e.g. with slirp4netns handling only a single
connection, you can then restart it a
From: Johannes Berg
This lock is useless, all the places that are using
it for some locking will already hold the RTNL. Just
remove it.
Signed-off-by: Johannes Berg
---
v2: remove unused flags variables
---
arch/um/drivers/vector_kern.c | 16 +---
arch/um/drivers/vector_kern.h
From: Johannes Berg
This lock is useless, all the places that are using
it for some locking will already hold the RTNL. Just
remove it.
Signed-off-by: Johannes Berg
---
arch/um/drivers/vector_kern.c | 14 +-
arch/um/drivers/vector_kern.h | 1 -
2 files changed, 1 insertion(+), 14
Lockdep reports a spinlock ordering problem: sometimes we take head_lock
first, sometimes tail_lock, so there's a classic ABBA deadlock possible.
It may not happen now because of UML being single-CPU and all that, but
perhaps with preempt?
Report:
=
From: Johannes Berg
Otherwise we always get
reboot: Power off not available: System halted instead
which is really quite pointless.
Signed-off-by: Johannes Berg
---
arch/um/kernel/reboot.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/um/kernel/reboot.c b/arch
From: Johannes Berg
The pointer isn't initialized by callers, but I have
encountered cases where it's still printed; initialize
it in all possible cases in setup_one_line().
Signed-off-by: Johannes Berg
---
arch/um/drivers/line.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
From: Johannes Berg
We just removed the driver, but forgot the row in the
documentation table mentioning it. Remove that.
Signed-off-by: Johannes Berg
---
Documentation/virt/uml/user_mode_linux_howto_v2.rst | 2 --
1 file changed, 2 deletions(-)
diff --git a/Documentation/virt/uml
On Wed, 2024-07-03 at 11:45 +0200, Johannes Berg wrote:
> On Fri, 2024-05-24 at 23:37 +0200, benja...@sipsolutions.net wrote:
> > From: Benjamin Berg
> >
> > There should be no need for this.
>
> "should" ;-)
>
> This breaks things if glibc enables r
On Wed, 2024-06-26 at 15:53 +0200, Benjamin Berg wrote:
>
> +choice
> + prompt "Pagetable levels"
> + default 2_LEVEL_PGTABLES if !64BIT
> + default 4_LEVEL_PGTABLES if 64BIT
> +
> + config 2_LEVEL_PGTABLES
> + bool "Two-level pagetables" if !64BIT
> + depen
From: Johannes Berg
When signals are hard-blocked in order to do time-travel
socket processing, we set signals_blocked and then handle
SIGIO signals by setting the SIGIO bit in signals_pending.
When unblocking, we first set signals_blocked to 0, and
then handle all pending signals. We have to
From: Johannes Berg
This function is unused and unneeded, remove it.
Signed-off-by: Johannes Berg
---
arch/um/kernel/time.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/um/kernel/time.c b/arch/um/kernel/time.c
index d44eaad53d9d..47b9f5e63566 100644
--- a/arch/um/kernel
On Wed, 2024-07-03 at 12:08 +0200, Benjamin Berg wrote:
> On Wed, 2024-07-03 at 11:45 +0200, Johannes Berg wrote:
> > On Fri, 2024-05-24 at 23:37 +0200, benja...@sipsolutions.net wrote:
> > > From: Benjamin Berg
> > >
> > > There should be no need for thi
On Wed, 2024-07-03 at 10:34 +0100, Andrew C Aitchison via Exim-dev
wrote:
>
> I have gcc versions 7-14 on Ubuntu, and none of them give that warning,
> even with -Wall -Wextra
You can get it with -Wpedantic. However, it's technically not legal in C
(until C23, it seems, TIL!), and clang will com
On Fri, 2024-05-24 at 23:37 +0200, benja...@sipsolutions.net wrote:
> From: Benjamin Berg
>
> There should be no need for this.
"should" ;-)
This breaks things if glibc enables rseq. That might even be already
broken in the sense that it might corrupt memory that's put at the same
place the rse
From: Johannes Berg
For the upcoming shared-memory time-travel external
optimisations, we need to be able to mmap/mremap
(and on error munmap). Add the necessary OS calls.
Signed-off-by: Johannes Berg
---
arch/um/include/shared/os.h | 2 ++
arch/um/os-Linux/file.c | 23
compromise, there's no
need to have any core changes and it solves the main use
case we have for it.
Signed-off-by: Mordechay Goodstein
Signed-off-by: Johannes Berg
---
arch/um/include/shared/timetravel.h | 9 +
arch/um/kernel/time.c | 59 +
a
From: Johannes Berg
Change os_rcv_fd() to os_rcv_fd_msg() that can more generally
receive any number of FDs in any kind of message.
Signed-off-by: Johannes Berg
---
v3: fix print format
---
arch/um/drivers/port_kern.c | 14 +
arch/um/drivers/xterm.c | 2 +-
arch/um/drivers
From: Johannes Berg
With external time travel, a LOT of message can end up
being exchanged on the socket, taking a significant
amount of time just to do that.
Add a new shared memory optimisation to that, where a
number of changes are made:
- the controller sends a client ID and a shared
On Tue, 2024-07-02 at 10:25 +0200, Johannes Berg wrote:
> From: Anton Ivanov
>
> Since userspace state is saved in the MM process, kernel using
> FPU still doesn't really need to do anything, so this really
> is as simple as enabling preemption. The irq critical sectio
On Tue, 2024-07-02 at 12:18 +0200, Johannes Berg wrote:
>
> We have 40 patches in patchwork now, including the 7 64-bit address
> space ones from Benjamin where I think some rework is needed. I've
> rebased/applied the other 33, I've just pushed that to the 'pe
On Tue, 2024-07-02 at 11:07 +0100, Anton Ivanov wrote:
>
>
> Is that all we have left?
I think so, yes.
> I lost track of your mm patches and they do not apply cleanly to master at
> present.
Mine actually mostly went away, in favour of Benjamin's, but his also
didn't apply cleanly due to th
vanov
[vastly simplify, fix x86/um Makefile, rewrite commit message]
Signed-off-by: Johannes Berg
---
v10:
- rebase on top of various other patchsets, including Benjamin's
page table updates:
https://patchwork.ozlabs.org/project/linux-um/list/?series=408104
- fix x86/um Makefile
- remov
On Tue, 2024-07-02 at 09:24 +0200, Johannes Berg wrote:
> From: Johannes Berg
>
> dev_t is a kernel type and may have different definitions
> in kernel and userspace. On 32-bit x86 this currently makes
> the stat structure being 4 bytes longer in the user code,
> causin
From: Johannes Berg
dev_t is a kernel type and may have different definitions
in kernel and userspace. On 32-bit x86 this currently makes
the stat structure being 4 bytes longer in the user code,
causing stack corruption.
However, this is (potentially) not the only problem, since
dev_t is a
From: Johannes Berg
dev_t is a kernel type and may have different definitions
in kernel and userspace. On 32-bit x86 this currently makes
the stat structure being 4 bytes longer in the user code,
causing stack corruption. Just use 'unsigned int' so the
same size is used.
Signed-off-by
compromise, there's no
need to have any core changes and it solves the main use
case we have for it.
Signed-off-by: Mordechay Goodstein
Signed-off-by: Johannes Berg
---
arch/um/include/shared/timetravel.h | 9 +
arch/um/kernel/time.c | 59 +
a
From: Johannes Berg
With external time travel, a LOT of message can end up
being exchanged on the socket, taking a significant
amount of time just to do that.
Add a new shared memory optimisation to that, where a
number of changes are made:
- the controller sends a client ID and a shared
From: Johannes Berg
For the upcoming shared-memory time-travel external
optimisations, we need to be able to mmap/mremap
(and on error munmap). Add the necessary OS calls.
Signed-off-by: Johannes Berg
---
arch/um/include/shared/os.h | 2 ++
arch/um/os-Linux/file.c | 23
From: Johannes Berg
Change os_rcv_fd() to os_rcv_fd_msg() that can more generally
receive any number of FDs in any kind of message.
Signed-off-by: Johannes Berg
---
v3: fix print format
---
arch/um/drivers/port_kern.c | 14 +
arch/um/drivers/xterm.c | 2 +-
arch/um/drivers
compromise, there's no
need to have any core changes and it solves the main use
case we have for it.
Signed-off-by: Mordechay Goodstein
Signed-off-by: Johannes Berg
---
arch/um/include/shared/timetravel.h | 9 +
arch/um/kernel/time.c | 59 +
a
From: Johannes Berg
With external time travel, a LOT of message can end up
being exchanged on the socket, taking a significant
amount of time just to do that.
Add a new shared memory optimisation to that, where a
number of changes are made:
- the controller sends a client ID and a shared
From: Johannes Berg
For the upcoming shared-memory time-travel external
optimisations, we need to be able to mmap/mremap
(and on error munmap). Add the necessary OS calls.
Signed-off-by: Johannes Berg
--
v2: drop os_munmap()
---
arch/um/include/shared/os.h | 2 ++
arch/um/os-Linux/file.c
From: Johannes Berg
Change os_rcv_fd() to os_rcv_fd_msg() that can more generally
receive any number of FDs in any kind of message.
Signed-off-by: Johannes Berg
---
arch/um/drivers/port_kern.c | 14 +
arch/um/drivers/xterm.c | 2 +-
arch/um/drivers/xterm_kern.c | 13
From: Johannes Berg
When signals are hard-blocked in order to do time-travel
socket processing, we set signals_blocked and then handle
SIGIO signals by setting the SIGIO bit in signals_pending.
When unblocking, we first set signals_blocked to 0, and
then handle all pending signals. We have to
On Wed, 2024-06-26 at 15:53 +0200, Benjamin Berg wrote:
>
> +static int __init init_stub_exec_fd(void)
> +{
> + size_t len = 0;
> + int res;
> + char tmpfile[] = "/tmp/uml-userspace-XX";
That seems awkward, perhaps it should use make_tempfile() from mem.c?
> + stub_e
From: Johannes Berg
We can select ARCH_HAS_UBSAN, it works just fine. It had been
enabled and we even used it, but then commit 890a64810d59
("ubsan: Restore dependency on ARCH_HAS_UBSAN") (correctly)
disabled it again, enable ARCH_HAS_UBSAN to get it.
Signed-off-by: Johannes Berg
--
On Mon, 2024-07-01 at 19:55 +0100, Anton Ivanov wrote:
> >
> As Benjamin pointed out we no longer need this, so we can junk this
> patch at this point. If there will be any need to save/restore FPU in
> kernel context, I will revisit it.
I think we still want/need the parts with the preempt_dis
On Mon, 2024-07-01 at 17:56 +0200, Johannes Berg wrote:
> Hmm. I also see a ton of this:
>
> BUG: sleeping function called from invalid context at
> kernel/locking/rwsem.c:1525
> in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 538, name:
> chan-switch.sh
> preempt_
Hmm. I also see a ton of this:
BUG: sleeping function called from invalid context at
kernel/locking/rwsem.c:1525
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 538, name: chan-switch.sh
preempt_count: 2, expected: 0
RCU nest depth: 0, expected: 0
no locks held by chan-switch.sh/538.
irq e
> arch/um/Kconfig | 2 +-
> arch/um/include/asm/fpu/api.h | 9 ++--
> arch/um/include/asm/thread_info.h | 4 +-
> arch/um/kernel/Makefile | 4 ++
> arch/um/kernel/fpu.c | 71 +++
> arch/um/kernel/irq.c | 2
> will this one get backported also?
Why? It's not even a bug.
johannes
On Fri, 2024-06-21 at 10:04 +0200, Koen Vandeputte wrote:
>
> memcpy: detected field-spanning write (size 64) of single field
> "tim->virtual_map" at
> ../ath10k-ct-smallbuffers/ath10k-ct-2024.03.02~eb3f488a/ath10k-6.7/wmi.c:4043
> (size 1)
>
Check out commit 2ae5c9248e06 ("wifi: mac80211: Use f
From: Johannes Berg
Now that we have drop_reason_lookup(), we can just use it for
drop_monitor as well, rather than exporting the list itself.
Signed-off-by: Johannes Berg
---
v3:
- look up SKB_DROP_REASON_NOT_SPECIFIED if initial lookup
returns NULL, to preserve previous behaviour
From: Johannes Berg
The __print_symbolic() could only ever print the core
drop reasons, since that's the way the infrastructure
works. Now that we have __print_sym() with all the
advantages mentioned in that commit, convert to that
and get all the drop reasons from all subsystems. As
we al
From: Johannes Berg
The way __print_symbolic() works is limited and inefficient
in multiple ways:
- you can only use it with a static list of symbols, but
e.g. the SKB dropreasons are now a dynamic list
- it builds the list in memory _three_ times, so it takes
a lot of memory:
- The
From: Johannes Berg
Use the new __print_sym() in the timer tracing, just to show
how to convert something. This adds ~80 bytes of .text for a
saving of ~1.5K of data in my builds.
Note the format changes from
print fmt: "success=%d dependency=%s", REC->success,
__print
v2 was:
- rebased on 6.9-rc1
- always search for __print_sym() and get rid of the DYNPRINT flag
and associated code; I think ideally we'll just remove the older
__print_symbolic() entirely
- use ':' as the separator instead of "//" since that makes searching
for it much easier and it's
On Wed, 2024-06-05 at 11:22 -0400, Kenton Groombridge wrote:
> Co-authored-by: Kees Cook
> Signed-off-by: Kenton Groombridge
>
Wait ... I don't know what Kees did here, but seems then he should sign-
off too.
Kees?
johannes
From: Johannes Berg
The __print_symbolic() could only ever print the core
drop reasons, since that's the way the infrastructure
works. Now that we have __print_sym() with all the
advantages mentioned in that commit, convert to that
and get all the drop reasons from all subsystems. As
we al
From: Johannes Berg
Now that we have drop_reason_lookup(), we can just use it for
drop_monitor as well, rather than exporting the list itself.
Signed-off-by: Johannes Berg
---
v3:
- look up SKB_DROP_REASON_NOT_SPECIFIED if initial lookup
returns NULL, to preserve previous behaviour
From: Johannes Berg
The way __print_symbolic() works is limited and inefficient
in multiple ways:
- you can only use it with a static list of symbols, but
e.g. the SKB dropreasons are now a dynamic list
- it builds the list in memory _three_ times, so it takes
a lot of memory:
- The
From: Johannes Berg
Use the new __print_sym() in the timer tracing, just to show
how to convert something. This adds ~80 bytes of .text for a
saving of ~1.5K of data in my builds.
Note the format changes from
print fmt: "success=%d dependency=%s", REC->success,
__print
Before I forget again ...
v2 was:
- rebased on 6.9-rc1
- always search for __print_sym() and get rid of the DYNPRINT flag
and associated code; I think ideally we'll just remove the older
__print_symbolic() entirely
- use ':' as the separator instead of "//" since that makes searching
f
From: Johannes Berg
Now that we have drop_reason_lookup(), we can just use it for
drop_monitor as well, rather than exporting the list itself.
Signed-off-by: Johannes Berg
---
v3:
- look up SKB_DROP_REASON_NOT_SPECIFIED if initial lookup
returns NULL, to preserve previous behaviour
From: Johannes Berg
The way __print_symbolic() works is limited and inefficient
in multiple ways:
- you can only use it with a static list of symbols, but
e.g. the SKB dropreasons are now a dynamic list
- it builds the list in memory _three_ times, so it takes
a lot of memory:
- The
From: Johannes Berg
The __print_symbolic() could only ever print the core
drop reasons, since that's the way the infrastructure
works. Now that we have __print_sym() with all the
advantages mentioned in that commit, convert to that
and get all the drop reasons from all subsystems. As
we al
Completely forgot about this again ... here's another respin.
v2 was:
- rebased on 6.9-rc1
- always search for __print_sym() and get rid of the DYNPRINT flag
and associated code; I think ideally we'll just remove the older
__print_symbolic() entirely
- use ':' as the separator instead of
From: Johannes Berg
Use the new __print_sym() in the timer tracing, just to show
how to convert something. This adds ~80 bytes of .text for a
saving of ~1.5K of data in my builds.
Note the format changes from
print fmt: "success=%d dependency=%s", REC->success,
__print
On Wed, 2024-06-05 at 19:59 +0200, Ard Biesheuvel wrote:
>
> > > -ifdef CONFIG_X86_64
> > > +ifneq ($(or $(CONFIG_X86_64),$(CONFIG_X86_32)),)
> >
> > These configurations are mutually exclusive, so would it look more
> > readable to have it be:
> >
> >
> > ifeq ($(CONFIG_X86_32)$(CONFIG_X86_64)
On Tue, 2024-06-04 at 14:53 -0400, Kenton Groombridge wrote:
> On 24/05/29 04:54PM, Johannes Berg wrote:
> > On Fri, 2024-05-17 at 10:54 -0400, Kenton Groombridge wrote:
> > > req->n_channels must be set before req->channels[] can be used.
> > >
> >
> &
On Fri, 2024-05-17 at 10:54 -0400, Kenton Groombridge wrote:
> req->n_channels must be set before req->channels[] can be used.
>
I don't know why, but this patch breaks a number of hwsim test cases.
https://w1.fi/cgit/hostap/tree/tests/hwsim/
johannes
On Tue, 2024-05-28 at 18:16 +0800, Tiwei Bie wrote:
> On 5/28/24 4:54 PM, benja...@sipsolutions.net wrote:
> > From: Benjamin Berg
> >
> > Newer glibc versions are enabling rseq support by default. This remains
> > enabled in the cloned child process, potentially causing the host kernel
> > to wr
On Fri, 2024-05-17 at 21:45 +0100, Simon Horman wrote:
>
> FWWIW, it seems unfortunate to me that the __counted_by field (n_channels)
> is set some distance away from the allocation of the flex-array (channels)
> whose bounds it checks. It seems it would be pretty easy for a bug in the
> code bein
On Sat, 2024-05-18 at 17:50 +0200, Remi Pommarel wrote:
> Wiphy should be locked before calling rdev_get_station() (see lockdep
> assert in ieee80211_get_station()).
>
> This fixes the following kernel NULL dereference:
How do you get a NULL pointer dereference from a locking issue? Was
something
On Mon, 2024-05-20 at 17:08 +0200, Stanislaw Gruszka wrote:
> >
> > I don't think this is right, now the raw comes after
> > DEF_CMD_PAYLOAD_SIZE? You want it to be a union with payload, I'd think.
>
> Not sure if I understand. I think we have union with payload with
> the patch. The structure l
> +++ b/drivers/net/wireless/intel/iwlegacy/commands.h
> @@ -201,9 +201,6 @@ struct il_cmd_header {
>* 15 unsolicited RX or uCode-originated notification
>*/
> __le16 sequence;
> -
> - /* command or response/notification data follows immediately */
> - u8 d
On Thu, 2024-05-16 at 20:23 -0400, Kenton Groombridge wrote:
> req->n_channels must be set before req->channels[] can be used.
> Additionally, memory addresses after the "channels" array need to be
> calculated from the allocation base ("request") instead of the first
> "out of bounds" index of "ch
On Mon, 2024-05-13 at 14:58 +0200, Roberto Sassu wrote:
> On Mon, 2024-05-13 at 14:52 +0200, Johannes Berg wrote:
> > On Mon, 2024-05-13 at 14:42 +0200, Roberto Sassu wrote:
> > > On Mon, 2024-05-13 at 14:29 +0200, Johannes Berg wrote:
> > > > On Mon, 2024-05-13 at 14
On Mon, 2024-05-13 at 14:58 +0200, Roberto Sassu wrote:
> On Mon, 2024-05-13 at 14:52 +0200, Johannes Berg wrote:
> > On Mon, 2024-05-13 at 14:42 +0200, Roberto Sassu wrote:
> > > On Mon, 2024-05-13 at 14:29 +0200, Johannes Berg wrote:
> > > > On Mon, 2024-05-13 at 14
On Mon, 2024-05-13 at 14:42 +0200, Roberto Sassu wrote:
> On Mon, 2024-05-13 at 14:29 +0200, Johannes Berg wrote:
> > On Mon, 2024-05-13 at 14:27 +0200, Roberto Sassu wrote:
> > > From: Roberto Sassu
> > >
> > > Disable UBSAN sanitization o
On Mon, 2024-05-13 at 14:42 +0200, Roberto Sassu wrote:
> On Mon, 2024-05-13 at 14:29 +0200, Johannes Berg wrote:
> > On Mon, 2024-05-13 at 14:27 +0200, Roberto Sassu wrote:
> > > From: Roberto Sassu
> > >
> > > Disable UBSAN sanitization o
On Mon, 2024-05-13 at 14:27 +0200, Roberto Sassu wrote:
> From: Roberto Sassu
>
> Disable UBSAN sanitization on UML, since UML does not support it.
>
Luckily, that isn't actually true, nor does it actually do this at all.
Please fix the commit message.
johannes
On Mon, 2024-05-13 at 14:27 +0200, Roberto Sassu wrote:
> From: Roberto Sassu
>
> Disable UBSAN sanitization on UML, since UML does not support it.
>
Luckily, that isn't actually true, nor does it actually do this at all.
Please fix the commit message.
johannes
On Thu, 2024-04-25 at 11:13 -0700, Nathan Chancellor wrote:
> On Wed, Apr 24, 2024 at 03:01:01PM -0700, Kees Cook wrote:
> > Before request->channels[] can be used, request->n_channels must be set.
> > Additionally, address calculations for memory after the "channels" array
> > need to be calculate
On Wed, 2024-04-24 at 15:01 -0700, Kees Cook wrote:
> Before request->channels[] can be used, request->n_channels must be set.
> Additionally, address calculations for memory after the "channels" array
> need to be calculated from the allocation base ("request") rather than
> via the first "out of
On Tue, 2024-04-23 at 20:09 +0800, Tiwei Bie wrote:
> On 4/23/24 7:30 PM, Johannes Berg wrote:
> > On Tue, 2024-04-23 at 19:24 +0800, Tiwei Bie wrote:
> > >
> > > $(USER_OBJS:.o=.%): \
> > > - c_flags = -Wp,-MD,$(depfile) $(USER_CFLAGS) -include
> >
On Tue, 2024-04-23 at 19:24 +0800, Tiwei Bie wrote:
>
> $(USER_OBJS:.o=.%): \
> - c_flags = -Wp,-MD,$(depfile) $(USER_CFLAGS) -include
> $(srctree)/include/linux/kern_levels.h -include user.h
> $(CFLAGS_$(basetarget).o)
> + c_flags = -Wp,-MD,$(depfile) $(USER_CFLAGS) -include
> $(srctr
1 - 100 of 3806 matches
Mail list logo
