All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yury Norov <yury.norov@gmail.com>
To: Gabriele Monaco <gmonaco@redhat.com>
Cc: linux-kernel@vger.kernel.org, Frederic Weisbecker <frederic@kernel.org>
Subject: Re: [PATCH v12 8/9] cpumask: Add initialiser CPUMASK_NULL to use cleanup helpers
Date: Wed, 17 Sep 2025 07:38:53 -0400	[thread overview]
Message-ID: <aMqdzQcwvkjl5WNA@yury> (raw)
In-Reply-To: <6aeda48661359eedd232c9bb0c337d93c36dae70.camel@redhat.com>

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@gmail.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?

  reply	other threads:[~2025-09-17 11:38 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-15 14:59 [PATCH v12 0/9] timers: Exclude isolated cpus from timer migration Gabriele Monaco
2025-09-15 14:59 ` [PATCH v12 1/9] timers/migration: Postpone online/offline callbacks registration to late initcall Gabriele Monaco
2025-09-15 14:59 ` [PATCH v12 2/9] timers: Rename tmigr 'online' bit to 'available' Gabriele Monaco
2025-09-15 14:59 ` [PATCH v12 3/9] timers: Add the available mask in timer migration Gabriele Monaco
2025-09-15 14:59 ` [PATCH v12 4/9] timers: Use scoped_guard when setting/clearing the tmigr available flag Gabriele Monaco
2025-09-15 14:59 ` [PATCH v12 5/9] cgroup/cpuset: Rename update_unbound_workqueue_cpumask() to update_exclusion_cpumasks() Gabriele Monaco
2025-09-15 14:59 ` [PATCH v12 6/9] sched/isolation: Force housekeeping if isolcpus and nohz_full don't leave any Gabriele Monaco
2025-09-15 14:59 ` [PATCH v12 7/9] cgroup/cpuset: Fail if isolated and nohz_full don't leave any housekeeping Gabriele Monaco
2025-09-15 20:43   ` Waiman Long
2025-09-16  8:31   ` Chen Ridong
2025-09-15 14:59 ` [PATCH v12 8/9] cpumask: Add initialiser CPUMASK_NULL to use cleanup helpers Gabriele Monaco
2025-09-15 16:04   ` Yury Norov
2025-09-15 17:02     ` Gabriele Monaco
2025-09-15 18:35       ` Yury Norov
2025-09-16 11:27         ` Frederic Weisbecker
2025-09-17  7:51           ` Gabriele Monaco
2025-09-17 11:38             ` Yury Norov [this message]
2025-09-17 12:08               ` Gabriele Monaco
2025-09-17 12:34                 ` Yury Norov
2025-09-19 14:58                   ` Yury Norov
2025-09-22 10:07                     ` Gabriele Monaco
2025-09-15 14:59 ` [PATCH v12 9/9] timers: Exclude isolated cpus from timer migration Gabriele Monaco
2025-09-15 20:51   ` John B. Wyatt IV
2025-09-16  5:29     ` Gabriele Monaco
2025-09-16 13:41   ` Frederic Weisbecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aMqdzQcwvkjl5WNA@yury \
    --to=yury.norov@gmail.com \
    --cc=frederic@kernel.org \
    --cc=gmonaco@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.