From: Doug Ledford <dledford@redhat.com>
To: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
sfr@canb.auug.org.au
Subject: Re: [Patch 3/4] ipc/mqueue: strengthen checks on mqueue creation
Date: Tue, 01 May 2012 16:11:31 -0400 [thread overview]
Message-ID: <4FA04373.6090100@redhat.com> (raw)
In-Reply-To: <4FA04131.2040004@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2908 bytes --]
On 05/01/2012 04:01 PM, KOSAKI Motohiro wrote:
> (5/1/12 1:50 PM), Doug Ledford wrote:
>> We already check the mq attr struct if it's passed in, but now that the
>> admin can set system wide defaults separate from maximums, it's actually
>> possible to set the defaults to something that would overflow. So,
>> if there is no attr struct passed in to the open call, check the default
>> values.
>>
>> While we are at it, simplify mq_attr_ok() by making it return 0 or an
>> error condition, so that way if we add more tests to it later, we have
>> the option of what error should be returned instead of the calling
>> location having to pick a possibly inaccurate error code.
>>
>> Signed-off-by: Doug Ledford<dledford@redhat.com>
>> ---
>> ipc/mqueue.c | 27 ++++++++++++++++++---------
>> 1 files changed, 18 insertions(+), 9 deletions(-)
>>
>> diff --git a/ipc/mqueue.c b/ipc/mqueue.c
>> index 4b2892e..6089f73 100644
>> --- a/ipc/mqueue.c
>> +++ b/ipc/mqueue.c
>> @@ -673,27 +673,27 @@ static int mq_attr_ok(struct ipc_namespace *ipc_ns, struct mq_attr *attr)
>> int mq_treesize;
>>
>> if (attr->mq_maxmsg<= 0 || attr->mq_msgsize<= 0)
>> - return 0;
>> + return -EINVAL;
>> if (capable(CAP_SYS_RESOURCE)) {
>> if (attr->mq_maxmsg> HARD_MSGMAX ||
>> attr->mq_msgsize> HARD_MSGSIZEMAX)
>> - return 0;
>> + return -EINVAL;
>> } else {
>> if (attr->mq_maxmsg> ipc_ns->mq_msg_max ||
>> attr->mq_msgsize> ipc_ns->mq_msgsize_max)
>> - return 0;
>> + return -EINVAL;
>> }
>> /* check for overflow */
>> if (attr->mq_msgsize> ULONG_MAX/attr->mq_maxmsg)
>> - return 0;
>> + return -ENOMEM;
>> mq_treesize = attr->mq_maxmsg * sizeof(struct msg_msg) +
>> min_t(unsigned int, attr->mq_maxmsg, MQ_PRIO_MAX) *
>> sizeof(struct posix_msg_tree_node);
>> if ((unsigned long)(attr->mq_maxmsg * attr->mq_msgsize +
>> mq_treesize)<
>> (unsigned long)(attr->mq_maxmsg * attr->mq_msgsize))
>> - return 0;
>> - return 1;
>> + return -ENOMEM;
>> + return 0;
>
> But ENOMEM is more inaccurate. It almostly is used for kmalloc failure.
I chose ENOMEM for that particular error because above there we have
checked the passed in arguments to make sure that they don't violate our
allowances for max message or max message size. If we violate either of
those items, we return EINVAL. In this case, neither of the values is
invalid, it's just that together they make an overly large allocation.
I would see that as more helpful to a programmer than EINVAL when the
values are within the maximums allowed. At least with ENOMEM the
programmer knows they have to reduce their combined message size and
message count in order to get things working.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: 0E572FDD
http://people.redhat.com/dledford
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
next prev parent reply other threads:[~2012-05-01 20:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-01 17:50 [Patch 0/4] ipc/mqueue improvements Doug Ledford
2012-05-01 17:50 ` [Patch 1/4] ipc/mqueue: improve performance of send/recv Doug Ledford
2012-05-01 17:50 ` [Patch 2/4] ipc/mqueue: correct mq_attr_ok test Doug Ledford
2012-05-01 19:34 ` Andrew Morton
2012-05-01 19:38 ` Doug Ledford
2012-05-01 17:50 ` [Patch 3/4] ipc/mqueue: strengthen checks on mqueue creation Doug Ledford
2012-05-01 20:01 ` KOSAKI Motohiro
2012-05-01 20:11 ` Doug Ledford [this message]
2012-05-01 20:18 ` KOSAKI Motohiro
2012-05-01 23:02 ` Doug Ledford
2012-05-01 23:04 ` KOSAKI Motohiro
2012-05-01 23:11 ` Andrew Morton
2012-05-01 17:50 ` [Patch 4/4] tools/selftests: add mq_perf_tests Doug Ledford
2012-05-01 19:53 ` Andrew Morton
2012-05-01 20:14 ` Doug Ledford
2012-05-03 9:21 ` [Patch 1/4] ipc/mqueue: improve performance of send/recv Dan Carpenter
2012-05-03 13:03 ` Doug Ledford
2012-05-03 10:05 ` Nick Piggin
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=4FA04373.6090100@redhat.com \
--to=dledford@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=kosaki.motohiro@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
/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