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: <6aeda48661359eedd232c9bb0c337d93c36dae70.camel@redhat.com>
Date: Wed, 17 Sep 2025 09:51:47 +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 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."

Thanks,
Gabriele