Re: [PATCH net-next v7 07/13] net: mana: swap queue sets in mana_change_mtu

[netdev-bot+sashiko@kernel.org]

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

Critical: 0 · High: 0 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] mana_change_mtu() adds a new use of the boolean
  channel_changing as an ad-hoc lock.

--

net: mana: swap queue sets in mana_change_mtu

With this patch, mana_change_mtu() builds a full replacement queue set
sized for the new MTU and swaps it in. It no longer does a detach and
attach. The MTU is carried in the queue set as configured_mtu, and
ndev->mtu is published only after RSS configuration succeeds.

> diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
> index c80a06ffbe508..c1ff4d9b8d45f 100644
> --- a/drivers/net/ethernet/microsoft/mana/mana_en.c
> +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
> @@ -956,32 +956,52 @@ int mana_pre_alloc_rxbufs(struct mana_port_context *mpc, int new_mtu, int num_qu
>  static int mana_change_mtu(struct net_device *ndev, int new_mtu)
>  {

[ ... ]

> +	/* Fail-close may release the Ethernet vport reference. */
> +	mutex_lock(&mpc->vport_mutex);
> +	if (mpc->channel_changing) {
> +		mutex_unlock(&mpc->vport_mutex);
> +		return -EBUSY;
> +	}
> +	mpc->channel_changing = true;
> +	mutex_unlock(&mpc->vport_mutex);
> +
> +	scratch = mana_qset_scratch_alloc(mpc);
> +	if (!scratch) {
> +		err = -ENOMEM;
> +		goto clear_flag;
>  	}
>  
> -	WRITE_ONCE(ndev->mtu, new_mtu);
> +	err = mana_alloc_qset(mpc, scratch, mpc->num_queues,
> +			      mpc->rx_queue_size, mpc->tx_queue_size,
> +			      mpc->priv_flags, new_mtu, &newq);
> +	if (err)
> +		goto free_scratch;
>  
> -	err = mana_attach(ndev);
> +	err = mana_publish_qset(mpc, &newq, &oldq);
>  	if (err) {
> -		netdev_err(ndev, "mana_attach failed: %d\n", err);
> -		WRITE_ONCE(ndev->mtu, old_mtu);
> +		mana_free_qset(scratch, &newq);
> +		goto free_scratch;
>  	}
>  
> -out:
> -	mana_pre_dealloc_rxbufs(mpc);
> +	mana_free_qset(scratch, &oldq);
> +
> +free_scratch:
> +	mana_publish_close_if_needed(mpc);
> +	mana_qset_scratch_free(scratch);
> +clear_flag:
> +	mutex_lock(&mpc->vport_mutex);
> +	mpc->channel_changing = false;
> +	mutex_unlock(&mpc->vport_mutex);
>  	return err;
>  }

[Severity: Medium]
Here, channel_changing seems to act as a lock around a code section rather
than as a record of object state. Is that the intent?

The flag is set under vport_mutex, and then the mutex is dropped. The whole
sleeping replacement runs after that: mana_qset_scratch_alloc(),
mana_alloc_qset(), mana_publish_qset(), mana_free_qset(),
mana_publish_close_if_needed() and mana_qset_scratch_free(). The flag is
cleared again at clear_flag.

The only reader is on the RDMA side, and it fails instead of waiting:

mana_cfg_vport() {
    ...
	mutex_lock(&apc->vport_mutex);
	if (apc->vport_use_count > 0 ||
	    (check_channel_changing && apc->channel_changing)) {
		mutex_unlock(&apc->vport_mutex);
		return -EBUSY;
	}
    ...
}

As a result, RAW-QP creation gets a transient -EBUSY during any MTU change
on a running port. Lockdep also cannot see this exclusion.

vport_mutex probably can't just be held across the region, because the
fail-close path takes it itself:

mana_publish_close_if_needed()
  -> mana_dealloc_queues()
    -> mana_destroy_vport()
      -> mana_uncfg_vport()
        -> mutex_lock(&apc->vport_mutex)

Can the -EBUSY check at the top of mana_change_mtu() ever trigger? Every
writer of channel_changing holds RTNL for its whole region, and RDMA only
reads the flag. The writers are mana_change_mtu(), the queue reset work,
the set_channels, set_ringparam and set_priv_flags handlers, and the XDP
setup path.

The same pattern already exists in the queue reset work,
mana_set_channels() and mana_set_priv_flags(). This patch extends it to
the MTU path, and it is still there at the end of the series. Could a real
lock, or some way for RDMA admission to wait, be used here?

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/cover.1791710735.git.weh%40linux.microsoft.com