Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH] io_uring: store back buffer in case of failure
To:     Jens Axboe <axboe@kernel.dk>,
        Olivier Langlois <olivier@trillion01.com>,
        io-uring@vger.kernel.org, linux-kernel@vger.kernel.org
References: <60c83c12.1c69fb81.e3bea.0806SMTPIN_ADDED_MISSING@mx.google.com>
 <93256513-08d8-5b15-aa98-c1e83af60b54@gmail.com>
 <b5b37477-985e-54da-fc34-4de389112365@kernel.dk>
 <4f32f06306eac4dd7780ed28c06815e3d15b43ad.camel@trillion01.com>
 <af2f7aa0-271f-ba70-8c6b-f6c6118e6f1f@gmail.com>
 <6bf916b4-ba6f-c401-9e8b-341f9a7b88f7@kernel.dk>
From:   Pavel Begunkov <asml.silence@gmail.com>
Message-ID: <5007a641-23cf-195d-87ee-de193e19dc20@gmail.com>
Date:   Wed, 16 Jun 2021 16:37:50 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <6bf916b4-ba6f-c401-9e8b-341f9a7b88f7@kernel.dk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

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