Re: [PATCH] aio: Fix return code of io_submit() (RFC)

From: Jens Axboe
Date: Fri Oct 03 2014 - 14:36:19 EST


On 2014-10-03 12:22, Benjamin LaHaise wrote:
On Fri, Oct 03, 2014 at 12:13:39PM -0600, Jens Axboe wrote:
On 2014-10-03 12:08, Kent Overstreet wrote:
io_submit() could return -EAGAIN on memory allocation failure when it
should
really have been returning -ENOMEM. This could confuse applications (i.e.
fio)
since -EAGAIN means "too many requests outstanding, wait until completions
have
been reaped" and if the application actually was tracking outstanding
completions this wouldn't make a lot of sense.

NOTE:

the man page seems to imply that the current behaviour (-EAGAIN on
allocation
failure) has always been the case. I don't think it makes a lot of sense,
but
this should probably be discussed more widely in case applications have
somehow
come to rely on the current behaviour...

We can't really feasibly fix this, is my worry. Fio does track the
pending requests and does not get into a getevents() forever wait if it
gets -EAGAIN on submission. But before the fix, it would loop forever in
submission in -EAGAIN.

There are lots of instances in the kernel where out of memory is potentially
exposed to the user. If we're failing a memory allocation that is well under
1KB, the system is probably completely hosed.

How are applications supposed to deal with ENOMEM? I think the answer
here is that they can't, it would be a fatal condition. AIO must provide
isn't own guarantee of progress, with a mempool or similar.

I'm not sure if using a mempool is appropriate for allocations that are
driven by userland code. At least with an ENOMEM error, an application
could free up some of the memory it allocated and possibly recover the
system.

Since fio just hit this, it has nothing it can potentially free to make progress possible. There was no pending IO, so all it can do is quit. But I do agree that if a small alloc like that fails, then we are probably pretty darn screwed anyway, and it doesn't matter that much what we do. My main concern was a potential change in the ABI, but since we could already return -ENOMEM from other cases, that is probably a moot point.

--
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/