io_uring stable 5.3 backports

io_uring stable 5.3 backports

[Jens Axboe]

Hi,

For some reason I forgot to mark these stable, but they should go
into stable. In order of applying them, they are:

bc808bced39f4e4b626c5ea8c63d5e41fce7205a
ef03681ae8df770745978148a7fb84796ae99cba
a1f58ba46f794b1168d1107befcf3d4b9f9fd453
84d55dc5b9e57b513a702fbc358e1b5489651590
fb5ccc98782f654778cb8d96ba8a998304f9a51f
935d1e45908afb8853c497f2c2bbbb685dec51dc
498ccd9eda49117c34e0041563d0da6ac40e52b8
2b2ed9750fc9d040b9f6d076afcef6f00b6f1f7c

Thanks!

-- 
Jens Axboe

Re: io_uring stable 5.3 backports

[Greg KH]

On Sat, Oct 26, 2019 at 05:33:41PM -0600, Jens Axboe wrote:
> Hi,
> 
> For some reason I forgot to mark these stable, but they should go
> into stable. In order of applying them, they are:
> 
> bc808bced39f4e4b626c5ea8c63d5e41fce7205a
> ef03681ae8df770745978148a7fb84796ae99cba
> a1f58ba46f794b1168d1107befcf3d4b9f9fd453
> 84d55dc5b9e57b513a702fbc358e1b5489651590
> fb5ccc98782f654778cb8d96ba8a998304f9a51f
> 935d1e45908afb8853c497f2c2bbbb685dec51dc
> 498ccd9eda49117c34e0041563d0da6ac40e52b8
> 2b2ed9750fc9d040b9f6d076afcef6f00b6f1f7c

Only 2 of these patches applied to the 5.3 stable tree, are you sure you
want these all there?  If so, can you provide a backport of them all?

I already did queue up these two:
	2b2ed9750fc9 ("io_uring: fix bad inflight accounting for SETUP_IOPOLL|SETUP_SQTHREAD")
	84d55dc5b9e5 ("io_uring: Fix corrupted user_data")

thanks,

greg k-h

Re: io_uring stable 5.3 backports

[Sasha Levin]

On Sat, Oct 26, 2019 at 05:33:41PM -0600, Jens Axboe wrote:
>Hi,
>
>For some reason I forgot to mark these stable, but they should go
>into stable. In order of applying them, they are:
>
>bc808bced39f4e4b626c5ea8c63d5e41fce7205a

This commit says it fixes c576666863b78 ("io_uring: optimize
submit_and_wait API") which is not in the stable tree.

>ef03681ae8df770745978148a7fb84796ae99cba

This commit doesn't say so, but really it fixes 5262f567987d3
("io_uring: IORING_OP_TIMEOUT support") which is not in the stable tree.

>a1f58ba46f794b1168d1107befcf3d4b9f9fd453

Same as the commit above.

>84d55dc5b9e57b513a702fbc358e1b5489651590
>fb5ccc98782f654778cb8d96ba8a998304f9a51f

This needed some massaging to work around not having 4fe2c963154c3
("io_uring: add support for link with drain"). I've fixed it up and
queued it.

>935d1e45908afb8853c497f2c2bbbb685dec51dc

I think that Greg's scripts didn't like how much this code moved around
and refused to deal with it. I've verified patching did the right thing
and queued it up.

>498ccd9eda49117c34e0041563d0da6ac40e52b8

This one needed massaging to work around missing 75b28affdd6ae
("io_uring: allocate the two rings together") in the stable tree. I've
fixed it up and queued it up.


Jens, could you please take a look at my backport of fb5ccc98782f65:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.3/io_uring-fix-broken-links-with-offloading.patch

And 498ccd9eda491:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.3/io_uring-used-cached-copies-of-sq-dropped-and-cq-ove.patch

And confirm I did the right thing?

-- 
Thanks,
Sasha

Re: io_uring stable 5.3 backports

[Jens Axboe]

On 10/27/19 2:52 AM, Sasha Levin wrote:
> On Sat, Oct 26, 2019 at 05:33:41PM -0600, Jens Axboe wrote:
>> Hi,
>>
>> For some reason I forgot to mark these stable, but they should go
>> into stable. In order of applying them, they are:
>>
>> bc808bced39f4e4b626c5ea8c63d5e41fce7205a
> 
> This commit says it fixes c576666863b78 ("io_uring: optimize
> submit_and_wait API") which is not in the stable tree.
> 
>> ef03681ae8df770745978148a7fb84796ae99cba
> 
> This commit doesn't say so, but really it fixes 5262f567987d3
> ("io_uring: IORING_OP_TIMEOUT support") which is not in the stable tree.
> 
>> a1f58ba46f794b1168d1107befcf3d4b9f9fd453
> 
> Same as the commit above.

Oh man, sorry about that, I always forget to check if all of them are in
5.3. I blame the fact that I backport everything to our internal tree,
which is 5.2 based. But yes, you are of course right, those three can be
dropped.

>> 84d55dc5b9e57b513a702fbc358e1b5489651590
>> fb5ccc98782f654778cb8d96ba8a998304f9a51f
> 
> This needed some massaging to work around not having 4fe2c963154c3
> ("io_uring: add support for link with drain"). I've fixed it up and
> queued it.
> 
>> 935d1e45908afb8853c497f2c2bbbb685dec51dc
> 
> I think that Greg's scripts didn't like how much this code moved around
> and refused to deal with it. I've verified patching did the right thing
> and queued it up.
> 
>> 498ccd9eda49117c34e0041563d0da6ac40e52b8
> 
> This one needed massaging to work around missing 75b28affdd6ae
> ("io_uring: allocate the two rings together") in the stable tree. I've
> fixed it up and queued it up.
> 
> 
> Jens, could you please take a look at my backport of fb5ccc98782f65:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.3/io_uring-fix-broken-links-with-offloading.patch
> 
> And 498ccd9eda491:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.3/io_uring-used-cached-copies-of-sq-dropped-and-cq-ove.patch
> 
> And confirm I did the right thing?

Of course, I'll take a look right now. Thanks for taking care of these!

-- 
Jens Axboe

Re: io_uring stable 5.3 backports

[Jens Axboe]

On 10/27/19 6:01 AM, Jens Axboe wrote:
>> Jens, could you please take a look at my backport of fb5ccc98782f65:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.3/io_uring-fix-broken-links-with-offloading.patch
>>
>> And 498ccd9eda491:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.3/io_uring-used-cached-copies-of-sq-dropped-and-cq-ove.patch
>>
>> And confirm I did the right thing?
> 
> Of course, I'll take a look right now. Thanks for taking care of these!

Both look good to me.

-- 
Jens Axboe

Re: io_uring stable 5.3 backports

[Sasha Levin]

On Sun, Oct 27, 2019 at 06:01:03AM -0600, Jens Axboe wrote:
>On 10/27/19 2:52 AM, Sasha Levin wrote:
>> On Sat, Oct 26, 2019 at 05:33:41PM -0600, Jens Axboe wrote:
>>> Hi,
>>>
>>> For some reason I forgot to mark these stable, but they should go
>>> into stable. In order of applying them, they are:
>>>
>>> bc808bced39f4e4b626c5ea8c63d5e41fce7205a
>>
>> This commit says it fixes c576666863b78 ("io_uring: optimize
>> submit_and_wait API") which is not in the stable tree.
>>
>>> ef03681ae8df770745978148a7fb84796ae99cba
>>
>> This commit doesn't say so, but really it fixes 5262f567987d3
>> ("io_uring: IORING_OP_TIMEOUT support") which is not in the stable tree.
>>
>>> a1f58ba46f794b1168d1107befcf3d4b9f9fd453
>>
>> Same as the commit above.
>
>Oh man, sorry about that, I always forget to check if all of them are in
>5.3. I blame the fact that I backport everything to our internal tree,
>which is 5.2 based. But yes, you are of course right, those three can be
>dropped.

How much "secret sauce" does your internal tree have? Is it something we
can peek into to make sure we don't miss fixes?

-- 
Thanks,
Sasha

Re: io_uring stable 5.3 backports

[Jens Axboe]

On 10/27/19 7:48 AM, Sasha Levin wrote:
> On Sun, Oct 27, 2019 at 06:01:03AM -0600, Jens Axboe wrote:
>> On 10/27/19 2:52 AM, Sasha Levin wrote:
>>> On Sat, Oct 26, 2019 at 05:33:41PM -0600, Jens Axboe wrote:
>>>> Hi,
>>>>
>>>> For some reason I forgot to mark these stable, but they should go
>>>> into stable. In order of applying them, they are:
>>>>
>>>> bc808bced39f4e4b626c5ea8c63d5e41fce7205a
>>>
>>> This commit says it fixes c576666863b78 ("io_uring: optimize
>>> submit_and_wait API") which is not in the stable tree.
>>>
>>>> ef03681ae8df770745978148a7fb84796ae99cba
>>>
>>> This commit doesn't say so, but really it fixes 5262f567987d3
>>> ("io_uring: IORING_OP_TIMEOUT support") which is not in the stable tree.
>>>
>>>> a1f58ba46f794b1168d1107befcf3d4b9f9fd453
>>>
>>> Same as the commit above.
>>
>> Oh man, sorry about that, I always forget to check if all of them are in
>> 5.3. I blame the fact that I backport everything to our internal tree,
>> which is 5.2 based. But yes, you are of course right, those three can be
>> dropped.
> 
> How much "secret sauce" does your internal tree have? Is it something
> we can peek into to make sure we don't miss fixes?

There's no secret sauce in the internal tree, it's just that I backport
everything into the 5.2 version that is our newest. It's fully uptodate
with 5.4-rc and in some cases what's queued up for 5.5 as well. Hence I
sometimes forget to check what is applicable to 5.3-stable, since I have
it in our 5.2 tree...

The internal tree is just backports. That's how we do things.

-- 
Jens Axboe

Re: io_uring stable 5.3 backports

[Sasha Levin]

On Sun, Oct 27, 2019 at 08:03:09AM -0600, Jens Axboe wrote:
>On 10/27/19 7:48 AM, Sasha Levin wrote:
>> On Sun, Oct 27, 2019 at 06:01:03AM -0600, Jens Axboe wrote:
>>> On 10/27/19 2:52 AM, Sasha Levin wrote:
>>>> On Sat, Oct 26, 2019 at 05:33:41PM -0600, Jens Axboe wrote:
>>>>> Hi,
>>>>>
>>>>> For some reason I forgot to mark these stable, but they should go
>>>>> into stable. In order of applying them, they are:
>>>>>
>>>>> bc808bced39f4e4b626c5ea8c63d5e41fce7205a
>>>>
>>>> This commit says it fixes c576666863b78 ("io_uring: optimize
>>>> submit_and_wait API") which is not in the stable tree.
>>>>
>>>>> ef03681ae8df770745978148a7fb84796ae99cba
>>>>
>>>> This commit doesn't say so, but really it fixes 5262f567987d3
>>>> ("io_uring: IORING_OP_TIMEOUT support") which is not in the stable tree.
>>>>
>>>>> a1f58ba46f794b1168d1107befcf3d4b9f9fd453
>>>>
>>>> Same as the commit above.
>>>
>>> Oh man, sorry about that, I always forget to check if all of them are in
>>> 5.3. I blame the fact that I backport everything to our internal tree,
>>> which is 5.2 based. But yes, you are of course right, those three can be
>>> dropped.
>>
>> How much "secret sauce" does your internal tree have? Is it something
>> we can peek into to make sure we don't miss fixes?
>
>There's no secret sauce in the internal tree, it's just that I backport
>everything into the 5.2 version that is our newest. It's fully uptodate
>with 5.4-rc and in some cases what's queued up for 5.5 as well. Hence I
>sometimes forget to check what is applicable to 5.3-stable, since I have
>it in our 5.2 tree...
>
>The internal tree is just backports. That's how we do things.

Could you push it somewhere public? I could automate grabbing fixes off
of it.

-- 
Thanks,
Sasha

Re: io_uring stable 5.3 backports

[Jens Axboe]

On 10/27/19 8:24 AM, Sasha Levin wrote:
> On Sun, Oct 27, 2019 at 08:03:09AM -0600, Jens Axboe wrote:
>> On 10/27/19 7:48 AM, Sasha Levin wrote:
>>> On Sun, Oct 27, 2019 at 06:01:03AM -0600, Jens Axboe wrote:
>>>> On 10/27/19 2:52 AM, Sasha Levin wrote:
>>>>> On Sat, Oct 26, 2019 at 05:33:41PM -0600, Jens Axboe wrote:
>>>>>> Hi,
>>>>>>
>>>>>> For some reason I forgot to mark these stable, but they should go
>>>>>> into stable. In order of applying them, they are:
>>>>>>
>>>>>> bc808bced39f4e4b626c5ea8c63d5e41fce7205a
>>>>>
>>>>> This commit says it fixes c576666863b78 ("io_uring: optimize
>>>>> submit_and_wait API") which is not in the stable tree.
>>>>>
>>>>>> ef03681ae8df770745978148a7fb84796ae99cba
>>>>>
>>>>> This commit doesn't say so, but really it fixes 5262f567987d3
>>>>> ("io_uring: IORING_OP_TIMEOUT support") which is not in the stable tree.
>>>>>
>>>>>> a1f58ba46f794b1168d1107befcf3d4b9f9fd453
>>>>>
>>>>> Same as the commit above.
>>>>
>>>> Oh man, sorry about that, I always forget to check if all of them are in
>>>> 5.3. I blame the fact that I backport everything to our internal tree,
>>>> which is 5.2 based. But yes, you are of course right, those three can be
>>>> dropped.
>>>
>>> How much "secret sauce" does your internal tree have? Is it something
>>> we can peek into to make sure we don't miss fixes?
>>
>> There's no secret sauce in the internal tree, it's just that I backport
>> everything into the 5.2 version that is our newest. It's fully uptodate
>> with 5.4-rc and in some cases what's queued up for 5.5 as well. Hence I
>> sometimes forget to check what is applicable to 5.3-stable, since I have
>> it in our 5.2 tree...
>>
>> The internal tree is just backports. That's how we do things.
> 
> Could you push it somewhere public? I could automate grabbing fixes off
> of it.

There a few reasons why that hasn't been done, and none of them are
related to the actual code/patches in there..

But I don't think it would help you. The io_uring branch is a mix of
things that have gone into the current window (and may or may not need
to go to stable), and things that are queued up for the next kernel
versions (and aren't going to stable). This will just continue to drift
from stable, until we respin a new kernel version internally.

-- 
Jens Axboe

Re: io_uring stable 5.3 backports

[Sasha Levin]

On Sun, Oct 27, 2019 at 10:18:12AM -0600, Jens Axboe wrote:
>On 10/27/19 8:24 AM, Sasha Levin wrote:
>> On Sun, Oct 27, 2019 at 08:03:09AM -0600, Jens Axboe wrote:
>>> On 10/27/19 7:48 AM, Sasha Levin wrote:
>>>> On Sun, Oct 27, 2019 at 06:01:03AM -0600, Jens Axboe wrote:
>>>>> On 10/27/19 2:52 AM, Sasha Levin wrote:
>>>>>> On Sat, Oct 26, 2019 at 05:33:41PM -0600, Jens Axboe wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> For some reason I forgot to mark these stable, but they should go
>>>>>>> into stable. In order of applying them, they are:
>>>>>>>
>>>>>>> bc808bced39f4e4b626c5ea8c63d5e41fce7205a
>>>>>>
>>>>>> This commit says it fixes c576666863b78 ("io_uring: optimize
>>>>>> submit_and_wait API") which is not in the stable tree.
>>>>>>
>>>>>>> ef03681ae8df770745978148a7fb84796ae99cba
>>>>>>
>>>>>> This commit doesn't say so, but really it fixes 5262f567987d3
>>>>>> ("io_uring: IORING_OP_TIMEOUT support") which is not in the stable tree.
>>>>>>
>>>>>>> a1f58ba46f794b1168d1107befcf3d4b9f9fd453
>>>>>>
>>>>>> Same as the commit above.
>>>>>
>>>>> Oh man, sorry about that, I always forget to check if all of them are in
>>>>> 5.3. I blame the fact that I backport everything to our internal tree,
>>>>> which is 5.2 based. But yes, you are of course right, those three can be
>>>>> dropped.
>>>>
>>>> How much "secret sauce" does your internal tree have? Is it something
>>>> we can peek into to make sure we don't miss fixes?
>>>
>>> There's no secret sauce in the internal tree, it's just that I backport
>>> everything into the 5.2 version that is our newest. It's fully uptodate
>>> with 5.4-rc and in some cases what's queued up for 5.5 as well. Hence I
>>> sometimes forget to check what is applicable to 5.3-stable, since I have
>>> it in our 5.2 tree...
>>>
>>> The internal tree is just backports. That's how we do things.
>>
>> Could you push it somewhere public? I could automate grabbing fixes off
>> of it.
>
>There a few reasons why that hasn't been done, and none of them are
>related to the actual code/patches in there..
>
>But I don't think it would help you. The io_uring branch is a mix of
>things that have gone into the current window (and may or may not need
>to go to stable), and things that are queued up for the next kernel
>versions (and aren't going to stable). This will just continue to drift
>from stable, until we respin a new kernel version internally.

My thinking here was that:

1. I have a bunch of scripts that determine whether a given patch is
relevant to any stable kernel branch.
2. I have a machine learning toy that can help me kick patches for
review.

Running both on your tree means I can (let's say once a week) get a list
of probably fixes that are in your tree but are not in upstream stable
trees and might need to be there.

-- 
Thanks,
Sasha

Re: io_uring stable 5.3 backports

[Jens Axboe]

On 10/27/19 12:10 PM, Sasha Levin wrote:
> On Sun, Oct 27, 2019 at 10:18:12AM -0600, Jens Axboe wrote:
>> On 10/27/19 8:24 AM, Sasha Levin wrote:
>>> On Sun, Oct 27, 2019 at 08:03:09AM -0600, Jens Axboe wrote:
>>>> On 10/27/19 7:48 AM, Sasha Levin wrote:
>>>>> On Sun, Oct 27, 2019 at 06:01:03AM -0600, Jens Axboe wrote:
>>>>>> On 10/27/19 2:52 AM, Sasha Levin wrote:
>>>>>>> On Sat, Oct 26, 2019 at 05:33:41PM -0600, Jens Axboe wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> For some reason I forgot to mark these stable, but they should go
>>>>>>>> into stable. In order of applying them, they are:
>>>>>>>>
>>>>>>>> bc808bced39f4e4b626c5ea8c63d5e41fce7205a
>>>>>>>
>>>>>>> This commit says it fixes c576666863b78 ("io_uring: optimize
>>>>>>> submit_and_wait API") which is not in the stable tree.
>>>>>>>
>>>>>>>> ef03681ae8df770745978148a7fb84796ae99cba
>>>>>>>
>>>>>>> This commit doesn't say so, but really it fixes 5262f567987d3
>>>>>>> ("io_uring: IORING_OP_TIMEOUT support") which is not in the stable tree.
>>>>>>>
>>>>>>>> a1f58ba46f794b1168d1107befcf3d4b9f9fd453
>>>>>>>
>>>>>>> Same as the commit above.
>>>>>>
>>>>>> Oh man, sorry about that, I always forget to check if all of them are in
>>>>>> 5.3. I blame the fact that I backport everything to our internal tree,
>>>>>> which is 5.2 based. But yes, you are of course right, those three can be
>>>>>> dropped.
>>>>>
>>>>> How much "secret sauce" does your internal tree have? Is it something
>>>>> we can peek into to make sure we don't miss fixes?
>>>>
>>>> There's no secret sauce in the internal tree, it's just that I backport
>>>> everything into the 5.2 version that is our newest. It's fully uptodate
>>>> with 5.4-rc and in some cases what's queued up for 5.5 as well. Hence I
>>>> sometimes forget to check what is applicable to 5.3-stable, since I have
>>>> it in our 5.2 tree...
>>>>
>>>> The internal tree is just backports. That's how we do things.
>>>
>>> Could you push it somewhere public? I could automate grabbing fixes off
>>> of it.
>>
>> There a few reasons why that hasn't been done, and none of them are
>> related to the actual code/patches in there..
>>
>> But I don't think it would help you. The io_uring branch is a mix of
>> things that have gone into the current window (and may or may not need
>> to go to stable), and things that are queued up for the next kernel
>> versions (and aren't going to stable). This will just continue to drift
>>from stable, until we respin a new kernel version internally.
> 
> My thinking here was that:
> 
> 1. I have a bunch of scripts that determine whether a given patch is
> relevant to any stable kernel branch.
> 2. I have a machine learning toy that can help me kick patches for
> review.
> 
> Running both on your tree means I can (let's say once a week) get a list
> of probably fixes that are in your tree but are not in upstream stable
> trees and might need to be there.

If you want to play with it, I can certainly create a mirror of my 5.2
based io_uring FB branch and push it somewhere. Whenever I add to the FB
branch, I'll add to the public one as well so they will stay in sync.

Only concern is that on at least on occassion, I ended up pushing a
patch to the FB repo too soon. That then results in something like this:

commit 4c5a7042904f689d981ef6faa45f6a09e8669db1
Author: Jens Axboe <axboe@kernel.dk>
Date:   Thu Oct 17 16:32:06 2019 -0600

    io_uring: fixup "io_uring: fix up O_NONBLOCK handling for sockets"
    
    Matches the offending commit with upstream commit 491381ce07ca.
    
    Fixes: 0d79665c5f18 ("io_uring: fix up O_NONBLOCK handling for sockets")
    Signed-off-by: Jens Axboe <axboe@kernel.dk>

where I commit an incremental patch to sync with the patch that went
upstream, which differed slightly from what I had committed internally.
This is the only one of those I have.

Another one I have a single commit of is where I made an error doing
conflict resolution:

commit 5d79f6ee5f2ed5d0efc6e7698abed1516cd2c416
Author: Jens Axboe <axboe@kernel.dk>
Date:   Tue Oct 22 13:00:20 2019 -0600

    io_uring: fix merge error
    
    Due to a merge error, we never got 'ret' set in the common case.
    This hasn't caused any issues, and gcc is buggy and doesn't warn
    about it, but let's get it in there so we're synced with upstream.
    
    Signed-off-by: Jens Axboe <axboe@kernel.dk>

If you're fine with that, I can make the external copy of the FB
io_uring branch match the internal one.

-- 
Jens Axboe

Re: io_uring stable 5.3 backports

[Sasha Levin]

On Sun, Oct 27, 2019 at 12:54:23PM -0600, Jens Axboe wrote:
>On 10/27/19 12:10 PM, Sasha Levin wrote:
>> On Sun, Oct 27, 2019 at 10:18:12AM -0600, Jens Axboe wrote:
>>> On 10/27/19 8:24 AM, Sasha Levin wrote:
>>>> On Sun, Oct 27, 2019 at 08:03:09AM -0600, Jens Axboe wrote:
>>>>> On 10/27/19 7:48 AM, Sasha Levin wrote:
>>>>>> On Sun, Oct 27, 2019 at 06:01:03AM -0600, Jens Axboe wrote:
>>>>>>> On 10/27/19 2:52 AM, Sasha Levin wrote:
>>>>>>>> On Sat, Oct 26, 2019 at 05:33:41PM -0600, Jens Axboe wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> For some reason I forgot to mark these stable, but they should go
>>>>>>>>> into stable. In order of applying them, they are:
>>>>>>>>>
>>>>>>>>> bc808bced39f4e4b626c5ea8c63d5e41fce7205a
>>>>>>>>
>>>>>>>> This commit says it fixes c576666863b78 ("io_uring: optimize
>>>>>>>> submit_and_wait API") which is not in the stable tree.
>>>>>>>>
>>>>>>>>> ef03681ae8df770745978148a7fb84796ae99cba
>>>>>>>>
>>>>>>>> This commit doesn't say so, but really it fixes 5262f567987d3
>>>>>>>> ("io_uring: IORING_OP_TIMEOUT support") which is not in the stable tree.
>>>>>>>>
>>>>>>>>> a1f58ba46f794b1168d1107befcf3d4b9f9fd453
>>>>>>>>
>>>>>>>> Same as the commit above.
>>>>>>>
>>>>>>> Oh man, sorry about that, I always forget to check if all of them are in
>>>>>>> 5.3. I blame the fact that I backport everything to our internal tree,
>>>>>>> which is 5.2 based. But yes, you are of course right, those three can be
>>>>>>> dropped.
>>>>>>
>>>>>> How much "secret sauce" does your internal tree have? Is it something
>>>>>> we can peek into to make sure we don't miss fixes?
>>>>>
>>>>> There's no secret sauce in the internal tree, it's just that I backport
>>>>> everything into the 5.2 version that is our newest. It's fully uptodate
>>>>> with 5.4-rc and in some cases what's queued up for 5.5 as well. Hence I
>>>>> sometimes forget to check what is applicable to 5.3-stable, since I have
>>>>> it in our 5.2 tree...
>>>>>
>>>>> The internal tree is just backports. That's how we do things.
>>>>
>>>> Could you push it somewhere public? I could automate grabbing fixes off
>>>> of it.
>>>
>>> There a few reasons why that hasn't been done, and none of them are
>>> related to the actual code/patches in there..
>>>
>>> But I don't think it would help you. The io_uring branch is a mix of
>>> things that have gone into the current window (and may or may not need
>>> to go to stable), and things that are queued up for the next kernel
>>> versions (and aren't going to stable). This will just continue to drift
>>>from stable, until we respin a new kernel version internally.
>>
>> My thinking here was that:
>>
>> 1. I have a bunch of scripts that determine whether a given patch is
>> relevant to any stable kernel branch.
>> 2. I have a machine learning toy that can help me kick patches for
>> review.
>>
>> Running both on your tree means I can (let's say once a week) get a list
>> of probably fixes that are in your tree but are not in upstream stable
>> trees and might need to be there.
>
>If you want to play with it, I can certainly create a mirror of my 5.2
>based io_uring FB branch and push it somewhere. Whenever I add to the FB
>branch, I'll add to the public one as well so they will stay in sync.

I'd be happy to try. We already do something similar to distro trees, so
it's just a matter of adding this tree to the list.

>Only concern is that on at least on occassion, I ended up pushing a
>patch to the FB repo too soon. That then results in something like this:
>
>commit 4c5a7042904f689d981ef6faa45f6a09e8669db1
>Author: Jens Axboe <axboe@kernel.dk>
>Date:   Thu Oct 17 16:32:06 2019 -0600
>
>    io_uring: fixup "io_uring: fix up O_NONBLOCK handling for sockets"
>
>    Matches the offending commit with upstream commit 491381ce07ca.
>
>    Fixes: 0d79665c5f18 ("io_uring: fix up O_NONBLOCK handling for sockets")
>    Signed-off-by: Jens Axboe <axboe@kernel.dk>
>
>where I commit an incremental patch to sync with the patch that went
>upstream, which differed slightly from what I had committed internally.
>This is the only one of those I have.
>
>Another one I have a single commit of is where I made an error doing
>conflict resolution:
>
>commit 5d79f6ee5f2ed5d0efc6e7698abed1516cd2c416
>Author: Jens Axboe <axboe@kernel.dk>
>Date:   Tue Oct 22 13:00:20 2019 -0600
>
>    io_uring: fix merge error
>
>    Due to a merge error, we never got 'ret' set in the common case.
>    This hasn't caused any issues, and gcc is buggy and doesn't warn
>    about it, but let's get it in there so we're synced with upstream.
>
>    Signed-off-by: Jens Axboe <axboe@kernel.dk>
>
>If you're fine with that, I can make the external copy of the FB
>io_uring branch match the internal one.

Let's give it a go, I'll start by staying a week+ behind the tip and
audit any out of tree patches such as the above manually.


-- 
Thanks,
Sasha