All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Yury Norov" <ynorov@nvidia.com>
Cc: linux-s390@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>
Subject: Re: [PATCH 7/7] cpu: make preferred CPU policy writers mutually exclusive
Date: Fri, 13 Nov 2026 19:25:20 +0000	[thread overview]
Message-ID: <sashiko-outbox-213549@kernel.org> (raw)
In-Reply-To: <20261113184257.621707-8-ynorov@nvidia.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] cpumask: preferred_cpumask_owned_by(NULL) returns true when
  unclaimed
--

commit 62477968d02f2aaa9afd9c7a8010ab357c98eb83
Author: Yury Norov <ynorov@nvidia.com>

cpu: make preferred CPU policy writers mutually exclusive

This commit adds helpers to claim, release, and check exclusive ownership of
the preferred CPU mask, and updates steal_governor to use them.

> diff --git a/lib/cpumask.c b/lib/cpumask.c
> index 2e16e19a2bdb6..ee710c3c89201 100644
> --- a/lib/cpumask.c
> +++ b/lib/cpumask.c
[ ... ]
> @@ -170,4 +172,64 @@ EXPORT_SYMBOL(cpumask_any_distribute);
>  #ifdef CONFIG_PREFERRED_CPU
>  DEFINE_MUTEX(cpu_preferred_mutex);
>  EXPORT_SYMBOL_GPL(cpu_preferred_mutex);
> +
> +static const void *preferred_cpumask_owner;
> +
> +/**
> + * preferred_cpumask_owned_by - test preferred CPU policy ownership
> + * @owner: policy identity
> + *
> + * Return: true if @owner holds the policy, false otherwise.
> + */
> +bool preferred_cpumask_owned_by(const void *owner)
> +{
> +	lockdep_assert_held(&cpu_preferred_mutex);
> +
> +	return preferred_cpumask_owner == owner;
> +}
> +EXPORT_SYMBOL_GPL(preferred_cpumask_owned_by);
> +
> +/**
> + * claim_preferred_cpumask - acquire exclusive preferred CPU policy ownership
> + * @owner: non-NULL identity that remains valid until ownership is released
> + *
> + * Call before starting policy work, normally on module init.
> + *
> + * Return: 0 on success, -EBUSY if claimed, or -EINVAL for a NULL identity.
> + */
> +int claim_preferred_cpumask(const void *owner)
> +{
> +	if (!owner)
> +		return -EINVAL;
> +
> +	guard(cpus_read_lock)();
> +	guard(mutex)(&cpu_preferred_mutex);
> +
> +	if (preferred_cpumask_owner)
> +		return -EBUSY;
> +
> +	preferred_cpumask_owner = owner;
> +	reset_preferred_cpumask();
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(claim_preferred_cpumask);
> +
> +/**
> + * release_preferred_cpumask - release exclusive preferred CPU policy ownership
> + * @owner: identity used to claim ownership
> + *
> + * Call after stopping policy work, normally on module exit.
> + */
> +void release_preferred_cpumask(const void *owner)
> +{
> +	guard(cpus_read_lock)();
> +	guard(mutex)(&cpu_preferred_mutex);
> +
> +	if (WARN_ON_ONCE(!owner || !preferred_cpumask_owned_by(owner)))
> +		return;

[Severity: Low]
Does preferred_cpumask_owned_by(NULL) return true when no policy driver owns
the preferred cpumask?  Checking owner && preferred_cpumask_owner == owner in
preferred_cpumask_owned_by() would also avoid needing the separate !owner
check in release_preferred_cpumask().

Also, the kernel-doc comments for preferred_cpumask_owned_by(),
claim_preferred_cpumask(), and release_preferred_cpumask() do not mention
their locking expectations (holding cpu_preferred_mutex for
preferred_cpumask_owned_by(), and acquiring cpus_read_lock() and
cpu_preferred_mutex internally in the claim/release helpers).

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261113184257.621707-2-ynorov@nvidia.com?part=7

      reply	other threads:[~2026-11-13 19:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-13 18:42 [PATCH 0/7] Harden preferred CPUs management Yury Norov
2026-11-13 18:42 ` [PATCH 1/7] cpumask: add reset_preferred_cpumask() helper Yury Norov
2026-11-13 18:55   ` sashiko-bot
2026-11-13 18:42 ` [PATCH 2/7] sched: restore preferred CPUs when hotplug removes the last one Yury Norov
2026-11-13 19:12   ` sashiko-bot
2026-11-13 18:42 ` [PATCH 3/7] virt: steal_governor: remove the minimum elapsed-time check Yury Norov
2026-11-13 18:56   ` sashiko-bot
2026-11-13 18:42 ` [PATCH 4/7] virt: steal_governor: serialize sampling against CPU hotplug Yury Norov
2026-11-13 19:03   ` sashiko-bot
2026-11-13 18:42 ` [PATCH 5/7] virt: steal_governor: warn on unexpected preferred mask states Yury Norov
2026-11-13 19:06   ` sashiko-bot
2026-11-13 18:42 ` [PATCH 6/7] virt: steal_governor: restart sampling immediately after CPU hotplug Yury Norov
2026-11-13 19:21   ` sashiko-bot
2026-11-13 18:42 ` [PATCH 7/7] cpu: make preferred CPU policy writers mutually exclusive Yury Norov
2026-11-13 19:25   ` sashiko-bot [this message]

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=sashiko-outbox-213549@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=ynorov@nvidia.com \
    /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.