Re: Backporting to stable... Re: [GIT PULL] io_uring thread worker change

[Jens Axboe <axboe@kernel.dk>]

On 3/11/21 3:43 AM, Stefan Metzmacher wrote:
> Hi Jens,
> 
>> I'm sure we're going to find little things to patch up after this
>> series, but testing has been pretty thorough, from the usual regression
>> suite to production. Any issue that may crop up should be manageable.
>> There's also a nice series of further reductions we can do on top of
>> this, but I wanted to get the meat of it out sooner rather than later.
>> The general worry here isn't that it's fundamentally broken. Most of the
>> little issues we've found over the last week have been related to just
>> changes in how thread startup/exit is done, since that's the main
>> difference between using kthreads and these kinds of threads. In fact,
>> if all goes according to plan, I want to get this into the 5.10 and 5.11
>> stable branches as well.
> 
> That would mean that IORING_FEAT_SQPOLL_NONFIXED would be implicitly
> be backported from 5.11 to 5.10, correct?

Right, that would happen by default if we moved the new worker code back
to 5.10 and 5.11.

> I'm wondering if I can advice people to move to 5.10 (as it's an lts
> release) in order to get a kernel that is most likely very useful to
> use in combination with Samba's drafted usage of io_uring, where I'd
> like to use IORING_FEAT_SQPOLL_NONFIXED and IORING_FEAT_NATIVE_WORKERS
> in order to use SENDMSG/RECVMSG with msg_control buffers (where the
> control buffers may reference file descriptors).

Understandable! It's worth nothing that 5.10 would also need a backport
of the TIF_NOTIFY_SIGNAL change - could be done without, but then we'd
have diverging code bases to some degree, which would be something I'd
love to avoid.

-- 
Jens Axboe