All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>,
	 fengwei_yin@linux.alibaba.com,
	 Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: davem@davemloft.net,  edumazet@google.com,  pabeni@redhat.com,
	 horms@kernel.org,  netdev@vger.kernel.org,
	 linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: procfs: Fix RCU stall and soft lockup in ptype_seq_next()
Date: Sat, 31 Jan 2026 12:41:42 -0500	[thread overview]
Message-ID: <willemdebruijn.kernel.39472926ed88e@gmail.com> (raw)
In-Reply-To: <20260130191845.404c5e64@kernel.org>

Jakub Kicinski wrote:
> On Wed, 28 Jan 2026 15:03:59 +0800 fengwei_yin@linux.alibaba.com wrote:
> > The root cause is in ptype_seq_next(): when iterating over packet
> > types, it's possible that a packet type entry (pt) has been removed,
> > its dev set to NULL, and pt->af_packet_net is not initialized.
> > In that case, the function may return the same 'nxt' pointer indefinitely.
> > This results in an infinite loop under RCU read-side critical section,
> > causing an RCU stall and eventually a soft lockup.
> > 
> > Fix the issue by properly handling the case where 'nxt' points to
> > an empty list, ensuring forward progress in the iterator.
> 
> > @@ -247,7 +247,7 @@ static void *ptype_seq_next(struct seq_file *seq, void *v, loff_t *pos)
> >  
> >  	if (pt->af_packet_net) {
> >  net_ptype_all:
> > -		if (nxt != &net->ptype_all && nxt != &net->ptype_specific)
> > +		if (!list_empty(nxt) && nxt != &net->ptype_all && nxt != &net->ptype_specific)
> >  			goto found;
> >  
> >  		if (nxt == &net->ptype_all) {
> > @@ -267,6 +267,9 @@ static void *ptype_seq_next(struct seq_file *seq, void *v, loff_t *pos)
> >  			return NULL;
> >  		nxt = ptype_base[hash].next;
> >  	}
> > +
> > +	if (list_empty(nxt))
> > +		return NULL;
> >  found:
> >  	return list_entry(nxt, struct packet_type, list);
> >  }
> 
> I'm not sure this fix works, TBH, we're dealing with an RCU list here.
> The elements are not deleted with list_del_init(), so they won't
> look "empty".
> 
> If the pt entries are under RCU protection I think the issue is that
> af_packet is clearing pt->dev before waiting for the grace period to
> expire.
>
> Willem, is there a reason for that or just convenience?

That would be wrong. Do we see it doing that somewhere?

These handlers should get removed with dev_remove_pack. Or
__dev_remove_pack and observe the RCU grace period some other way.
I can review these, but was not aware of any abuses.

> -- 
> pw-bot: cr



  reply	other threads:[~2026-01-31 17:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-28  7:03 [PATCH] net: procfs: Fix RCU stall and soft lockup in ptype_seq_next() fengwei_yin
2026-01-31  3:18 ` Jakub Kicinski
2026-01-31 17:41   ` Willem de Bruijn [this message]
2026-01-31 17:50     ` Eric Dumazet
2026-01-31 18:00       ` Eric Dumazet
2026-02-02  1:04         ` YinFengwei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=willemdebruijn.kernel.39472926ed88e@gmail.com \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fengwei_yin@linux.alibaba.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.