On 11/19/19 1:51 PM, Pavel Begunkov wrote:
> On 16/11/2019 04:53, Jens Axboe wrote:
>> We have an issue with timeout links that are deeper in the submit chain,
>> because we only handle it upfront, not from later submissions. Move the
>> prep + issue of the timeout link to the async work prep handler, and do
>> it normally for non-async queue. If we validate and prepare the timeout
>> links upfront when we first see them, there's nothing stopping us from
>> supporting any sort of nesting.
>>
>> Fixes: 2665abfd757f ("io_uring: add support for linked SQE timeouts")
>> Reported-by: Pavel Begunkov <asml.silence@xxxxxxxxx>
>> Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
>> ---
>
>> @@ -923,6 +942,7 @@ static void io_fail_links(struct io_kiocb *req)
>> io_cqring_fill_event(link, -ECANCELED);
>> __io_double_put_req(link);
>> }
>> + kfree(sqe_to_free);
>> }
>>
>> io_commit_cqring(ctx);
>> @@ -2668,8 +2688,12 @@ static void io_wq_submit_work(struct io_wq_work **workptr)
>>
>> /* if a dependent link is ready, pass it back */
>> if (!ret && nxt) {
>> - io_prep_async_work(nxt);
>> + struct io_kiocb *link;
>> +
>> + io_prep_async_work(nxt, &link);
>> *workptr = &nxt->work;
> Are we safe here without synchronisation?
> Probably io_link_timeout_fn() may miss the new value
> (doing io-wq cancel).
Miss what new value? Don't follow that part.
This should be safe, by the time the request is findable, we have
made the necessary setup in io_prep_async_work().
--
Jens Axboe
