[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=witXXeQuP9fgs4dDL2Ex0meXQiHJs+3JEfNdaPwngMVEg@mail.gmail.com>
Date: Mon, 6 Mar 2023 09:47:34 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Vernon Yang <vernon2gm@...il.com>
Cc: tytso@....edu, Jason@...c4.com, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
jejb@...ux.ibm.com, martin.petersen@...cle.com,
yury.norov@...il.com, andriy.shevchenko@...ux.intel.com,
linux@...musvillemoes.dk, james.smart@...adcom.com,
dick.kennedy@...adcom.com, linux-kernel@...r.kernel.org,
wireguard@...ts.zx2c4.com, netdev@...r.kernel.org,
linux-scsi@...r.kernel.org
Subject: Re: [PATCH 5/5] cpumask: fix comment of cpumask_xxx
On Mon, Mar 6, 2023 at 9:29 AM Linus Torvalds
<torvalds@...ux-foundation.org> 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 reporting a problem with that
> optimization, so unless I figure out what is going on I'll just need
> to revert it anyway.
Ahh. And the reason is exactly that people do *not* follow that
"Returns >= nr_cpu_ids" rule.
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 doesn't use ">=".
Oh well.
I'll have to look for more of this pattern, but basically all those
"xyz_cpumask_bits" things were supposed to always be just internal to
that header file implementation, which is *exactly* why you have to
check the result for ">= nr_cpu_ids".
Linus
Powered by blists - more mailing lists