netdev - Re: [Intel-wired-lan] i40e XDP program stops transmitting after link down/up

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] [thread-next>] [day] [month] [year] [list]

Date: Wed, 31 Jan 2024 10:26:07 -0600
From: Seth Forshee <sforshee@...nel.org>
To: Maciej Fijalkowski <maciej.fijalkowski@...el.com>
Cc: Paul Menzel <pmenzel@...gen.mpg.de>,
	Jesse Brandeburg <jesse.brandeburg@...el.com>,
	Tony Nguyen <anthony.l.nguyen@...el.com>, netdev@...r.kernel.org,
	intel-wired-lan@...ts.osuosl.org
Subject: Re: [Intel-wired-lan] i40e XDP program stops transmitting after link
 down/up

On Tue, Jan 30, 2024 at 11:06:07PM +0100, Maciej Fijalkowski wrote:
> On Tue, Jan 30, 2024 at 08:28:24PM +0100, Maciej Fijalkowski wrote:
> > On Tue, Jan 30, 2024 at 10:59:13AM -0600, Seth Forshee wrote:
> > > On Tue, Jan 30, 2024 at 05:14:23PM +0100, Paul Menzel wrote:
> > > > Dear Seth,
> > > > 
> > > > 
> > > > Thank you for bring this up.
> > > > 
> > > > Am 30.01.24 um 15:17 schrieb Seth Forshee:
> > > > > I got a inquiry from a colleague about a behavior he's seeing with i40e
> > > > > but not with other NICs. The interfaces are bonded with a XDP
> > > > > load-balancer program attached to them. After 'ip link set ethX down; ip
> > > > > link set ethX up' on one of the interfaces the XDP program on that
> > > > > interface is no longer transmitting packets. He found that tx starts
> > > > > again after running 'sudo ethtool -t ethX'.
> > > > > 
> > > > > There's a 'i40e 0000:d8:00.1: VSI seid 391 XDP Tx ring 0 disable
> > > > > timeout' message in dmesg when disabling the interface. I've included
> > > > > the relevant portions from dmesg below.
> > > > > 
> > > > > This was first observed with a 6.1 kernel, but we've confirmed that the
> > > > > behavior is the same in 6.7. I realize the firmware is pretty old, so
> > > > > far our attempts to update the NVM have failed.
> > > > 
> > > > Does that mean, the problem didn’t happen before Linux 6.1? If so, if you
> > > > have the reproducer and the time, bisecting the issue is normally the
> > > > fastest way to solve the issue.
> > > 
> > > No, sorry, I should have worded that better. I meant that they were
> > > using 6.1 when they noticed the issue, not that kernels before 6.1 did
> > > not have that issue. We've also tried a 5.15 kernel build now and still
> > > see the issue there, we haven't tested anything older than that.
> > 
> > Hey Seth,
> > 
> > I am observing same thing on my side with xdpsock in txonly mode, so I'll
> > take a look at this and will keep you updated.
> 
> Can you try this diff on your side?

That fixes the problem!

Thanks,
Seth