Re: [PATCH net] xsk: restore UMEM flags after failed pool assignment

[Paul Moses]

On Friday, October 23rd, 2026 at 6:12 PM, Jakub Kicinski <kuba@xxxxxxxxxx> wrote:

> On Thu, 22 Oct 2026 19:10:08 +0200 Maciej Fijalkowski wrote:
> > > Right, evidence suggests igc handles it gracefully, I had attempted
> > > to provide multiple examples of real world impact to satiate Sashiko,
> > > but only igc survived final edit. It needs to be open for the failed
> > > bind and successful retry, it can be closed after and bad state
> > > remains. If you're looking for greater impact, look at stmmac. I'll
> > > send out a v2 without naming drivers specifically soon.
> >
> > Not really needed to go with v2 with reworded message. Let us wait for
> > bot reports first.
> 
> Bots look happy, but I'm slightly confused by Paul's "only igc survived
> final edit" statement. Was this issue discovered in normal development
> or by an LLM bug hunt? Was it tested on I225-V hardware, or LLM just
> suggest that HW as a NIC that would be impacted?
> 

What I meant is that it was admittedly awkward the way I left it.

I do use LLMs to a certain extent, but they have no autonomy or ability to 
communicate, I am a CS major that has a long history/love for C and  
been configuring/compiling the kernel since 2.4 (old gentoo user), so I 
didn't wander in off the street. The bug was found through development, 
I have a little n305 with dual I225-V, working on v3 for that initial 
patch I sent out, I now agree that it needs to be reworked. Currently 
experimenting with tracking frame position and these are the side 
quests...