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 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.

greg k-h