SysV can be abused to allocate locked kernel memory. For most systems, a small limit doesn't make sense, see the discussion with regards to SHMMAX. Therefore: increase MSGMNI to the maximum supported. And: If we ignore the risk of locking too much memory, then an automatic scaling of MSGMNI doesn't make sense. Therefore the logic can be removed. The code preserves auto_msgmni to avoid breaking any user space applications that expect that the value exists. Notes: 1) If an administrator must limit the memory allocations, then he can set MSGMNI as necessary. Or he can disable sysv entirely (as e.g. done by Android). 2) MSGMAX and MSGMNB are intentionally not increased, as these values are used to control latency vs. throughput: If MSGMNB is large, then msgsnd() just returns and more messages can be queued before a task switch to a task that calls msgrcv() is forced. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Manfred Spraul <manfred@colorfullife.com> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: Rafael Aquini <aquini@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Showing the changes to include/uapi/linux (1 of 9 files). Show all
Unified · Split
| @@ -51,16 +51,28 @@ struct msginfo { · 50 unmodified lines | ||
| 51 | 51 | }; |
| 52 | 52 | |
| 53 | 53 | /* |
| 54 | − * Scaling factor to compute msgmni: | |
| 55 | − * the memory dedicated to msg queues (msgmni * msgmnb) should occupy | |
| 56 | − * at most 1/MSG_MEM_SCALE of the lowmem (see the formula in ipc/msg.c): | |
| 57 | − * up to 8MB : msgmni = 16 (MSGMNI) | |
| 58 | − * 4 GB : msgmni = 8K | |
| 59 | − * more than 16 GB : msgmni = 32K (IPCMNI) | |
| 54 | + * MSGMNI, MSGMAX and MSGMNB are default values which can be | |
| 55 | + * modified by sysctl. | |
| 56 | + * | |
| 57 | + * MSGMNI is the upper limit for the number of messages queues per | |
| 58 | + * namespace. | |
| 59 | + * It has been chosen to be as large possible without facilitating | |
| 60 | + * scenarios where userspace causes overflows when adjusting the limits via | |
| 61 | + * operations of the form retrieve current limit; add X; update limit". | |
| 62 | + * | |
| 63 | + * MSGMNB is the default size of a new message queue. Non-root tasks can | |
| 64 | + * decrease the size with msgctl(IPC_SET), root tasks | |
| 65 | + * (actually: CAP_SYS_RESOURCE) can both increase and decrease the queue | |
| 66 | + * size. The optimal value is application dependent. | |
| 67 | + * 16384 is used because it was always used (since 0.99.10) | |
| 68 | + * | |
| 69 | + * MAXMAX is the maximum size of an individual message, it's a global | |
| 70 | + * (per-namespace) limit that applies for all message queues. | |
| 71 | + * It's set to 1/2 of MSGMNB, to ensure that at least two messages fit into | |
| 72 | + * the queue. This is also an arbitrary choice (since 2.6.0). | |
| 60 | 73 | */ |
| 61 | −#define MSG_MEM_SCALE 32 | |
| 62 | 74 | |
| 63 | −#define MSGMNI 16 /* <= IPCMNI */ /* max # of msg queue identifiers */ | |
| 75 | +#define MSGMNI 32000 /* <= IPCMNI */ /* max # of msg queue identifiers */ | |
| 64 | 76 | #define MSGMAX 8192 /* <= INT_MAX */ /* max size of message (bytes) */ |
| 65 | 77 | #define MSGMNB 16384 /* <= INT_MAX */ /* default max size of a message queue */ |
| 66 | 78 | |