linux-kernel - Re: [Patch 2/8] ipc/mqueue: switch back to using non-max values on create

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F8ECE09.3050700@redhat.com>
Date:	Wed, 18 Apr 2012 10:22:01 -0400
From:	Doug Ledford <dledford@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	KOSAKI Motohiro <kosaki.motohiro@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [Patch 2/8] ipc/mqueue: switch back to using non-max values on
 create

On 4/17/2012 7:00 PM, Andrew Morton wrote:
> On Tue, 17 Apr 2012 18:32:25 -0400
> KOSAKI Motohiro <kosaki.motohiro@...il.com> 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 <dledford@...hat.com>
              GPG KeyID: 0E572FDD
	      http://people.redhat.com/dledford

Infiniband specific RPMs available at
	      http://people.redhat.com/dledford/Infiniband

Download attachment "signature.asc" of type "application/pgp-signature" (899 bytes)