All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Benjamin LaHaise <bcrl@kvack.org>
Cc: Kent Overstreet <kmo@daterainc.com>,
	linux-kernel@vger.kernel.org, Zach Brown <zab@zabbo.net>,
	Jeff Moyer <jmoyer@redhat.com>, Slava Pestov <sp@daterainc.com>
Subject: Re: [PATCH] aio: Fix return code of io_submit() (RFC)
Date: Fri, 03 Oct 2014 12:36:10 -0600	[thread overview]
Message-ID: <542EEC9A.3090308@kernel.dk> (raw)
In-Reply-To: <20141003182220.GA17057@kvack.org>

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


  parent reply	other threads:[~2014-10-03 18:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-03 18:08 [PATCH] aio: Fix return code of io_submit() (RFC) Kent Overstreet
2014-10-03 18:13 ` Jens Axboe
2014-10-03 18:21   ` Kent Overstreet
2014-10-03 18:25     ` Jens Axboe
2014-10-03 18:22   ` Benjamin LaHaise
2014-10-03 18:31     ` Kent Overstreet
2014-10-03 18:39       ` Jens Axboe
2014-10-03 18:36     ` Jens Axboe [this message]
2014-10-03 18:19 ` Benjamin LaHaise

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=542EEC9A.3090308@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=bcrl@kvack.org \
    --cc=jmoyer@redhat.com \
    --cc=kmo@daterainc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sp@daterainc.com \
    --cc=zab@zabbo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.