Re: FAILED: patch "[PATCH] io_uring: only flush workqueues on fileset removal" failed to apply to 5.3-stable tree

[Greg KH <gregkh@linuxfoundation.org>]

On Wed, Oct 16, 2019 at 10:20:16AM -0600, Jens Axboe wrote:
> On 10/16/19 10:13 AM, Greg KH wrote:
> > On Wed, Oct 16, 2019 at 09:04:43AM -0700, gregkh@linuxfoundation.org wrote:
> >>
> >> The patch below does not apply to the 5.3-stable tree.
> >> If someone wants it applied there, or to any other stable or longterm
> >> tree, then please email the backport, including the original git commit
> >> id to <stable@vger.kernel.org>.
> >>
> >> thanks,
> >>
> >> greg k-h
> >>
> >> ------------------ original commit in Linus's tree ------------------
> >>
> >> >From 8a99734081775c012a4a6c442fdef0379fe52bdf Mon Sep 17 00:00:00 2001
> >> From: Jens Axboe <axboe@kernel.dk>
> >> Date: Wed, 9 Oct 2019 14:40:13 -0600
> >> Subject: [PATCH] io_uring: only flush workqueues on fileset removal
> >>
> >> We should not remove the workqueue, we just need to ensure that the
> >> workqueues are synced. The workqueues are torn down on ctx removal.
> >>
> >> Cc: stable@vger.kernel.org
> >> Fixes: 6b06314c47e1 ("io_uring: add file set registration")
> >> Reported-by: Stefan Hajnoczi <stefanha@redhat.com>
> >> Signed-off-by: Jens Axboe <axboe@kernel.dk>
> >>
> >> diff --git a/fs/io_uring.c b/fs/io_uring.c
> >> index ceb3497bdd2a..2c44648217bd 100644
> >> --- a/fs/io_uring.c
> >> +++ b/fs/io_uring.c
> >> @@ -2866,8 +2866,12 @@ static void io_finish_async(struct io_ring_ctx *ctx)
> >>   static void io_destruct_skb(struct sk_buff *skb)
> >>   {
> >>   	struct io_ring_ctx *ctx = skb->sk->sk_user_data;
> >> +	int i;
> >> +
> >> +	for (i = 0; i < ARRAY_SIZE(ctx->sqo_wq); i++)
> >> +		if (ctx->sqo_wq[i])
> >> +			flush_workqueue(ctx->sqo_wq[i]);
> >>   
> >> -	io_finish_async(ctx);
> >>   	unix_destruct_scm(skb);
> >>   }
> >>   
> >>
> > 
> > This fails to build as sqo_wq is a pointer in 5.3, not an arrary.
> > Backporting that array change feels "big" for 5.3, is that needed here,
> > or can this be fixed differently?
> 
> Yeah, we don't need to do that. It's just a pointer in 5.3, not an
> array of pointers, so the below should be all we need for 5.3 (and
> 5.2/5.1).

5.2/5.1 are long end-of-life, but this change looks sane.  I'll go queue
it up for 5.3.y, thanks for the patch!

greg k-h