ipc/mqueue: cleanup definition names and locations

ipc/mqueue: cleanup definition names and locations

Since commit b231cca4381 ("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
b231cca4381 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: Doug Ledford <dledford@redhat.com>
Acked-by: 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>