Re: [PATCH net] bnxt_en: Take RTNL before netif_close() when aborting FW reset

[Michael Chan]

On Mon, Nov 2, 2026 at 10:59 AM Michael Chan <michael.chan@xxxxxxxxxxxx> wrote:
>
> On Wed, Oct 28, 2026 at 8:28 PM Bryan Cochrane <bcochrane@xxxxxxxxxx> wrote:
>
> >  drivers/net/ethernet/broadcom/bnxt/bnxt.c | 9 +++++----
> >  1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> > index 0682060b048c..0f37639b70ba 100644
> > --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> > +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> > @@ -14798,7 +14798,7 @@ static int bnxt_get_registered_vfs(struct bnxt *bp)
> >  void bnxt_fw_reset(struct bnxt *bp)
> >  {
> >         bnxt_ulp_stop(bp);
> > -       bnxt_lock_sp(bp);
> > +       bnxt_rtnl_lock_sp(bp);
>
> Thanks for the patch.  This isignificantly increases the scope of the
> rtnl_lock to cover the whole FW reset sequence.  I'm concerned that
> with a large number of VFs running in the same kernel, the rtnl_lock
> contention will cause some of the VFs to fail recovery.
>

Looking more closely, I think the case that requires the rtnl_lock is
very narrow.  Only a PF with active VFs will need it in case
bnxt_get_registered_vfs() fails.  For example, all the VFs now will
take the rtnl_lock for no reason and will cause unnecessary
contention.  I suggest fixing this bnxt_get_registered_vfs() failure
more locally without increasing the scope of the rtnl_lock.  Thanks.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature