Re: [PATCH v2] io_uring: provide fallback request for OOM situations

[Bob Liu <bob.liu@oracle.com>]

On 11/18/19 10:32 PM, Jens Axboe wrote:
> On 11/17/19 11:57 PM, Bob Liu wrote:
>> On 11/9/19 5:25 AM, Jens Axboe wrote:
>>> One thing that really sucks for userspace APIs is if the kernel passes
>>> back -ENOMEM/-EAGAIN for resource shortages. The application really has
>>> no idea of what to do in those cases. Should it try and reap
>>> completions? Probably a good idea. Will it solve the issue? Who knows.
>>>
>>> This patch adds a simple fallback mechanism if we fail to allocate
>>> memory for a request. If we fail allocating memory from the slab for a
>>> request, we punt to a pre-allocated request. There's just one of these
>>> per io_ring_ctx, but the important part is if we ever return -EBUSY to
>>> the application, the applications knows that it can wait for events and
>>> make forward progress when events have completed. This is the important
>>> part.
>>>
>>
>> I'm lost how -EBUSY will be returned if allocating from the pre-allocated request.
>> Could you please explain a bit more?
> 
> The patch actually returns -EAGAIN, not -EBUSY... The last -EBUSY
> mention in that commit message should be -EAGAIN.
> 
> But the point is that if you get a busy return back, then you know that
> things are moving forward as we have a backup request. This is a similar
> concept to the mempools we have in the kernel, have any kind of reserve
> guarantees forward progress.
> 

I see.
But there are two more potential place may fail to allocate memory,
'shadow_req = io_get_req()' and 'sqe_copy = kmalloc()'.

We may need one more pre-allocated request and make sure pre-allocated req can't be deferred?
So as to guarantee things can really moving forward.