• Doug Ledford's avatar
    ipc/mqueue: cleanup definition names and locations · 93e6f119
    Doug Ledford authored
    Since commit b231cca4 ("message queues: increase range limits") on
    Oct 18, 2008, calls to mq_open() that did not pass in an attribute
    struct and expected to get default values for the size of the queue and
    the max message size now get the system wide maximums instead of
    hardwired defaults like they used to get.
    This was uncovered when one of the earlier patches in this patch set
    increased the default system wide maximums at the same time it increased
    the hard ceiling on the system wide maximums (a customer specifically
    needed the hard ceiling brought back up, the new ceiling that commit
    b231cca4 introduced was too low for their production systems).  By
    increasing the default maximums and not realising they were tied to any
    attempt to create a message queue without an attribute struct, I had
    inadvertently made it such that all message queue creation attempts
    without an attribute struct were failing because the new default
    maximums would create a queue that exceeded the default rlimit for
    message queue bytes.
    As a result, the system wide defaults were brought back down to their
    previous levels, and the system wide ceilings on the maximums were
    raised to meet the customer's needs.  However, the fact that the no
    attribute struct behavior of mq_open() could be broken by changing the
    system wide maximums for message queues was seen as fundamentally broken
    itself.  So we hardwired the no attribute case back like it used to be.
    But, then we realized that on the very off chance that some piece of
    software in the wild depended on that behavior, we could work around
    that issue by adding two new knobs to /proc that allowed setting the
    defaults for message queues created without an attr struct separately
    from the system wide maximums.
    What is not an option IMO is to leave the current behavior in place.  No
    piece of software should ever rely on setting the system wide maximums
    in order to get a desired message queue.  Such a reliance would be so
    fundamentally multitasking OS unfriendly as to not really be tolerable.
    Fortunately, we don't know of any software in the wild that uses this
    except for a regression test program that caught the issue in the first
    place.  If there is though, we have made accommodations with the two new
    /proc knobs (and that's all the accommodations such fundamentally broken
    software can be allowed)..
    This patch:
    The various defines for minimums and maximums of the sysctl controllable
    mqueue values are scattered amongst different files and named
    inconsistently.  Move them all into ipc_namespace.h and make them have
    consistent names.  Additionally, make the number of queues per namespace
    also have a minimum and maximum and use the same sysctl function as the
    other two settable variables.
    Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
    Acked-by: default avatarSerge 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: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Manfred Spraul <manfred@colorfullife.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
mq_sysctl.c 2.28 KB