All of lore.kernel.org
 help / color / mirror / Atom feed
From: Przemek Kitszel <przemyslaw.kitszel@intel.com>
To: Aaron Ma <aaron.ma@canonical.com>
Cc: Dan Nowlin <dan.nowlin@intel.com>,
	Brett Creeley <brett.creeley@intel.com>,
	Jacob Keller <jacob.e.keller@intel.com>,
	"moderated list:INTEL ETHERNET DRIVERS"
	<intel-wired-lan@lists.osuosl.org>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Alexander Lobakin <aleksander.lobakin@intel.com>,
	Richard Cochran <richardcochran@gmail.com>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/5] ice: scope global configuration lock to the adapter
Date: Thu, 22 Oct 2026 13:10:16 +0200	[thread overview]
Message-ID: <ac4fb583-4721-48ec-bea5-ee4e7380f606@intel.com> (raw)
In-Reply-To: <20261019105155.3793063-4-aaron.ma@canonical.com>

On 10/19/26 12:51 PM, Aaron Ma wrote:
> ice_global_cfg_lock_sw is a module-global mutex, so a package download
> on one E810 adapter blocks Admin Queue commands on unrelated adapters in
> the same system. In addition, the mutex is acquired only after firmware
> grants the Global Configuration Lock and dropped before firmware
> releases it, while the opcode exemption list in ice_aq_send_cmd() does
> not check whether the caller is the lock owner. Non-owning PFs on the
> same adapter can therefore submit exempted Admin Queue commands or
> sideband requests while another PF holds firmware ownership.

This is not a bug to allow exempted commands, does not matter from which
PF.

> 
> Move the software mutex to struct ice_adapter and record the owning task
> across the entire Global Configuration Lock acquisition and release
> sequence, including the core reset path in ice_cfg_tx_topo(). In

this is fine,
would be better to not track mutex holder

> ice_aq_send_cmd(), require non-owning tasks to wait on the adapter mutex
> while allowing the owning task to issue the permitted configuration
> commands. 


> Route the Admin Queue fallback in ice_sbq_send_cmd() through
> ice_aq_send_cmd() as well.

perhaps this should be separate commit?

> 
> This patch depends on the previous patch in this series.
> 
> Fixes: c76488109616 ("ice: Implement Dynamic Device Personalization (DDP) download")
> Signed-off-by: Aaron Ma <aaron.ma@canonical.com>


> @@ -1895,17 +1894,24 @@ ice_aq_send_cmd(struct ice_hw *hw, struct libie_aq_desc *desc, void *buf,
>   		u16 buf_size, struct ice_sq_cd *cd)
>   {
>   	struct libie_aqc_req_res *cmd = libie_aq_raw(desc);
> -	bool lock_acquired = false;
> -	int status;
> +	struct ice_pf *pf = hw->back;
> +	struct ice_adapter *adapter = pf->adapter;

RCT violation

> +
> +	if (READ_ONCE(adapter->global_cfg_owner) != current) {
> +		guard(mutex)(&adapter->global_cfg_lock);

no guard()()
especially here scoped_guard() fits nicely

> +		return ice_sq_send_cmd_retry(hw, &hw->adminq, desc, buf,
> +					     buf_size, cd);
> +	}


  parent reply	other threads:[~2026-10-22 11:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-19 10:51 [PATCH 0/5] ice: fix reset and suspend paths Aaron Ma
2026-10-19 10:51 ` [PATCH 1/5] ice: check the full PF reset polling limit Aaron Ma
2026-10-19 11:28   ` Temerkhanov, Sergey
2026-10-19 11:30   ` Przemek Kitszel
2026-10-27 21:35   ` Jacob Keller
2026-10-19 10:51 ` [PATCH 2/5] ice: retain the adapter throughout hardware initialization and teardown Aaron Ma
2026-10-19 11:29   ` Temerkhanov, Sergey
2026-10-20  9:24   ` Przemek Kitszel
2026-10-22 18:06     ` Jacob Keller
2026-10-19 10:51 ` [PATCH 3/5] ice: scope global configuration lock to the adapter Aaron Ma
2026-10-21 11:12   ` Loktionov, Aleksandr
2026-10-22  8:17     ` Aaron Ma
2026-10-22 11:10   ` Przemek Kitszel [this message]
2026-10-22 18:19     ` Jacob Keller
2026-10-19 10:51 ` [PATCH 4/5] ice: clear DVM boost table before scanning package hints Aaron Ma
2026-10-19 10:51 ` [PATCH 5/5] ice: quiesce PTP periodic work before system suspend Aaron Ma
2026-10-21 12:14   ` Loktionov, Aleksandr
2026-10-22 18:22   ` Jacob Keller

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=ac4fb583-4721-48ec-bea5-ee4e7380f606@intel.com \
    --to=przemyslaw.kitszel@intel.com \
    --cc=aaron.ma@canonical.com \
    --cc=aleksander.lobakin@intel.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=brett.creeley@intel.com \
    --cc=dan.nowlin@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jacob.e.keller@intel.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=richardcochran@gmail.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.