On 6/16/21 3:44 PM, Jens Axboe wrote: > On 6/16/21 8:01 AM, Pavel Begunkov wrote: >> On 6/16/21 2:42 PM, Olivier Langlois wrote: >>> On Tue, 2021-06-15 at 15:51 -0600, Jens Axboe wrote: >>>> Ditto for this one, don't see it in my email nor on the list. >>>> >>> I can resend you a private copy of this one but as Pavel pointed out, >>> it contains fatal flaws. >>> >>> So unless someone can tell me that the idea is interesting and has >>> potential and can give me some a hint or 2 about how to address the >>> challenges to fix the current flaws, it is pretty much a show stopper >>> to me and I think that I am going to let it go... >> >> It'd need to go through some other context, e.g. task context. >> task_work_add() + custom handler would work, either buf-select >> synchronisation can be reworked, but both would rather be >> bulky and not great. > > Indeed - that'd solve both the passing around of locking state which > I really don't like, and make it much simpler. Just use task work for > the re-insert, and you can grab the ring lock unconditionally from > there. Hmm, it might be much simpler than I thought if we allocate a separate struct callback_head, i.e. task_work, queued it with exactly task_work_add() but not io_req_task_work_add(), and continue with the request handler. -- Pavel Begunkov
