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: <CAKgT0UeQ6_HSQ=2E6-DNuKA0yMWbYYhhZrKPvhBEhmwODmbSeQ@mail.gmail.com>
Date: Sun, 4 May 2025 07:53:09 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Simon Horman <horms@...nel.org>
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 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.