Re: [PATCH AUTOSEL 6.2 09/30] cpumask: fix incorrect cpumask scanning result checks

2023-03-19 Thread Linus Torvalds
On Sun, Mar 19, 2023 at 5:53 PM Sasha Levin wrote: > > [ Upstream commit 8ca09d5fa3549d142c2080a72a4c70ce389163cd ] These are technically real fixes, but they are really just "documented behavior" fixes, and don't actually matter unless you also have 596ff4a09b89 ("cpumask: re-introduce constant-

Re: [PATCH 3/5] scsi: lpfc: fix lpfc_cpu_affinity_check() if no further cpus set

2023-03-06 Thread Linus Torvalds
On Mon, Mar 6, 2023 at 8:07 AM Vernon Yang wrote: > > - if (new_cpu == nr_cpumask_bits) > + if (new_cpu >= nr_cpumask_bits) This all should use "nr_cpu_ids", not "nr_cpumask_bits". But I really suspect that it should all be rewritten to

Re: [PATCH 5/5] cpumask: fix comment of cpumask_xxx

2023-03-06 Thread Linus Torvalds
On Mon, Mar 6, 2023 at 10:13 AM Vernon Yang wrote: > > I also just see nr_cpumask_size exposed to outside, so... Yeah, it's not great. nr_cpumask_bits came out of the exact same "this is an internal value that we use for optimized cpumask accesses", and existed exactly because it *might* be the

Re: [PATCH 5/5] cpumask: fix comment of cpumask_xxx

2023-03-06 Thread Linus Torvalds
On Mon, Mar 6, 2023 at 9:47 AM Linus Torvalds wrote: > > The drivers/char/random.c code is very wrong, and does > > if (cpu == nr_cpumask_bits) > cpu = cpumask_first(&timer_cpus); > > which fails miserably exactly because it doe

Re: [PATCH 5/5] cpumask: fix comment of cpumask_xxx

2023-03-06 Thread Linus Torvalds
On Mon, Mar 6, 2023 at 9:29 AM Linus Torvalds wrote: > > The correct thing to do is always that > >* Returns >= nr_cpu_ids if no cpus set. > > because nr_cpu_ids is always the *smallest* of the access sizes. > > Of course, right now Guenter seems to be re

Re: [PATCH 5/5] cpumask: fix comment of cpumask_xxx

2023-03-06 Thread Linus Torvalds
On Mon, Mar 6, 2023 at 8:07 AM Vernon Yang wrote: > > After commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask > optimizations"), the cpumask size is divided into three different case, > so fix comment of cpumask_xxx correctly. No no. Those three cases are meant to be entirely in

Re: Random arrays on kernel stack..

2022-07-29 Thread Linus Torvalds
On Fri, Jul 29, 2022 at 10:12 AM Jason A. Donenfeld wrote: > > That's a good point. Though note that the current WARN_ON is also > dependent on DEBUG being set. Sure. And I think that's ok. > > (a) that constant should be a bit lower, so that we *can* use a 1kB > > stack frame warning on 64-bit

Random arrays on kernel stack..

2022-07-28 Thread Linus Torvalds
So I finally have an arm64 laptop that I'm playing with, and as a result building the kernel the way I usually do - with warnings as errors. And I get this: drivers/net/wireguard/allowedips.c: In function ‘root_remove_peer_lists’: drivers/net/wireguard/allowedips.c:77:1: error: the frame size