linux-kernel - Re: Max number of posix queues in vanilla kernel (/proc/sys/fs/mqueue/queues

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: <52F7A909.5030408@redhat.com>
Date:	Sun, 09 Feb 2014 11:12:57 -0500
From:	Doug Ledford <dledford@...hat.com>
To:	Davidlohr Bueso <davidlohr@...com>
CC:	m@...odev.com, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org,
	Manfred Spraul <manfred@...orfullife.com>
Subject: Re: Max number of posix queues in vanilla kernel (/proc/sys/fs/mqueue/queues_max)

On 02/08/2014 11:17 PM, Davidlohr Bueso wrote:
> On Fri, 2014-02-07 at 16:24 -0500, Doug Ledford wrote:
>> On 2/7/2014 3:11 PM, Davidlohr Bueso wrote:
>>> On Thu, 2014-02-06 at 12:21 +0200, m@...odev.com wrote:
>>>> Hi Folks,
>>>>
>>>> I have recently ported my multi-process application (like a classical open
>>>> system) which uses POSIX Queues as IPC to one of the latest Linux kernels,
>>>> and I have faced issue that number of maximum queues are dramatically
>>>> limited down to 1024 (see include/linux/ipc_namespace.h, #define
>>>> HARD_QUEUESMAX 1024).
>>>>
>>>> Previously the max number of queues was INT_MAX (on 64bit system was:
>>>> 2147483647).
>>>
>>> Hmm yes, 1024 is quite unrealistic for some workloads and breaks
>>> userspace - I don't see any reasons for _this_ specific value in the
>>> changelog or related changes in the patchset that introduced commits
>>> 93e6f119 and 02967ea0.
>>
>> There wasn't a specific selection of that number other than a general
>> attempt to make the max more reasonable (INT_MAX isn't really reasonable
>> given the overhead of each individual queue, even if the queue number
>> and max msg size are small).
>>
>>> And the fact that this limit is per namespace
>>> makes no difference really. Hell, if nothing else, the mq_overview(7)
>>> manpage description is evidence enough. For privileged users:
>>>
>>> The default value for queues_max is 256; it can be changed to any value in the range 0 to INT_MAX.
>>
>> That was obviously never updated to match the change.
>>
>> In hindsight, I'm not sure we really even care though.  Since the limit
>> on queues is per namespace, and we can make as many namespaces as we
>> want, the limit is more or less meaningless and only serves as a
>> nuisance to people.
>
> Yes, but namespaces aren't _that_ popular in reality, specially as you
> describe the workaround.
>
>>   Since we have accounting on a per user basis that
>> spans across namespaces and across queues, maybe that should be
>> sufficient and the limit on queues should simply be removed and we
>> should instead just rely on memory limits.  When the user has exhausted
>> their allowed memory usage, whether by large queue sizes, large message
>> sizes, or large queue counts, then they are done.  When they haven't,
>> they can keep allocating.  Would make things considerably easier and
>> would avoid the breakage we are talking about here.
>>
>
> Right, and this is taken care of in mqueue_get_inode().
>
> The (untested) code below simply removes this global limit, let me know
> if you're okay with it and I'll send a formal/tested patch.
>
> diff --git a/include/linux/ipc_namespace.h b/include/linux/ipc_namespace.h
> index e7831d2..d78a09f 100644
> --- a/include/linux/ipc_namespace.h
> +++ b/include/linux/ipc_namespace.h
> @@ -120,7 +120,6 @@ extern int mq_init_ns(struct ipc_namespace *ns);
>    */
>   #define MIN_QUEUESMAX			1
>   #define DFLT_QUEUESMAX		      256
> -#define HARD_QUEUESMAX		     1024

Since you are passing the queue setting off to proc_dointvec, I don't 
think the3 MIN_QUEUESMAX value is used any longer, so might as well kill 
it too.  Otherwise, it looks acceptable to me.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/