mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Doug Ledford <dledford@redhat.com>
To: akpm@linux-foundation.org, torvalds@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, joe.korty@ccur.com, amwang@redhat.com
Subject: Various cleanups and a couple fixes to ipc/mqueue
Date: Tue, 27 Sep 2011 18:30:09 -0400	[thread overview]
Message-ID: <1317162613-11060-1-git-send-email-dledford@redhat.com> (raw)

We had a customer come up with a problem while trying to upgrade from
our 2.6.18 kernel to our 2.6.32 kernel.  In diagnosing their problem,
it was determined that when commit b231cca4 changed the msg size max
from INT_MAX to 8192*128, that's what broke their setup.  While fixing
this problem, testing showed that if you increase the max values of a
msg queue, then attempt to create one without an attr struct passed in
to the open call, it could fail because it sets the queue size to the
max of both the msg size and queue size.  If these are large enough,
they over run the default RLIMIT_MSGQUEUE.  This change was also
introduced in the b231cca4 commit.  We then found that the msg queue
limits were not all being enforced on CAP_SYS_RESOURCE apps.  Finally,
we found that commit 9cf18e1d fiddled with HARD_MSGMAX without
realizing that the reason it was set to what it was, was to avoid
trying to kmalloc a chunk larger than 128K.  So, this series of
patches cleans up the various defines, takes us back to having a
larger HARD_MSGSIZEMAX, goes back to using a separate define for the
case where a user doesn't pass in an attr struct in case the maxes
have been raised too large for RLIMIT_MSGQUEUE, enforces the maximums
on CAP_SYS_RESOURCE apps, uses vmalloc instead of kmalloc when the
msg pointer array is too large, and documents all of this so it
shouldn't happen again.

Authors of the two original commits have been Cc:ed in case they want
to have any input.

Patches are also available via git at:

git://github.com/dledford/linux.git upstream/mqueue

[PATCH 1/4] ipc/mqueue: cleanup definition names and locations
[PATCH 2/4] ipc/mqueue: switch back to using non-max values on
[PATCH 3/4] ipc/mqueue: enforce hard limits
[PATCH 4/4] ipc/mqueue: update maximums for the mqueue subsystem

 include/linux/ipc_namespace.h |   40 +++++++++++++++++++++++++++++++++++-----
 ipc/mq_sysctl.c               |   31 ++++++++-----------------------
 ipc/mqueue.c                  |   23 ++++++++++++++++-------
 3 files changed, 59 insertions(+), 35 deletions(-)

--
Doug Ledford <dledford@redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford


             reply	other threads:[~2011-09-27 22:30 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-27 22:30 Doug Ledford [this message]
2011-09-27 22:30 ` [PATCH 1/4] ipc/mqueue: cleanup definition names and locations Doug Ledford
2011-09-27 22:30 ` [PATCH 2/4] ipc/mqueue: switch back to using non-max values on create Doug Ledford
2011-10-25  0:56   ` KOSAKI Motohiro
2011-10-26 15:36     ` KOSAKI Motohiro
     [not found]     ` <4EA828E4.1070409@gmail.com>
2011-10-26 15:37       ` [PATCH 5/4] ipc/mqueue: revert bump up DFLT_*MAX KOSAKI Motohiro
2011-10-26 17:28         ` Doug Ledford
2011-10-27 16:41         ` Joe Korty
2011-10-26 15:37       ` [PATCH 6/4] ipc/mqueue: don't use kmalloc(KMALLOC_MAX_SIZE) KOSAKI Motohiro
2011-10-26 17:29         ` Doug Ledford
2011-10-27 16:41         ` Joe Korty
2011-10-26 15:38       ` [PATCH 7/4] ipc/mqueue: separate mqueue default value from maximum value KOSAKI Motohiro
2011-10-26 17:31         ` Doug Ledford
2011-10-27 16:44         ` Joe Korty
2011-09-27 22:30 ` [PATCH 3/4] ipc/mqueue: enforce hard limits Doug Ledford
2011-09-27 22:30 ` [PATCH 4/4] ipc/mqueue: update maximums for the mqueue subsystem Doug Ledford
2011-10-25  1:00   ` KOSAKI Motohiro

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=1317162613-11060-1-git-send-email-dledford@redhat.com \
    --to=dledford@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=amwang@redhat.com \
    --cc=joe.korty@ccur.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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

all inboxes | Powered by JetHome®