Re: [PATCH 6.12.y 11/15] io_uring/msg_ring: ensure io_kiocb freeing is deferred for RCU

[Greg KH <gregkh@linuxfoundation.org>]

On Sat, Sep 06, 2025 at 02:47:04PM -0600, Jens Axboe wrote:
> On 9/6/25 12:36 PM, Greg KH wrote:
> > On Fri, Sep 05, 2025 at 07:23:00PM -0600, Jens Axboe wrote:
> >> On 9/5/25 1:58 PM, Jens Axboe wrote:
> >>> On 9/5/25 5:04 AM, Harshit Mogalapalli wrote:
> >>>> diff --git a/include/linux/io_uring_types.h b/include/linux/io_uring_types.h
> >>>> index 5ce332fc6ff5..3b27d9bcf298 100644
> >>>> --- a/include/linux/io_uring_types.h
> >>>> +++ b/include/linux/io_uring_types.h
> >>>> @@ -648,6 +648,8 @@ struct io_kiocb {
> >>>>  	struct io_task_work		io_task_work;
> >>>>  	/* for polled requests, i.e. IORING_OP_POLL_ADD and async armed poll */
> >>>>  	struct hlist_node		hash_node;
> >>>> +	/* for private io_kiocb freeing */
> >>>> +	struct rcu_head		rcu_head;
> >>>>  	/* internal polling, see IORING_FEAT_FAST_POLL */
> >>>>  	struct async_poll		*apoll;
> >>>>  	/* opcode allocated if it needs to store data for async defer */
> >>>
> >>> This should go into a union with hash_node, rather than bloat the
> >>> struct. That's how it was done upstream, not sure why this one is
> >>> different?
> >>
> >> Here's a test variant with that sorted. Greg, I never got a FAILED email
> >> on this one, as far as I can tell. When a patch is marked with CC:
> >> stable@vger.kernel.org and the origin of the bug clearly marked with
> >> Fixes, I'm expecting to have a 100% reliable notification if it fails to
> >> apply. If not, I just kind of assume patches flow into stable.
> >>
> >> Was this missed on my side, or was it on the stable side? If the latter,
> >> how did that happen? I always ensure that stable has what it needs and
> >> play nice on my side, but if misses like this can happen with the
> >> tooling, that makes me a bit nervous.
> >>
> > 
> > This looks like a failure on my side, sorry.  I don't see any FAILED
> > email that went out for this anywhere, so I messed up.
> > 
> > sorry about that, and Harshit, thanks for noticing it.
> 
> Thanks for confirming, because I was worried it was on my side. But I
> thought these things were fully automated? I'm going to add something on
> my side to catch these in the future, just in case.

Hah, "fully automated", I wish...

Just because "learning how the sausage is made" is something that some
people are curious about, here's how I apply stable patches:
  - I get a mbox full of patches that are in Linus's tree with a
    cc:stable in them, when he applies them to his tree.  How that
    happens is another story...
  - In mutt, I open the mbox, and pick a patch to look at.  if it seems
    sane (almost all do), I look for a "Fixes:" tag.  if it's there, I
    press a key and a script of mine + a local database I've hacked
    together, tells me just how far back that "Fixes: " commit went.  I
    try to remember that version number.
  - I press a different key, and the mail is turned into a patch, and
    then attempted to be applied to each branch of the currently active
    stable trees using quilt.  It tells me about fuzz, or failures, or
    other things, and can let me resolve failures if I want to, one per
    branch (I have to manually continue on after each attempt because I
    can cancel it all if it stops applying).
  - If the patch didn't apply all the way back, I go to a different
    terminal window and run 'bad_stable GIT_ID' with GIT_ID the id from
    the original commit which I had selected in the original email.  I'm
    then offered up which tree to say it failed for by the script, and
    it sends the email off.

Notice the "I try to remember how far back" stage.  Normally that works
just fine.  Sometimes it doesn't.  This time it didn't.  Overall my % is
pretty good in the past 20+ years of doing this.  Or no one is really
paying attention and my % is way worse, hard to tell...

And yes, I've tried to make the "send the failed email" happen directly
from the failure to apply, but that gets into some combinations of "did
it really want to go that far back" (some patches do not have Fixes:
tags) and sometimes Fixes is actually wrong (hit that just a few minutes
ago with a drm patch), and there's some messy terminal/focus issues with
running interactive scripts from within a mutt process that sometimes
requires me to spawn separate windows to work around, but then I lost
the original email involved as that was piped from mutt, and well, it's
a mess.  So I stick to this process.

I can process stable patches pretty fast now, I'm only rate limited by
my test builds, not the "apply from email" dance.  And the failure rate
is generally pretty low, with the exception of the -rc1 DRM subsystem
merge nightmare, but that's another issue...

Anyway, sorry for the wall of text that you weren't looking for :)

greg k-h