All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Long Li" <longli@microsoft.com>
Cc: linux-hyperv@vger.kernel.org
Subject: Re: [PATCH net-next v2 04/13] net: mana: swap queue sets in mana_set_priv_flags
Date: Fri, 14 Aug 2026 05:05:16 +0000	[thread overview]
Message-ID: <20260814050517.220791F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260813050418.2906468-5-longli@microsoft.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The boolean flag `apc->channel_changing` is used as an open-coded, ad-hoc lock to protect vport reconfiguration against concurrent RDMA access, violating core kernel locking rules.
--

--- Patch [4]: [PATCH net-next v2 04/13] net: mana: swap queue sets in mana_set_priv_flags ---
commit 922132e276d163d3c58e43d88b85f6b85a403949
Author: Long Li <longli@microsoft.com>

net: mana: swap queue sets in mana_set_priv_flags

This commit modifies mana_set_priv_flags to pre-allocate and swap queue sets
instead of rebuilding them in place. This ensures that if the rebuild fails,
both the queues and the flag word remain untouched.

> diff --git a/drivers/net/ethernet/microsoft/mana/mana_ethtool.c b/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
> --- a/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
> +++ b/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
[ ... ]
> @@ -884,54 +888,53 @@ static int mana_set_priv_flags(struct net_device *ndev, u32 priv_flags)
[ ... ]
> -		/* Block RDMA from grabbing the vport during detach/attach */
> -		mutex_lock(&apc->vport_mutex);
> -		apc->channel_changing = true;
> +	/* Block RDMA from acquiring the vport for the duration. */
> +	mutex_lock(&apc->vport_mutex);
> +	if (apc->channel_changing) {
>  		mutex_unlock(&apc->vport_mutex);
> +		return -EBUSY;
> +	}
> +	apc->channel_changing = true;
> +	mutex_unlock(&apc->vport_mutex);

[Severity: High]
This is a pre-existing issue, but in mana_set_priv_flags, is using a boolean
flag like apc->channel_changing as an open-coded trylock safe?

It appears to be set on entry here and cleared on exit to protect vport
reconfiguration against concurrent RDMA access, rather than using a standard
synchronization primitive. Does this ad-hoc locking pattern evade lockdep
and risk races since it bypasses proper kernel locking rules?

[ ... ]
> clear_flag:
>  	mutex_lock(&apc->vport_mutex);
>  	apc->channel_changing = false;
>  	mutex_unlock(&apc->vport_mutex);
> -
>  	return err;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260813050418.2906468-1-longli@microsoft.com?part=4

  reply	other threads:[~2026-08-14  5:05 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-13  5:04 [PATCH net-next v2 00/13] net: mana: reconfigure by replacing the queue set Long Li
2026-08-13  5:04 ` [PATCH net-next v2 01/13] net: mana: add queue-set allocation and teardown helpers Long Li
2026-08-14  5:05   ` sashiko-bot
2026-08-13  5:04 ` [PATCH net-next v2 02/13] net: mana: swap queue sets in mana_set_channels Long Li
2026-08-14  5:05   ` sashiko-bot
2026-08-13  5:04 ` [PATCH net-next v2 03/13] net: mana: swap queue sets in mana_set_ringparam Long Li
2026-08-14  5:05   ` sashiko-bot
2026-08-13  5:04 ` [PATCH net-next v2 04/13] net: mana: swap queue sets in mana_set_priv_flags Long Li
2026-08-14  5:05   ` sashiko-bot [this message]
2026-08-13  5:04 ` [PATCH net-next v2 05/13] net: mana: swap queue sets in mana_change_mtu Long Li
2026-08-14  5:05   ` sashiko-bot
2026-08-13  5:04 ` [PATCH net-next v2 06/13] net: mana: swap queue sets in mana_xdp_set Long Li
2026-08-13  5:04 ` [PATCH net-next v2 07/13] net: mana: do not bail out of mana_detach on dealloc failure Long Li
2026-08-14  5:05   ` sashiko-bot
2026-08-13  5:04 ` [PATCH net-next v2 08/13] net: mana: keep per-queue statistics in the port context Long Li
2026-08-14  5:05   ` sashiko-bot
2026-08-13  5:04 ` [PATCH net-next v2 09/13] net: mana: share the EQ pool across a queue-set swap Long Li
2026-08-13  5:04 ` [PATCH net-next v2 10/13] net: mana: release EQs left idle by a channel-count reduction Long Li
2026-08-13  5:04 ` [PATCH net-next v2 11/13] net: mana: keep a user-configured RSS table across a queue rebuild Long Li
2026-08-14  5:05   ` sashiko-bot
2026-08-13  5:04 ` [PATCH net-next v2 12/13] net: mana: keep the surviving queues when the channel count is reduced Long Li
2026-08-13  5:04 ` [PATCH net-next v2 13/13] net: mana: keep the existing queues when the channel count is raised Long Li
  -- strict thread matches above, loose matches on Subject: below --
2026-08-11  6:34 [PATCH net-next v2 00/13] net: mana: reconfigure by replacing the queue set Long Li
2026-08-11  6:35 ` [PATCH net-next v2 04/13] net: mana: swap queue sets in mana_set_priv_flags Long Li

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=20260814050517.220791F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=longli@microsoft.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.