On 4/17/2012 7:00 PM, Andrew Morton wrote: > On Tue, 17 Apr 2012 18:32:25 -0400 > KOSAKI Motohiro wrote: > >>> Here the "future patch" is "mqueue: separate mqueue default value from >>> maximum value v2" in this series, yes? >>> >>> So people who have applications which are broken by this patch will >>> need to manually set /proc/sys/fs/mqueue/msg_default and/or >>> /proc/sys/fs/mqueue/msgsize_default to get those apps working again? >>> >> >> Yes, it works. >> > > OK, I updated the changelog for this patch to reflect that. > > I worry a bit that some people who we don't know about will hit this > problem and will have to spend a lot of time working out why it broke. > Is there some way in which we can make it easier for them? A little > printk_once() in a suitable place? It might be doable, although rather tricky. The deal is that we won't know on mq_open if they really wanted a default sized mq or a max sized mq. And we wouldn't even know on send if they wanted default or max sized mqs. The best we could do is flag an mq as being a no-attr-struct-used mq, then wait and see if they ever try to send too many or too large of a message to that mq, and then we could do a printk_once(), but we would almost need a printk_once_per_pid() because they could have more than one app guilty of this behavior (if any are guilty of it, something I doubt). But even with all of this, we wouldn't necessarily know that the app was intending to get a max sized mq, it could simply be that the app expected a default sized mq but tried to send an overly large message because it is a poorly coded app, or it could have run out of space because the receiving app is blocked. So, we could print something out, but personally I'm not entirely convinced that it's worth the extra lines of code in the kernel to make it happen properly. This problem, if it existed in the real world, would be such poor programming practice that I'm having a hard time imagining that it really exists. For a simple, whip it up in 20 minutes test program as part of a regression suite? Sure, I can see that. For anything intended to be robust and reliable? No, I can't see this bad behavior being done there. But, who knows, maybe I give programmers writing real programs too much credit... -- Doug Ledford GPG KeyID: 0E572FDD http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband