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
