diff options
author | Doug Ledford <dledford@redhat.com> | 2012-05-31 16:26:29 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2012-05-31 17:49:30 -0700 |
commit | 858ee3784e8105467f1f3017f4ece51cb51d4830 (patch) | |
tree | c95f55ff8bd29be3a8648acc21118a47b07d117b /ipc | |
parent | 93e6f119c0ce8a1bba6e81dc8dd97d67be360844 (diff) | |
download | kernel-common-858ee3784e8105467f1f3017f4ece51cb51d4830.tar.gz kernel-common-858ee3784e8105467f1f3017f4ece51cb51d4830.tar.bz2 kernel-common-858ee3784e8105467f1f3017f4ece51cb51d4830.zip |
ipc/mqueue: switch back to using non-max values on create
Commit b231cca4381e ("message queues: increase range limits") changed
how we create a queue that does not include an attr struct passed to
open so that it creates the queue with whatever the maximum values are.
However, if the admin has set the maximums to allow flexibility in
creating a queue (aka, both a large size and large queue are allowed,
but combined they create a queue too large for the RLIMIT_MSGQUEUE of
the user), then attempts to create a queue without an attr struct will
fail. Switch back to using acceptable defaults regardless of what the
maximums are.
Note: so far, we only know of a few applications that rely on this
behavior (specifically, set the maximums in /proc, then run the
application which calls mq_open() without passing in an attr struct, and
the application expects the newly created message queue to have the
maximum sizes that were set in /proc used on the mq_open() call, and all
of those applications that we know of are actually part of regression
test suites that were coded to do something like this:
for size in 4096 65536 $((1024 * 1024)) $((16 * 1024 * 1024)); do
echo $size > /proc/sys/fs/mqueue/msgsize_max
mq_open || echo "Error opening mq with size $size"
done
These test suites that depend on any behavior like this are broken. The
concept that programs should rely upon the system wide maximum in order
to get their desired results instead of simply using a attr struct to
specify what they want is fundamentally unfriendly programming practice
for any multi-tasking OS.
Fixing this will break those few apps that we know of (and those app
authors recognize the brokenness of their code and the need to fix it).
However, the following patch "mqueue: separate mqueue default value"
allows a workaround in the form of new knobs for the default msg queue
creation parameters for any software out there that we don't already
know about that might rely on this behavior at the moment.
Signed-off-by: Doug Ledford <dledford@redhat.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: Amerigo Wang <amwang@redhat.com>
Cc: Joe Korty <joe.korty@ccur.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'ipc')
-rw-r--r-- | ipc/mqueue.c | 5 |
1 files changed, 3 insertions, 2 deletions
diff --git a/ipc/mqueue.c b/ipc/mqueue.c index a2757d4ab773..b103022179a3 100644 --- a/ipc/mqueue.c +++ b/ipc/mqueue.c @@ -144,8 +144,9 @@ static struct inode *mqueue_get_inode(struct super_block *sb, info->qsize = 0; info->user = NULL; /* set when all is ok */ memset(&info->attr, 0, sizeof(info->attr)); - info->attr.mq_maxmsg = ipc_ns->mq_msg_max; - info->attr.mq_msgsize = ipc_ns->mq_msgsize_max; + info->attr.mq_maxmsg = min(ipc_ns->mq_msg_max, DFLT_MSG); + info->attr.mq_msgsize = + min(ipc_ns->mq_msgsize_max, DFLT_MSGSIZE); if (attr) { info->attr.mq_maxmsg = attr->mq_maxmsg; info->attr.mq_msgsize = attr->mq_msgsize; |