netdev - Re: [net PATCH 6/6] fbnic: Pull fbnic_fw_xmit_cap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250506155049.GR3339421@horms.kernel.org>
Date: Tue, 6 May 2025 16:50:49 +0100
From: Simon Horman <horms@...nel.org>
To: Alexander Duyck <alexander.duyck@...il.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
	pabeni@...hat.com
Subject: Re: [net PATCH 6/6] fbnic: Pull fbnic_fw_xmit_cap_msg use out of
 interrupt context

On Sun, May 04, 2025 at 07:53:09AM -0700, Alexander Duyck wrote:
> On Fri, May 2, 2025 at 9:54 AM Simon Horman <horms@...nel.org> wrote:
> >
> > On Thu, May 01, 2025 at 04:30:30PM -0700, Alexander Duyck wrote:
> > > From: Alexander Duyck <alexanderduyck@...com>
> > >
> > > This change pulls the call to fbnic_fw_xmit_cap_msg out of
> > > fbnic_mbx_init_desc_ring and instead places it in the polling function for
> > > getting the Tx ready. Doing that we can avoid the potential issue with an
> > > interrupt coming in later from the firmware that causes it to get fired in
> > > interrupt context.
> > >
> > > In addition we can add additional verification to the poll_tx_ready
> > > function to make sure that the mailbox is actually ready by verifying that
> > > it has populated the capabilities from the firmware. This is important as
> > > the link config relies on this and we were currently delaying this until
> > > the open call was made which would force the capbabilities message to be
> > > processed then. This resolves potential issues with the link state being
> > > inconsistent between the netdev being registered and the open call being
> > > made.
> > >
> > > Lastly we can make the overall mailbox poll-to-ready more
> > > reliable/responsive by reducing the overall sleep time and using a jiffies
> > > based timeout method instead of relying on X number of sleeps/"attempts".
> >
> > This patch really feels like it ought to be three patches.
> > Perhaps that comment applies to other patches in this series,
> > but this one seems to somehow stand out in that regard.
> 
> Yeah, part of the issue is that these patches all became an exercise
> in "flipping rocks". Every time I touched one thing it exposed a bunch
> more bugs. I'll try to split this one up a bit more. I should be able
> to defer the need for the management version until net-next which will
> cut down on the noise.

Thanks. I could see that you were working your way through some sort of
rabbit hole situation. And while I certainly don't want to be unreasonable.
If would be nice if you could split this one up a bit. And it would
be a bonus in my view if some bits could be deferred to net-next.