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: <aMqdzQcwvkjl5WNA@yury>
Date: Wed, 17 Sep 2025 07:38:53 -0400
From: Yury Norov <yury.norov@...il.com>
To: Gabriele Monaco <gmonaco@...hat.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, Sep 17, 2025 at 09:51:47AM +0200, Gabriele Monaco wrote:
> 
> 
> On Tue, 2025-09-16 at 13:27 +0200, Frederic Weisbecker wrote:
> > Le Mon, Sep 15, 2025 at 02:35:12PM -0400, Yury Norov a écrit :
> > > On Mon, Sep 15, 2025 at 05:02:45PM +0000, Gabriele Monaco wrote:
> > > > 2025-09-15T16:04:53Z Yury Norov <yury.norov@...il.com>:
> > > > > So why don't you pick the original patch instead?
> > > > 
> > > > In my opinion, the /juice/ of that patch was included with [1],
> > > > here I'm just adding part of it.
> > > > If you prefer I can pick that patch and adapt the commit message
> > > > to reflect only the part included here.
> > > > 
> > > > [1] -
> > > > https://lore.kernel.org/lkml/1706509267-17754-3-git-send-email-schakrabarti@linux.microsoft.com/
> > > 
> > > Yes please.
> 
> Alright, will use your commit in v13 while changing the macro name to
> CPUMASK_VAR_NULL as suggested.
> 
> > And can we rename CPUMASK_NULL to CPUMASK_VAR_NULL to avoid
> > accidents/confusion with real
> > cpumasks initializations?
> 
> Note that in the linked commit message, you have what I believe is an
> incorrect assumption:
> 
> > So define a CPUMASK_VAR_NULL macro, ... and effectively a no-op
> > when CPUMASK_OFFSTACK is disabled.
> 
> 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?