On 10/16/19 10:33 AM, Greg KH wrote:
> 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@xxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx>.
>>>>
>>>> thanks,
>>>>
>>>> greg k-h
>>>>
>>>> ------------------ original commit in Linus's tree ------------------
>>>>
>>>> >From 8a99734081775c012a4a6c442fdef0379fe52bdf Mon Sep 17 00:00:00 2001
>>>> From: Jens Axboe <axboe@xxxxxxxxx>
>>>> 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@xxxxxxxxxxxxxxx
>>>> Fixes: 6b06314c47e1 ("io_uring: add file set registration")
>>>> Reported-by: Stefan Hajnoczi <stefanha@xxxxxxxxxx>
>>>> Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
>>>>
>>>> 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!
Thanks Greg!
--
Jens Axboe
