On 3/4/21 12:54 PM, Jens Axboe wrote:
> On 3/4/21 12:46 PM, Linus Torvalds wrote:
>> On Thu, Mar 4, 2021 at 11:19 AM Jens Axboe <axboe@xxxxxxxxx> wrote:
>>>
>>> Took a quick look at this, and I agree that's _much_ better. In fact, it
>>> boils down to just calling copy_process() and then having the caller do
>>> wake_up_new_task(). So not sure if it's worth adding an
>>> create_io_thread() helper, or just make copy_process() available
>>> instead. This is ignoring the trace point for now...
>>
>> I really don't want to expose copy_process() outside of kernel/fork.c.
>>
>> The whole three-phase "copy - setup - activate" model is a really
>> really good thing, and it's how we've done things internally almost
>> forever, but I really don't want to expose those middle stages to any
>> outsiders.
>>
>> So I'd really prefer a simple new "create_io_worker()", even if it's
>> literally just some four-line function that does
>>
>> p = copy_process(..);
>> if (!IS_ERR(p)) {
>> block all signals in p
>> set PF_IO_WORKER flag
>> wake_up_new_task(p);
>> }
>> return p;
>>
>> I very much want that to be inside kernel/fork.c and have all these
>> rules about creating new threads localized there.
>
> I agree, here are the two current patches. Just need to add the signal
> blocking, which I'd love to do in create_io_thread(), but seems to
> require either an allocation or provide a helper to do it in the thread
> itself (with an on-stack mask).
Nevermind, it's actually copied, so we can do it in create_io_thread().
I know you'd prefer not to expose the 'task created but not active' state,
but:
1) That allows us to do further setup in the creator and hence eliminate
wait+complete for that
2) It's not exported, so not available to drivers etc.
--
Jens Axboe
