From: Jiri Slaby <jslaby@suse.cz>
To: Doug Ledford <dledford@xsintricity.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [Patch] Fix up return value from mq_open()
Date: Fri, 30 Sep 2011 08:40:54 +0200 [thread overview]
Message-ID: <4E856476.6060808@suse.cz> (raw)
In-Reply-To: <4E85263D.3030905@xsintricity.com>
On 09/30/2011 04:15 AM, Doug Ledford wrote:
> Commit d40dcdb ipc/mqueue.c: fix mq_open() return value
> changed the return value for mq_open() to return
>
> EMFILE - The process already has the maximum number of files and
> message queues open.
>
> instead of
>
> ENOMEM - Insufficient memory.
>
> While the portion of d40dcdb that introduced using ERR_PTR() to
> propagate the condition were helpful, the change to the type of error
> was not. The specific test that was failing was a memory space test.
> It can fail if there are too many message queues open and this one would
> cause us to exceed the tasks counter for memory bytes capacity (aka, int
> wrap) or it can fail if the total number of bytes already allocated plus
> this allocation will exceed the user's RLIMIT for POSIX message queues.
Yes, then it should not definitely return ENOMEM, right? You exceeded a
limit, not ran out of memory. At least for the latter case.
> However, depending on the values passed in via an attribute struct,
> this could happen on the 1st file or the 100th file. There is no direct
> relationship to file count in this test. There is only a direct
> correlation to memory usage. Therefore return the code to giving ENOMEM
> instead of EMFILE.
...
> commit b80e4058e2b4234fb33a9fd84b4ce288e8ba65cb
> Author: Doug Ledford <dledford@redhat.com>
> Date: Thu Sep 29 19:02:47 2011 -0400
>
> ipc/mqueue: make the error returns match the conditions
>
> We should not return -EMFILE when the problem is memory usage.
Sorry, I still don't udnerstand, how this test:
u->mq_bytes + mq_bytes > task_rlimit(p, RLIMIT_MSGQUEUE)
is about running out of memory. I see only a test for exceeding some
quota. Should this be changed, change it to something like ENOSPC.
> diff --git a/ipc/mqueue.c b/ipc/mqueue.c
> index 0474ddb..3e53604 100644
> --- a/ipc/mqueue.c
> +++ b/ipc/mqueue.c
> @@ -165,7 +165,7 @@ static struct inode *mqueue_get_inode(struct super_block *sb,
> u->mq_bytes + mq_bytes > task_rlimit(p, RLIMIT_MSGQUEUE)) {
> spin_unlock(&mq_lock);
> /* mqueue_evict_inode() releases info->messages */
> - ret = -EMFILE;
> + ret = -ENOMEM;
The code now looks like:
int ret = -ENOMEM;
...
if (sth)
ret = -ENOMEM;
...
return ret;
which is not good.
thanks,
--
js
suse labs
next prev parent reply other threads:[~2011-09-30 6:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-30 2:15 [Patch] Fix up return value from mq_open() Doug Ledford
2011-09-30 6:40 ` Jiri Slaby [this message]
2011-09-30 10:56 ` Doug Ledford
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=4E856476.6060808@suse.cz \
--to=jslaby@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=dledford@xsintricity.com \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox