Re: [PATCH net] net: ps3_gelic_net: handle skb allocation failures

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 12 Nov 2025 10:34:01 +0100 Florian Fuchs wrote:
> > > --- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
> > > +++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
> > > @@ -259,6 +259,7 @@ void gelic_card_down(struct gelic_card *card)
> > >  	mutex_lock(&card->updown_lock);
> > >  	if (atomic_dec_if_positive(&card->users) == 0) {
> > >  		pr_debug("%s: real do\n", __func__);
> > > +		timer_delete_sync(&card->rx_oom_timer);
> > >  		napi_disable(&card->napi);  
> > 
> > I think the ordering here should be inverted  
> 
> I thought, that there might be a race condition in the inverted order
> like that napi gets re-enabled by the timer in between of the down:
> 
> 1. napi_disable
> 2. rx_oom_timer runs and calls napi_schedule again
> 3. timer_delete_sync
> 
> So the timer is deleted first, to prevent any possibility to run.

napi_disable() makes napi_schedule() a nop (it makes it look like it's
already scheduled).

> > TBH handling the OOM inside the Rx function seems a little fragile.
> > What if there is a packet to Rx as we enter. I don't see any loop here
> > it just replaces the used buffer..  
> 
> I am not sure, the handling needs to happen, when the skb allocation
> fails, and that happens in the rx function, right? I am open to better
> fitting fix position.

Purely from the structure of the code PoV it'd be cleaner if the
alloc/refill was separate from the processing so we can call just 
that part.

But looking closer I think the handling is fine as is. So I think
just addressing the nits is fine for v2