mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Jens Axboe <axboe@kernel.dk>
Cc: Anvik Loitongbam <permissiontogallop@gmail.com>,
	Pavel Begunkov <asml.silence@gmail.com>,
	Olivier Langlois <olivier@trillion01.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	io-uring@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-rt-devel@lists.linux.dev, stable@vger.kernel.org
Subject: Re: [PATCH] io_uring/napi: fix list use-after-free on PREEMPT_RT
Date: Thu, 29 Oct 2026 10:31:17 -0400	[thread overview]
Message-ID: <20261029103117.50aae919@gandalf.local.home> (raw)
In-Reply-To: <3fa26fac-5317-4c09-a181-c9c15e124972@kernel.dk>

On Thu, 29 Oct 2026 08:28:13 -0600
Jens Axboe <axboe@kernel.dk> wrote:

> On 10/29/26 7:48 AM, Steven Rostedt wrote:
> > On Thu, 29 Oct 2026 07:42:09 -0600
> > Jens Axboe <axboe@kernel.dk> wrote:
> >   
> >> I don't think your analysis is fully correct. On PREEMPT_RT, spin_lock()
> >> should still be an RCU read side critical section. __rt_spin_lock()
> >> calls rcu_read_lock() after taking the rtmutex, and then
> >> rt_spin_unlock() drops it at the end. There's even a comment on
> >> kfree_rcu() callbacks in there too, it should not be able to run until
> >> napi_lock is released, which is post the loop.  
> > 
> > Good point.  
> 
> If even the preempt rt people can't get this right, that's a little
> worrying :)

I really didn't even take a deep look at how preempt-rt was involved. I
just didn't like the assumption about the RCU internals in general ;-)

> 
> >> IOW, I think this patch is unnecessary - there's no bug there. The list
> >> safe change could be done as a cleanup, but it's not a fix.  
> > 
> > I agree, it should still be applied, but as a clean up and not a fix.  
> 
> Sure, like I said, as a cleanup. But would need a resend as the
> analysis in the commit message is entirely wrong.
> 

Totally agree.

-- Steve


      reply	other threads:[~2026-10-29 14:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-29 10:22 Anvik Loitongbam
2026-10-29 13:35 ` Steven Rostedt
2026-10-29 13:42 ` Jens Axboe
2026-10-29 13:48   ` Steven Rostedt
2026-10-29 14:28     ` Jens Axboe
2026-10-29 14:31       ` Steven Rostedt [this message]

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=20261029103117.50aae919@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=bigeasy@linutronix.de \
    --cc=io-uring@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=olivier@trillion01.com \
    --cc=permissiontogallop@gmail.com \
    --cc=stable@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®