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-next>] [day] [month] [year] [list]
Date:	Thu, 6 Feb 2014 12:21:06 +0200 (EET)
Subject: Max number of posix queues in vanilla kernel  

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

Previously the max number of queues was INT_MAX (on 64bit system was:

This update imposes bad limits on our multi-process application. As our
app uses approaches that each process opens its own set of queues (usually
something about 3-5 queues per process). In some scenarios we might run up
to 3000 processes or more (which of-course for linux is not a problem).
Thus we might need up to 9000 queues or more. All processes run under one

But now we have this limit, which limits our software down and we are
getting in trouble. We could patch the kernel manually, but not all
customers are capable of this and willing to do the patching.

Thus I *kindly* ask you guys to increase this limit to something like 1M
queues or more (or to technical limit i.e. leave the same INT_MAX). If
user can screw up the system by setting or using maximums, let it leave to
the user. As it is doing system tuning and he is responsible for kernel

The kernel limit was introduced by:

Also I see other people are claiming issues with this, see:
- - for
them some database software is not working after the kernel upgrade...

Also I think that when people will upgrade from RHEL 5 or RHEL 6 to next
versions where this hard limit will be defined, I suspect that many will
claim problem about it...

Thanks a lot in advance,
Madars Vitolins

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists