Messages in this thread | | | Date | Wed, 14 Mar 2012 17:28:33 -0400 | From | Doug Ledford <> | Subject | Re: [resend][PATCH 1/3] mqueue: revert bump up DFLT_*MAX |
| |
On 12/18/2011 01:38 PM, Andrew Morton wrote: > On Sun, 18 Dec 2011 13:29:56 -0500 KOSAKI Motohiro <kosaki.motohiro@gmail.com> wrote: > >> (12/9/11 5:35 PM), kosaki.motohiro@gmail.com wrote: >>> From: KOSAKI Motohiro<kosaki.motohiro@jp.fujitsu.com> >>> >>> Mqueue limitation is slightly naieve parameter likes other ipcs >>> because unprivileged user can consume kernel memory by using ipcs. >>> >>> Thus, too aggressive raise bring us security issue. Example, >>> current setting allow evil unprivileged user use 256GB (= 256 >>> * 1024 * 1024*1024) and it's enough large to system will belome >>> unresponsive. Don't do that. >>> >>> Instead, every admin should adjust the knobs for their own systems. >>> >>> Signed-off-by: KOSAKI Motohiro<kosaki.motohiro@jp.fujitsu.com> >>> Acked-by: Doug Ledford<dledford@redhat.com> >>> Acked-by: Joe Korty<joe.korty@ccur.com> >>> Cc: Amerigo Wang<amwang@redhat.com> >>> Cc: Serge E. Hallyn<serue@us.ibm.com> >>> Cc: Jiri Slaby<jslaby@suse.cz> >> >> Andrew, can you please pick up this series into your tree? because your >> tree have related Doug mqueue patch series. > > Soon. I need to go back and read the email trail regarding Doug's patches.
This has obviously fallen through the cracks. Can we please see if we can get this put to bed.
Andrew, long and short of the story on this entire patch set is:
A) Current Linus kernel is broken in regards to customer needs, maximums are too low. B) My patch set upped maximums and also upped the default maximums on the system, but inadvertently also upped the default mqueue size the original patch that my entire patch set is more or less reverting tied maximums and defaults together. This broke some apps that didn't pass an attr struct to open as it caused a default sized mqueue to exceed a non-root RLIMIT for message queue bytes. C) My next patches brought defaults back down by decoupling defaults from maximums. This then broke some apps again that wanted to be able to fiddle with the maximum settings in /proc and have that modify the default value for an app that didn't pass an attr struct (fortunately, all of these apps appear to be nothing more than regression test suites at the moment where the people writing the suite used a combination of setting the maximum size in proc, then running a test program that created a default queue and checking it, then re-running with different sizes in /proc, etc). D) Motohiro and I argued for some time over this behavior until we both agreed that apps can not be written to rely upon the maximum setting of the system wide mqueue limits as their default queue size as this is fundamentally unfriendly behavior to any multi-application OS (the situation of two apps both needing specific, different queue sizes, and both expecting to get them by default by twiddling values in /proc is simply not supportable). In the end, we agreed that the best approach to solve the problem was to leave the defaults decoupled from the maximums, but add a default knob in /proc so that if there are any apps out there that have been coded to expect this behavior, then there is a workaround path for them until they get coded to use an attr struct on open instead of relying on values twiddled in /proc. This is what Motohiro's patch set does as well as a few other cleanups.
Hopefully that clears things up, and given the unsupportability of the current design in Linus' kernel (changing maximums changes defaults for all apps and encourages poor programming choices) we can move this forward please.
-- Doug Ledford <dledford@redhat.com> GPG KeyID: 0E572FDD http://people.redhat.com/dledford
[unhandled content-type:application/pgp-signature] | |