[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjit4tstX3q4DkiYLTD6zet_7j=CfjbvTMqtnOwmY7jzA@mail.gmail.com>
Date: Sat, 4 Mar 2023 11:19:54 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Yury Norov <yury.norov@...il.com>
Cc: Mateusz Guzik <mjguzik@...il.com>,
Alexander Potapenko <glider@...gle.com>,
Al Viro <viro@...iv.linux.org.uk>,
Kees Cook <keescook@...omium.org>,
Eric Biggers <ebiggers@...gle.com>,
Christian Brauner <brauner@...nel.org>, serge@...lyn.com,
paul@...l-moore.com, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH v3 2/2] vfs: avoid duplicating creds in faccessat if possible
On Fri, Mar 3, 2023 at 9:51 PM Yury Norov <yury.norov@...il.com> wrote:
>
> And the following code will be broken:
>
> cpumask_t m1, m2;
>
> cpumask_setall(m1); // m1 is ffff ffff ffff ffff because it uses
> // compile-time optimized nr_cpumask_bits
>
> for_each_cpu(cpu, m1) // 32 iterations because it relied on nr_cpu_ids
> cpumask_set_cpu(cpu, m2); // m2 is ffff ffff XXXX XXXX
So honestly, it looks like you picked an example of something very
unusual to then make everything else slower.
Rather than commit aa47a7c215e7, we should just have fixed 'setall()'
and 'for_each_cpu()' to use nr_cpu_ids, and then the rest would
continue to use nr_cpumask_bits.
That particular code sequence is arguably broken to begin with.
setall() should really only be used as a mask, most definitely not as
some kind of "all possible cpus".
The latter is "cpu_possible_mask", which is very different indeed (and
often what you want is "cpu_online_mask")
But I'd certainly be ok with using nr_cpu_ids for setall, partly
exactly because it's so rare. It would probably be better to remove it
entirely, but whatever.
Linus
Powered by blists - more mailing lists