linux-kernel - Re: [PATCH net] net: ps3_gelic_net: handle skb allocation failures

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: <20251112063143.1040d431@kernel.org>
Date: Wed, 12 Nov 2025 06:31:43 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Florian Fuchs <fuchsfl@...il.com>
Cc: Geoff Levand <geoff@...radead.org>, netdev@...r.kernel.org, Andrew Lunn
 <andrew+netdev@...n.ch>, "David S . Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Madhavan
 Srinivasan <maddy@...ux.ibm.com>, Michael Ellerman <mpe@...erman.id.au>,
 Nicholas Piggin <npiggin@...il.com>, Christophe Leroy
 <christophe.leroy@...roup.eu>, linuxppc-dev@...ts.ozlabs.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] net: ps3_gelic_net: handle skb allocation failures

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