linux-kernel - Re: [PATCH v12 8/9] cpumask: Add initialiser CPUMASK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1d15af4ab9f8f63dafbf4810a76eb3d547217596.camel@redhat.com>
Date: Wed, 17 Sep 2025 14:08:06 +0200
From: Gabriele Monaco <gmonaco@...hat.com>
To: Yury Norov <yury.norov@...il.com>
Cc: linux-kernel@...r.kernel.org, Frederic Weisbecker <frederic@...nel.org>
Subject: Re: [PATCH v12 8/9] cpumask: Add initialiser CPUMASK_NULL to use
 cleanup helpers

On Wed, 2025-09-17 at 07:38 -0400, Yury Norov wrote:
> On Wed, Sep 17, 2025 at 09:51:47AM +0200, Gabriele Monaco wrote:
> > According to what I can understand from the standard, the C list
> > initialisation sets to the default value (e.g. 0) all elements not
> > present in the initialiser. Since in {} no element is present, {}
> > is not a no-op but it initialises the entire cpumask to 0.
> > 
> > Am I missing your original intent here?
> > It doesn't look like a big price to pay, but I'd still reword the
> > sentence to something like:
> > "and a valid struct initializer when CPUMASK_OFFSTACK is disabled."
> 
> The full quote is:
> 
>   So define a CPUMASK_NULL macro, which allows to init struct cpumask
>   pointer with NULL when CPUMASK_OFFSTACK is enabled, and effectively
>   a no-op when CPUMASK_OFFSTACK is disabled.
> 
> If you read the 'which allows' part, it makes more sense, isn't?

Alright, my bad for trimming the sentence, what I wanted to highlight
is that with !CPUMASK_OFFSTACK this CPUMASK_NULL becomes something like

  struct cpumask mask[1] = {};

which, to me, doesn't look like a no-op as the description suggests,
but an initialisation of the entire array.

Now I'm not sure if the compiler would be smart enough to optimise this
assignment out, but it doesn't look obvious to me.

Unless you were meaning the __free() becomes a no-op (which is true but
out of scope in this version of the patch), I would avoid mentioning
the no-op altogether.

Am I missing something and that initialisation is proven to be compiled
out?