From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by kanga.kvack.org (Postfix) with ESMTP id 9CAAD6B0031 for ; Sat, 19 Apr 2014 07:43:58 -0400 (EDT) Received: by mail-ee0-f50.google.com with SMTP id c13so2288473eek.23 for ; Sat, 19 Apr 2014 04:43:57 -0700 (PDT) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by mx.google.com with ESMTPS id u5si44535616een.233.2014.04.19.04.43.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Apr 2014 04:43:56 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id b57so2300687eek.21 for ; Sat, 19 Apr 2014 04:43:56 -0700 (PDT) From: Manfred Spraul Subject: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL Date: Sat, 19 Apr 2014 13:43:37 +0200 Message-Id: <1397907821-29319-1-git-send-email-manfred@colorfullife.com> Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky Cc: LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org, Manfred Spraul Hi all, the increase of SHMMAX/SHMALL is now a 4 patch series, and still not ready for merging (see at the end, TASK_SIZE and s390). If we increase the default limits for SHMMAX and SHMALL, integer overflows could happen: SHMMAX: - shmmem_file_setup places a hard limit on the segment size: MAX_LFS_FILESIZE. on 32-bit, the limit is > 1 TB. --> 32-bit: 4 GB-1 segments are possible. Rounded up to full pages the actual allocated size is 0. --> patch 3 on 64-bit, this is 0x7fff ffff ffff ffff --> no chance for an overflow. - shmat: - find_vma_intersection does not handle overflows properly --> patch 1. - do_mmap_pgoff limits mappings to TASK_SIZE 3 GB on 32-bit (assuming x86) 47 bits on 64-bit (assuming x86) - do_mmap_pgoff checks for overflows: map 2 GB, starting from addr=2.5GB fails. SHMALL: - after creating 8192 segments size (1L<<63)-1, shm_tot overflows and returns 0. --> patch 2. And finally: Patch 4, increase the limits to ULONG_MAX Open points: - Better ideas to handle uapi: Is it worth the effort to get access to TASK_SIZE? I would say no. - Better ideas with regards to SHMALL? The values are probably large enough, but still arbitrary. - The TASK_SIZE definition for e.g. S390 differs: It's not a constant, instead it is the current task size for current. And it seems that the task size can change based on (virtual) memory pressure (s390_mmap_check()). For new namespaces, this might have interesting effects, i.e. this must be fixed. -- Manfred -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by kanga.kvack.org (Postfix) with ESMTP id C46076B0035 for ; Mon, 21 Apr 2014 10:31:41 -0400 (EDT) Received: by mail-ee0-f41.google.com with SMTP id t10so3731347eei.28 for ; Mon, 21 Apr 2014 07:31:41 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by mx.google.com with ESMTPS id y6si54724694eep.317.2014.04.21.07.31.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Apr 2014 07:31:40 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id e49so3739398eek.3 for ; Mon, 21 Apr 2014 07:31:39 -0700 (PDT) From: Manfred Spraul Subject: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL Date: Mon, 21 Apr 2014 16:26:33 +0200 Message-Id: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky Cc: LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org, Manfred Spraul Hi all, the increase of SHMMAX/SHMALL is now a 4 patch series. I don't have ideas how to improve it further. The change itself is trivial, the only problem are interger overflows. The overflows are not new, but if we make huge values the default, then the code should be free from overflows. SHMMAX: - shmmem_file_setup places a hard limit on the segment size: MAX_LFS_FILESIZE. On 32-bit, the limit is > 1 TB, i.e. 4 GB-1 byte segments are possible. Rounded up to full pages the actual allocated size is 0. --> must be fixed, patch 3 - shmat: - find_vma_intersection does not handle overflows properly. --> must be fixed, patch 1 - the rest is fine, do_mmap_pgoff limits mappings to TASK_SIZE and checks for overflows (i.e.: map 2 GB, starting from addr=2.5GB fails). SHMALL: - after creating 8192 segments size (1L<<63)-1, shm_tot overflows and returns 0. --> must be fixed, patch 2. User space: - Obviuosly, there could be overflows in user space. There is nothing we can do, only use values smaller than ULONG_MAX. I ended with "ULONG_MAX - 1L<<24": - TASK_SIZE cannot be used because it is the size of the current task. Could be 4G if it's a 32-bit task on a 64-bit kernel. - The maximum size is not standardized across archs: I found TASK_MAX_SIZE, TASK_SIZE_MAX and TASK_SIZE_64. - Just in case some arch revives a 4G/4G split, nearly ULONG_MAX is a valid segment size. - Using "0" as a magic value for infinity is even worse, because right now 0 means 0, i.e. fail all allocations. Andrew: Could you add it into -akpm and move it towards linux-next? -- Manfred -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by kanga.kvack.org (Postfix) with ESMTP id 08E5B6B0039 for ; Mon, 21 Apr 2014 10:31:44 -0400 (EDT) Received: by mail-ee0-f47.google.com with SMTP id b15so3678341eek.20 for ; Mon, 21 Apr 2014 07:31:44 -0700 (PDT) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by mx.google.com with ESMTPS id n46si10536232eeo.97.2014.04.21.07.31.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Apr 2014 07:31:43 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id e53so3684728eek.2 for ; Mon, 21 Apr 2014 07:31:42 -0700 (PDT) From: Manfred Spraul Subject: [PATCH 1/4] ipc/shm.c: check for ulong overflows in shmat Date: Mon, 21 Apr 2014 16:26:34 +0200 Message-Id: <1398090397-2397-2-git-send-email-manfred@colorfullife.com> In-Reply-To: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky Cc: LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org, Manfred Spraul find_vma_intersection does not work as intended if addr+size overflows. The patch adds a manual check before the call to find_vma_intersection. Signed-off-by: Manfred Spraul --- ipc/shm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ipc/shm.c b/ipc/shm.c index 7645961..382e2fb 100644 --- a/ipc/shm.c +++ b/ipc/shm.c @@ -1160,6 +1160,9 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr, down_write(¤t->mm->mmap_sem); if (addr && !(shmflg & SHM_REMAP)) { err = -EINVAL; + if (addr + size < addr) + goto invalid; + if (find_vma_intersection(current->mm, addr, addr + size)) goto invalid; /* -- 1.9.0 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by kanga.kvack.org (Postfix) with ESMTP id 90D5E6B003A for ; Mon, 21 Apr 2014 10:31:46 -0400 (EDT) Received: by mail-ee0-f49.google.com with SMTP id c41so3686617eek.36 for ; Mon, 21 Apr 2014 07:31:46 -0700 (PDT) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by mx.google.com with ESMTPS id u5si54783852een.113.2014.04.21.07.31.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Apr 2014 07:31:45 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id e53so3666768eek.16 for ; Mon, 21 Apr 2014 07:31:44 -0700 (PDT) From: Manfred Spraul Subject: [PATCH 2/4] ipc/shm.c: check for overflows of shm_tot Date: Mon, 21 Apr 2014 16:26:35 +0200 Message-Id: <1398090397-2397-3-git-send-email-manfred@colorfullife.com> In-Reply-To: <1398090397-2397-2-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky Cc: LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org, Manfred Spraul shm_tot counts the total number of pages used by shm segments. If SHMALL is ULONG_MAX (or nearly ULONG_MAX), then the number can overflow. Subsequent calls to shmctl(,SHM_INFO,) would return wrong values for shm_tot. The patch adds a detection for overflows. Signed-off-by: Manfred Spraul --- ipc/shm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ipc/shm.c b/ipc/shm.c index 382e2fb..2dfa3d6 100644 --- a/ipc/shm.c +++ b/ipc/shm.c @@ -493,7 +493,8 @@ static int newseg(struct ipc_namespace *ns, struct ipc_params *params) if (size < SHMMIN || size > ns->shm_ctlmax) return -EINVAL; - if (ns->shm_tot + numpages > ns->shm_ctlall) + if (ns->shm_tot + numpages < ns->shm_tot || + ns->shm_tot + numpages > ns->shm_ctlall) return -ENOSPC; shp = ipc_rcu_alloc(sizeof(*shp)); -- 1.9.0 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by kanga.kvack.org (Postfix) with ESMTP id 226336B003B for ; Mon, 21 Apr 2014 10:31:48 -0400 (EDT) Received: by mail-ee0-f51.google.com with SMTP id c13so3691144eek.38 for ; Mon, 21 Apr 2014 07:31:47 -0700 (PDT) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx.google.com with ESMTPS id 49si54722862een.335.2014.04.21.07.31.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Apr 2014 07:31:46 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id d49so3703223eek.13 for ; Mon, 21 Apr 2014 07:31:46 -0700 (PDT) From: Manfred Spraul Subject: [PATCH 3/4] ipc/shm.c: check for integer overflow during shmget. Date: Mon, 21 Apr 2014 16:26:36 +0200 Message-Id: <1398090397-2397-4-git-send-email-manfred@colorfullife.com> In-Reply-To: <1398090397-2397-3-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky Cc: LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org, Manfred Spraul SHMMAX is the upper limit for the size of a shared memory segment, counted in bytes. The actual allocation is that size, rounded up to the next full page. Add a check that prevents the creation of segments where the rounded up size causes an integer overflow. Signed-off-by: Manfred Spraul --- ipc/shm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ipc/shm.c b/ipc/shm.c index 2dfa3d6..f000696 100644 --- a/ipc/shm.c +++ b/ipc/shm.c @@ -493,6 +493,9 @@ static int newseg(struct ipc_namespace *ns, struct ipc_params *params) if (size < SHMMIN || size > ns->shm_ctlmax) return -EINVAL; + if (numpages << PAGE_SHIFT < size) + return -ENOSPC; + if (ns->shm_tot + numpages < ns->shm_tot || ns->shm_tot + numpages > ns->shm_ctlall) return -ENOSPC; -- 1.9.0 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by kanga.kvack.org (Postfix) with ESMTP id 51F4D6B003C for ; Mon, 21 Apr 2014 10:31:56 -0400 (EDT) Received: by mail-ee0-f53.google.com with SMTP id b57so3663425eek.40 for ; Mon, 21 Apr 2014 07:31:50 -0700 (PDT) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by mx.google.com with ESMTPS id x44si54693933eep.330.2014.04.21.07.31.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Apr 2014 07:31:50 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id t10so3731434eei.28 for ; Mon, 21 Apr 2014 07:31:49 -0700 (PDT) From: Manfred Spraul Subject: [PATCH 4/4] ipc/shm.c: Increase the defaults for SHMALL, SHMMAX. Date: Mon, 21 Apr 2014 16:26:37 +0200 Message-Id: <1398090397-2397-5-git-send-email-manfred@colorfullife.com> In-Reply-To: <1398090397-2397-4-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> <1398090397-2397-4-git-send-email-manfred@colorfullife.com> Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky Cc: LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org, Manfred Spraul System V shared memory a) can be abused to trigger out-of-memory conditions and the standard measures against out-of-memory do not work: - it is not possible to use setrlimit to limit the size of shm segments. - segments can exist without association with any processes, thus the oom-killer is unable to free that memory. b) is typically used for shared information - today often multiple GB. (e.g. database shared buffers) The current default is a maximum segment size of 32 MB and a maximum total size of 8 GB. This is often too much for a) and not enough for b), which means that lots of users must change the defaults. This patch increases the default limits (nearly) to the maximum, which is perfect for case b). The defaults are used after boot and as the initial value for each new namespace. Admins/distros that need a protection against a) should reduce the limits and/or enable shm_rmid_forced. Further notes: - The patch only changes default, overrides behave as before: # sysctl kernel.shmall=33554432 would recreate the previous limit for SHMMAX (for the current namespace). - Disabling sysv shm allocation is possible with: # sysctl kernel.shmall=0 (not a new feature, also per-namespace) - The limits are intentionally set to a value slightly less than ULONG_MAX, to avoid triggering overflows in user space apps. [not unreasonable, see http://marc.info/?l=linux-mm&m=139638334330127] Signed-off-by: Manfred Spraul Reported-by: Davidlohr Bueso Cc: mtk.manpages@gmail.com --- include/linux/shm.h | 3 +-- include/uapi/linux/shm.h | 8 +++----- 2 files changed, 4 insertions(+), 7 deletions(-) diff --git a/include/linux/shm.h b/include/linux/shm.h index 1e2cd2e..57d7770 100644 --- a/include/linux/shm.h +++ b/include/linux/shm.h @@ -3,9 +3,8 @@ #include #include - -#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) */ #include + struct shmid_kernel /* private to the kernel */ { struct kern_ipc_perm shm_perm; diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h index 78b6941..74e786d 100644 --- a/include/uapi/linux/shm.h +++ b/include/uapi/linux/shm.h @@ -9,15 +9,13 @@ /* * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can - * be increased by sysctl + * be modified by sysctl. */ -#define SHMMAX 0x2000000 /* max shared seg size (bytes) */ #define SHMMIN 1 /* min shared seg size (bytes) */ #define SHMMNI 4096 /* max num of segs system wide */ -#ifndef __KERNEL__ -#define SHMALL (SHMMAX/getpagesize()*(SHMMNI/16)) -#endif +#define SHMMAX (ULONG_MAX - (1L<<24)) /* max shared seg size (bytes) */ +#define SHMALL (ULONG_MAX - (1L<<24)) /* max shm system wide (pages) */ #define SHMSEG SHMMNI /* max shared segs per process */ -- 1.9.0 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by kanga.kvack.org (Postfix) with ESMTP id 2BA916B0035 for ; Mon, 21 Apr 2014 13:25:11 -0400 (EDT) Received: by mail-ob0-f175.google.com with SMTP id wp4so4485810obc.6 for ; Mon, 21 Apr 2014 10:25:10 -0700 (PDT) Received: from g5t1625.atlanta.hp.com (g5t1625.atlanta.hp.com. [15.192.137.8]) by mx.google.com with ESMTPS id sd1si29525566obb.208.2014.04.21.10.25.10 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 21 Apr 2014 10:25:10 -0700 (PDT) Message-ID: <1398101106.2623.6.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL From: Davidlohr Bueso Date: Mon, 21 Apr 2014 10:25:06 -0700 In-Reply-To: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Manfred Spraul Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote: > Hi all, > > the increase of SHMMAX/SHMALL is now a 4 patch series. > I don't have ideas how to improve it further. Manfred, is there any difference between this set and the one you sent a couple of days ago? > > The change itself is trivial, the only problem are interger overflows. > The overflows are not new, but if we make huge values the default, > then the code should be free from overflows. > > SHMMAX: > > - shmmem_file_setup places a hard limit on the segment size: > MAX_LFS_FILESIZE. > > On 32-bit, the limit is > 1 TB, i.e. 4 GB-1 byte segments are > possible. Rounded up to full pages the actual allocated size > is 0. --> must be fixed, patch 3 > > - shmat: > - find_vma_intersection does not handle overflows properly. > --> must be fixed, patch 1 > > - the rest is fine, do_mmap_pgoff limits mappings to TASK_SIZE > and checks for overflows (i.e.: map 2 GB, starting from > addr=2.5GB fails). > > SHMALL: > - after creating 8192 segments size (1L<<63)-1, shm_tot overflows and > returns 0. --> must be fixed, patch 2. > > User space: > - Obviuosly, there could be overflows in user space. There is nothing > we can do, only use values smaller than ULONG_MAX. > I ended with "ULONG_MAX - 1L<<24": > > - TASK_SIZE cannot be used because it is the size of the current > task. Could be 4G if it's a 32-bit task on a 64-bit kernel. > > - The maximum size is not standardized across archs: > I found TASK_MAX_SIZE, TASK_SIZE_MAX and TASK_SIZE_64. > > - Just in case some arch revives a 4G/4G split, nearly > ULONG_MAX is a valid segment size. > > - Using "0" as a magic value for infinity is even worse, because > right now 0 means 0, i.e. fail all allocations. Sorry but I don't quite get this. Using 0 eliminates the need for all these patches, no? I mean overflows have existed since forever, and taking this route would naturally solve the problem. 0 allocations are a no no anyways. I do agree with the series iff we endup taking this 'increase the limit size approach'. But I just don't see the need. Thanks, Davidlohr -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by kanga.kvack.org (Postfix) with ESMTP id 5E0D26B0035 for ; Tue, 22 Apr 2014 00:23:35 -0400 (EDT) Received: by mail-ee0-f42.google.com with SMTP id d17so4092770eek.15 for ; Mon, 21 Apr 2014 21:23:34 -0700 (PDT) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by mx.google.com with ESMTPS id 45si57751070eeh.123.2014.04.21.21.23.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Apr 2014 21:23:33 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id c13so4052733eek.24 for ; Mon, 21 Apr 2014 21:23:33 -0700 (PDT) Message-ID: <5355EEC2.4010304@colorfullife.com> Date: Tue, 22 Apr 2014 06:23:30 +0200 From: Manfred Spraul MIME-Version: 1.0 Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398101106.2623.6.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1398101106.2623.6.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org On 04/21/2014 07:25 PM, Davidlohr Bueso wrote: > On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote: >> Hi all, >> >> the increase of SHMMAX/SHMALL is now a 4 patch series. >> I don't have ideas how to improve it further. > Manfred, is there any difference between this set and the one you sent a > couple of days ago? a) I updated the comments. b) the initial set used TASK_SIZE, not I switch to ULONG_MAX-(1L<<24) >> - Using "0" as a magic value for infinity is even worse, because >> right now 0 means 0, i.e. fail all allocations. > Sorry but I don't quite get this. Using 0 eliminates the need for all > these patches, no? I mean overflows have existed since forever, and > taking this route would naturally solve the problem. 0 allocations are a > no no anyways. No. The patches are required to handle e.g. shmget(,ULONG_MAX,): Right now, shmget(,ULONG_MAX,) results in a 0-byte segment. The risk of using 0 is that it reverses the current behavior: Up to now, # sysctl kernel.shmall=0 disables allocations. If we define 0 a infinity, then the same configuration would allow unlimited allocations. -- Manfred -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by kanga.kvack.org (Postfix) with ESMTP id A85EC6B0070 for ; Tue, 22 Apr 2014 14:18:16 -0400 (EDT) Received: by mail-oa0-f41.google.com with SMTP id j17so6142167oag.28 for ; Tue, 22 Apr 2014 11:18:16 -0700 (PDT) Received: from g2t2352.austin.hp.com (g2t2352.austin.hp.com. [15.217.128.51]) by mx.google.com with ESMTPS id sm4si32133738obb.76.2014.04.22.11.18.15 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Apr 2014 11:18:16 -0700 (PDT) Message-ID: <1398190693.2473.7.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL From: Davidlohr Bueso Date: Tue, 22 Apr 2014 11:18:13 -0700 In-Reply-To: <5355EEC2.4010304@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398101106.2623.6.camel@buesod1.americas.hpqcorp.net> <5355EEC2.4010304@colorfullife.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Manfred Spraul Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org On Tue, 2014-04-22 at 06:23 +0200, Manfred Spraul wrote: > On 04/21/2014 07:25 PM, Davidlohr Bueso wrote: > > On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote: > >> Hi all, > >> > >> the increase of SHMMAX/SHMALL is now a 4 patch series. > >> I don't have ideas how to improve it further. > > Manfred, is there any difference between this set and the one you sent a > > couple of days ago? > a) I updated the comments. > b) the initial set used TASK_SIZE, not I switch to ULONG_MAX-(1L<<24) > > >> - Using "0" as a magic value for infinity is even worse, because > >> right now 0 means 0, i.e. fail all allocations. > > Sorry but I don't quite get this. Using 0 eliminates the need for all > > these patches, no? I mean overflows have existed since forever, and > > taking this route would naturally solve the problem. 0 allocations are a > > no no anyways. > No. The patches are required to handle e.g. shmget(,ULONG_MAX,): > Right now, shmget(,ULONG_MAX,) results in a 0-byte segment. Ok, I was mixing 'issues' then. > The risk of using 0 is that it reverses the current behavior: > Up to now, > # sysctl kernel.shmall=0 > disables allocations. > If we define 0 a infinity, then the same configuration would allow > unlimited allocations. Right, but as I mentioned, this also contradicts the fact that shmmin cannot be 0. And again, I don't know who's correct here. Do any standards mention this? I haven't found anything, and hard-codding shmmin to 1 seems to be different among OSs, Linux choosing to do so. This difference must also be commented in the manpage. That said, I believe that violating this "feature" and forbidding disabling shm would probably have a more severe penalty (security, perhaps) for users who rely on this. So while I'm really annoyed that we "cannot" use 0 because of this, I'm going to give up arguing. I believe you approach is the safer way of going. Thanks a lot for looking into this, Manfred. Davidlohr -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by kanga.kvack.org (Postfix) with ESMTP id 0A9036B0071 for ; Tue, 22 Apr 2014 14:18:41 -0400 (EDT) Received: by mail-ob0-f170.google.com with SMTP id vb8so4863482obc.15 for ; Tue, 22 Apr 2014 11:18:40 -0700 (PDT) Received: from g2t2353.austin.hp.com (g2t2353.austin.hp.com. [15.217.128.52]) by mx.google.com with ESMTPS id kk10si32135194obb.68.2014.04.22.11.18.39 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Apr 2014 11:18:39 -0700 (PDT) Message-ID: <1398190717.2473.8.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 1/4] ipc/shm.c: check for ulong overflows in shmat From: Davidlohr Bueso Date: Tue, 22 Apr 2014 11:18:37 -0700 In-Reply-To: <1398090397-2397-2-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Manfred Spraul Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote: > find_vma_intersection does not work as intended if addr+size overflows. > The patch adds a manual check before the call to find_vma_intersection. > > Signed-off-by: Manfred Spraul Acked-by: Davidlohr Bueso -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-f181.google.com (mail-yk0-f181.google.com [209.85.160.181]) by kanga.kvack.org (Postfix) with ESMTP id 8C15E6B0072 for ; Tue, 22 Apr 2014 14:18:56 -0400 (EDT) Received: by mail-yk0-f181.google.com with SMTP id 131so4849779ykp.40 for ; Tue, 22 Apr 2014 11:18:56 -0700 (PDT) Received: from g6t1526.atlanta.hp.com (g6t1526.atlanta.hp.com. [15.193.200.69]) by mx.google.com with ESMTPS id q56si41844404yhi.56.2014.04.22.11.18.55 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Apr 2014 11:18:55 -0700 (PDT) Message-ID: <1398190732.2473.9.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 2/4] ipc/shm.c: check for overflows of shm_tot From: Davidlohr Bueso Date: Tue, 22 Apr 2014 11:18:52 -0700 In-Reply-To: <1398090397-2397-3-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Manfred Spraul Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote: > shm_tot counts the total number of pages used by shm segments. > > If SHMALL is ULONG_MAX (or nearly ULONG_MAX), then the number > can overflow. Subsequent calls to shmctl(,SHM_INFO,) would return > wrong values for shm_tot. > > The patch adds a detection for overflows. > > Signed-off-by: Manfred Spraul Acked-by: Davidlohr Bueso -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yh0-f43.google.com (mail-yh0-f43.google.com [209.85.213.43]) by kanga.kvack.org (Postfix) with ESMTP id 376FD6B0073 for ; Tue, 22 Apr 2014 14:19:08 -0400 (EDT) Received: by mail-yh0-f43.google.com with SMTP id b6so5195300yha.30 for ; Tue, 22 Apr 2014 11:19:07 -0700 (PDT) Received: from g5t1626.atlanta.hp.com (g5t1626.atlanta.hp.com. [15.192.137.9]) by mx.google.com with ESMTPS id q49si41855675yhe.34.2014.04.22.11.19.07 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Apr 2014 11:19:07 -0700 (PDT) Message-ID: <1398190745.2473.10.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 3/4] ipc/shm.c: check for integer overflow during shmget. From: Davidlohr Bueso Date: Tue, 22 Apr 2014 11:19:05 -0700 In-Reply-To: <1398090397-2397-4-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> <1398090397-2397-4-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Manfred Spraul Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote: > SHMMAX is the upper limit for the size of a shared memory segment, > counted in bytes. The actual allocation is that size, rounded up to > the next full page. > Add a check that prevents the creation of segments where the > rounded up size causes an integer overflow. > > Signed-off-by: Manfred Spraul Acked-by: Davidlohr Bueso -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by kanga.kvack.org (Postfix) with ESMTP id 5F7496B0070 for ; Tue, 22 Apr 2014 14:21:19 -0400 (EDT) Received: by mail-pd0-f175.google.com with SMTP id x10so5145054pdj.34 for ; Tue, 22 Apr 2014 11:21:19 -0700 (PDT) Received: from g2t2353.austin.hp.com (g2t2353.austin.hp.com. [15.217.128.52]) by mx.google.com with ESMTPS id s9si9690150pbj.360.2014.04.22.11.21.18 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Apr 2014 11:21:18 -0700 (PDT) Message-ID: <1398190871.2473.12.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 4/4] ipc/shm.c: Increase the defaults for SHMALL, SHMMAX. From: Davidlohr Bueso Date: Tue, 22 Apr 2014 11:21:11 -0700 In-Reply-To: <1398090397-2397-5-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> <1398090397-2397-4-git-send-email-manfred@colorfullife.com> <1398090397-2397-5-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Manfred Spraul Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote: > System V shared memory > > a) can be abused to trigger out-of-memory conditions and the standard > measures against out-of-memory do not work: > > - it is not possible to use setrlimit to limit the size of shm segments. > > - segments can exist without association with any processes, thus > the oom-killer is unable to free that memory. > > b) is typically used for shared information - today often multiple GB. > (e.g. database shared buffers) > > The current default is a maximum segment size of 32 MB and a maximum total > size of 8 GB. This is often too much for a) and not enough for b), which > means that lots of users must change the defaults. > > This patch increases the default limits (nearly) to the maximum, which is > perfect for case b). The defaults are used after boot and as the initial > value for each new namespace. > > Admins/distros that need a protection against a) should reduce the limits > and/or enable shm_rmid_forced. > > Further notes: > - The patch only changes default, overrides behave as before: > # sysctl kernel.shmall=33554432 > would recreate the previous limit for SHMMAX (for the current namespace). > > - Disabling sysv shm allocation is possible with: > # sysctl kernel.shmall=0 > (not a new feature, also per-namespace) > > - The limits are intentionally set to a value slightly less than ULONG_MAX, > to avoid triggering overflows in user space apps. > [not unreasonable, see http://marc.info/?l=linux-mm&m=139638334330127] > > Signed-off-by: Manfred Spraul > Reported-by: Davidlohr Bueso > Cc: mtk.manpages@gmail.com Signed-off-by: Davidlohr Bueso With one comment below. > --- > include/linux/shm.h | 3 +-- > include/uapi/linux/shm.h | 8 +++----- > 2 files changed, 4 insertions(+), 7 deletions(-) > > diff --git a/include/linux/shm.h b/include/linux/shm.h > index 1e2cd2e..57d7770 100644 > --- a/include/linux/shm.h > +++ b/include/linux/shm.h > @@ -3,9 +3,8 @@ > > #include > #include > - > -#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) */ > #include > + > struct shmid_kernel /* private to the kernel */ > { > struct kern_ipc_perm shm_perm; > diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h > index 78b6941..74e786d 100644 > --- a/include/uapi/linux/shm.h > +++ b/include/uapi/linux/shm.h > @@ -9,15 +9,13 @@ > > /* > * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can > - * be increased by sysctl > + * be modified by sysctl. > */ > > -#define SHMMAX 0x2000000 /* max shared seg size (bytes) */ > #define SHMMIN 1 /* min shared seg size (bytes) */ > #define SHMMNI 4096 /* max num of segs system wide */ > -#ifndef __KERNEL__ > -#define SHMALL (SHMMAX/getpagesize()*(SHMMNI/16)) > -#endif > +#define SHMMAX (ULONG_MAX - (1L<<24)) /* max shared seg size (bytes) */ > +#define SHMALL (ULONG_MAX - (1L<<24)) /* max shm system wide (pages) */ It's quite clear in the changelog, but could you please add a big fat comment explaining this option, and that there's no point in enlarging it. In fact if the user wants to make it bigger, we should display some printk_once mentioning that this is the upper limit. Thanks, Davidlohr -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yh0-f43.google.com (mail-yh0-f43.google.com [209.85.213.43]) by kanga.kvack.org (Postfix) with ESMTP id 6F1256B0062 for ; Tue, 22 Apr 2014 14:28:55 -0400 (EDT) Received: by mail-yh0-f43.google.com with SMTP id b6so5161970yha.2 for ; Tue, 22 Apr 2014 11:28:55 -0700 (PDT) Received: from g5t1625.atlanta.hp.com (g5t1625.atlanta.hp.com. [15.192.137.8]) by mx.google.com with ESMTPS id i68si41895615yhf.71.2014.04.22.11.28.54 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Apr 2014 11:28:54 -0700 (PDT) Message-ID: <1398191332.2473.14.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 4/4] ipc/shm.c: Increase the defaults for SHMALL, SHMMAX. From: Davidlohr Bueso Date: Tue, 22 Apr 2014 11:28:52 -0700 In-Reply-To: <1398090397-2397-5-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> <1398090397-2397-4-git-send-email-manfred@colorfullife.com> <1398090397-2397-5-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Manfred Spraul Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote: > System V shared memory > > a) can be abused to trigger out-of-memory conditions and the standard > measures against out-of-memory do not work: > > - it is not possible to use setrlimit to limit the size of shm segments. > > - segments can exist without association with any processes, thus > the oom-killer is unable to free that memory. > > b) is typically used for shared information - today often multiple GB. > (e.g. database shared buffers) > > The current default is a maximum segment size of 32 MB and a maximum total > size of 8 GB. This is often too much for a) and not enough for b), which > means that lots of users must change the defaults. Per Andrew's request, I think the following should go here from the changelog of my patch: Unix has historically required setting these limits for shared memory, and Linux inherited such behavior. The consequence of this is added complexity for users and administrators. One very common example are Database setup/installation documents and scripts, where users must manually calculate the values for these limits. This also requires (some) knowledge of how the underlying memory management works, thus causing, in many occasions, the limits to just be flat out wrong. Disabling these limits sooner could have saved companies a lot of time, headaches and money for support. But it's never too late, simplify users life now. > This patch increases the default limits (nearly) to the maximum, which is > perfect for case b). The defaults are used after boot and as the initial > value for each new namespace. > > Admins/distros that need a protection against a) should reduce the limits > and/or enable shm_rmid_forced. > > Further notes: > - The patch only changes default, overrides behave as before: > # sysctl kernel.shmall=33554432 > would recreate the previous limit for SHMMAX (for the current namespace). > > - Disabling sysv shm allocation is possible with: > # sysctl kernel.shmall=0 > (not a new feature, also per-namespace) > > - The limits are intentionally set to a value slightly less than ULONG_MAX, > to avoid triggering overflows in user space apps. > [not unreasonable, see http://marc.info/?l=linux-mm&m=139638334330127] > > Signed-off-by: Manfred Spraul > Reported-by: Davidlohr Bueso > Cc: mtk.manpages@gmail.com > --- > include/linux/shm.h | 3 +-- > include/uapi/linux/shm.h | 8 +++----- > 2 files changed, 4 insertions(+), 7 deletions(-) > > diff --git a/include/linux/shm.h b/include/linux/shm.h > index 1e2cd2e..57d7770 100644 > --- a/include/linux/shm.h > +++ b/include/linux/shm.h > @@ -3,9 +3,8 @@ > > #include > #include > - > -#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) */ > #include > + > struct shmid_kernel /* private to the kernel */ > { > struct kern_ipc_perm shm_perm; > diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h > index 78b6941..74e786d 100644 > --- a/include/uapi/linux/shm.h > +++ b/include/uapi/linux/shm.h > @@ -9,15 +9,13 @@ > > /* > * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can > - * be increased by sysctl > + * be modified by sysctl. > */ > > -#define SHMMAX 0x2000000 /* max shared seg size (bytes) */ > #define SHMMIN 1 /* min shared seg size (bytes) */ > #define SHMMNI 4096 /* max num of segs system wide */ > -#ifndef __KERNEL__ > -#define SHMALL (SHMMAX/getpagesize()*(SHMMNI/16)) > -#endif > +#define SHMMAX (ULONG_MAX - (1L<<24)) /* max shared seg size (bytes) */ > +#define SHMALL (ULONG_MAX - (1L<<24)) /* max shm system wide (pages) */ > #define SHMSEG SHMMNI /* max shared segs per process */ > > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) by kanga.kvack.org (Postfix) with ESMTP id BECA86B006E for ; Tue, 22 Apr 2014 16:18:38 -0400 (EDT) Received: by mail-ig0-f171.google.com with SMTP id c1so3477641igq.10 for ; Tue, 22 Apr 2014 13:18:38 -0700 (PDT) Received: from fujitsu25.fnanic.fujitsu.com (fujitsu25.fnanic.fujitsu.com. [192.240.6.15]) by mx.google.com with ESMTPS id bo3si15856571icc.10.2014.04.22.13.18.37 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Apr 2014 13:18:37 -0700 (PDT) From: Motohiro Kosaki Date: Tue, 22 Apr 2014 13:16:38 -0700 Subject: RE: [PATCH 3/4] ipc/shm.c: check for integer overflow during shmget. Message-ID: <6B2BA408B38BA1478B473C31C3D2074E30989E9D81@SV-EXCHANGE1.Corp.FC.LOCAL> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> <1398090397-2397-4-git-send-email-manfred@colorfullife.com> <1398190745.2473.10.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1398190745.2473.10.camel@buesod1.americas.hpqcorp.net> Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso , Manfred Spraul Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , Motohiro Kosaki JP , "gthelen@google.com" , "aswin@hp.com" , "linux-mm@kvack.org" PiA+IFNITU1BWCBpcyB0aGUgdXBwZXIgbGltaXQgZm9yIHRoZSBzaXplIG9mIGEgc2hhcmVkIG1l bW9yeSBzZWdtZW50LA0KPiA+IGNvdW50ZWQgaW4gYnl0ZXMuIFRoZSBhY3R1YWwgYWxsb2NhdGlv biBpcyB0aGF0IHNpemUsIHJvdW5kZWQgdXAgdG8NCj4gPiB0aGUgbmV4dCBmdWxsIHBhZ2UuDQo+ ID4gQWRkIGEgY2hlY2sgdGhhdCBwcmV2ZW50cyB0aGUgY3JlYXRpb24gb2Ygc2VnbWVudHMgd2hl cmUgdGhlIHJvdW5kZWQNCj4gPiB1cCBzaXplIGNhdXNlcyBhbiBpbnRlZ2VyIG92ZXJmbG93Lg0K PiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogTWFuZnJlZCBTcHJhdWwgPG1hbmZyZWRAY29sb3JmdWxs aWZlLmNvbT4NCj4gDQo+IEFja2VkLWJ5OiBEYXZpZGxvaHIgQnVlc28gPGRhdmlkbG9ockBocC5j b20+DQoNCkFja2VkLWJ5OiBLT1NBS0kgTW90b2hpcm8gPGtvc2FraS5tb3RvaGlyb0BqcC5mdWpp dHN1LmNvbT4NCg== -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) by kanga.kvack.org (Postfix) with ESMTP id D1DA16B0070 for ; Tue, 22 Apr 2014 16:18:54 -0400 (EDT) Received: by mail-ig0-f178.google.com with SMTP id hn18so139819igb.11 for ; Tue, 22 Apr 2014 13:18:54 -0700 (PDT) Received: from fujitsu24.fnanic.fujitsu.com (fujitsu24.fnanic.fujitsu.com. [192.240.6.14]) by mx.google.com with ESMTPS id rv8si13475948igb.32.2014.04.22.13.18.54 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Apr 2014 13:18:54 -0700 (PDT) From: Motohiro Kosaki Date: Tue, 22 Apr 2014 13:15:44 -0700 Subject: RE: [PATCH 1/4] ipc/shm.c: check for ulong overflows in shmat Message-ID: <6B2BA408B38BA1478B473C31C3D2074E30989E9D7A@SV-EXCHANGE1.Corp.FC.LOCAL> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398190717.2473.8.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1398190717.2473.8.camel@buesod1.americas.hpqcorp.net> Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso , Manfred Spraul Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , Motohiro Kosaki JP , "gthelen@google.com" , "aswin@hp.com" , "linux-mm@kvack.org" PiA+IGZpbmRfdm1hX2ludGVyc2VjdGlvbiBkb2VzIG5vdCB3b3JrIGFzIGludGVuZGVkIGlmIGFk ZHIrc2l6ZSBvdmVyZmxvd3MuDQo+ID4gVGhlIHBhdGNoIGFkZHMgYSBtYW51YWwgY2hlY2sgYmVm b3JlIHRoZSBjYWxsIHRvIGZpbmRfdm1hX2ludGVyc2VjdGlvbi4NCj4gPg0KPiA+IFNpZ25lZC1v ZmYtYnk6IE1hbmZyZWQgU3ByYXVsIDxtYW5mcmVkQGNvbG9yZnVsbGlmZS5jb20+DQo+IA0KPiBB Y2tlZC1ieTogRGF2aWRsb2hyIEJ1ZXNvIDxkYXZpZGxvaHJAaHAuY29tPg0KDQpBY2tlZC1ieTog S09TQUtJIE1vdG9oaXJvIDxrb3Nha2kubW90b2hpcm9AanAuZnVqaXRzdS5jb20+DQoNCg== -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yh0-f43.google.com (mail-yh0-f43.google.com [209.85.213.43]) by kanga.kvack.org (Postfix) with ESMTP id 109716B0072 for ; Tue, 22 Apr 2014 16:19:02 -0400 (EDT) Received: by mail-yh0-f43.google.com with SMTP id b6so5303716yha.2 for ; Tue, 22 Apr 2014 13:19:01 -0700 (PDT) Received: from fujitsu24.fnanic.fujitsu.com (fujitsu24.fnanic.fujitsu.com. [192.240.6.14]) by mx.google.com with ESMTPS id f1si8552908yhh.103.2014.04.22.13.19.01 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Apr 2014 13:19:01 -0700 (PDT) From: Motohiro Kosaki Date: Tue, 22 Apr 2014 13:16:11 -0700 Subject: RE: [PATCH 2/4] ipc/shm.c: check for overflows of shm_tot Message-ID: <6B2BA408B38BA1478B473C31C3D2074E30989E9D7E@SV-EXCHANGE1.Corp.FC.LOCAL> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> <1398190732.2473.9.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1398190732.2473.9.camel@buesod1.americas.hpqcorp.net> Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso , Manfred Spraul Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , Motohiro Kosaki JP , "gthelen@google.com" , "aswin@hp.com" , "linux-mm@kvack.org" PiA+IHNobV90b3QgY291bnRzIHRoZSB0b3RhbCBudW1iZXIgb2YgcGFnZXMgdXNlZCBieSBzaG0g c2VnbWVudHMuDQo+ID4NCj4gPiBJZiBTSE1BTEwgaXMgVUxPTkdfTUFYIChvciBuZWFybHkgVUxP TkdfTUFYKSwgdGhlbiB0aGUgbnVtYmVyIGNhbg0KPiA+IG92ZXJmbG93LiAgU3Vic2VxdWVudCBj YWxscyB0byBzaG1jdGwoLFNITV9JTkZPLCkgd291bGQgcmV0dXJuIHdyb25nDQo+ID4gdmFsdWVz IGZvciBzaG1fdG90Lg0KPiA+DQo+ID4gVGhlIHBhdGNoIGFkZHMgYSBkZXRlY3Rpb24gZm9yIG92 ZXJmbG93cy4NCj4gPg0KPiA+IFNpZ25lZC1vZmYtYnk6IE1hbmZyZWQgU3ByYXVsIDxtYW5mcmVk QGNvbG9yZnVsbGlmZS5jb20+DQo+IA0KPiBBY2tlZC1ieTogRGF2aWRsb2hyIEJ1ZXNvIDxkYXZp ZGxvaHJAaHAuY29tPg0KDQpBY2tlZC1ieTogS09TQUtJIE1vdG9oaXJvIDxrb3Nha2kubW90b2hp cm9AanAuZnVqaXRzdS5jb20+DQo= -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yh0-f42.google.com (mail-yh0-f42.google.com [209.85.213.42]) by kanga.kvack.org (Postfix) with ESMTP id E63C46B0074 for ; Tue, 22 Apr 2014 16:19:26 -0400 (EDT) Received: by mail-yh0-f42.google.com with SMTP id v1so3500335yhn.15 for ; Tue, 22 Apr 2014 13:19:26 -0700 (PDT) Received: from fujitsu24.fnanic.fujitsu.com (fujitsu24.fnanic.fujitsu.com. [192.240.6.14]) by mx.google.com with ESMTPS id v6si33982917yhm.170.2014.04.22.13.19.25 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Apr 2014 13:19:26 -0700 (PDT) From: Motohiro Kosaki Date: Tue, 22 Apr 2014 13:17:15 -0700 Subject: RE: [PATCH 4/4] ipc/shm.c: Increase the defaults for SHMALL, SHMMAX. Message-ID: <6B2BA408B38BA1478B473C31C3D2074E30989E9D84@SV-EXCHANGE1.Corp.FC.LOCAL> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> <1398090397-2397-4-git-send-email-manfred@colorfullife.com> <1398090397-2397-5-git-send-email-manfred@colorfullife.com> In-Reply-To: <1398090397-2397-5-git-send-email-manfred@colorfullife.com> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-linux-mm@kvack.org List-ID: To: Manfred Spraul , Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky Cc: LKML , Andrew Morton , KAMEZAWA Hiroyuki , Motohiro Kosaki JP , "gthelen@google.com" , "aswin@hp.com" , "linux-mm@kvack.org" > -----Original Message----- > From: Manfred Spraul [mailto:manfred@colorfullife.com] > Sent: Monday, April 21, 2014 10:27 AM > To: Davidlohr Bueso; Michael Kerrisk; Martin Schwidefsky > Cc: LKML; Andrew Morton; KAMEZAWA Hiroyuki; Motohiro Kosaki JP; gthelen@g= oogle.com; aswin@hp.com; linux-mm@kvack.org; > Manfred Spraul > Subject: [PATCH 4/4] ipc/shm.c: Increase the defaults for SHMALL, SHMMAX. >=20 > System V shared memory >=20 > a) can be abused to trigger out-of-memory conditions and the standard > measures against out-of-memory do not work: >=20 > - it is not possible to use setrlimit to limit the size of shm segmen= ts. >=20 > - segments can exist without association with any processes, thus > the oom-killer is unable to free that memory. >=20 > b) is typically used for shared information - today often multiple GB. > (e.g. database shared buffers) >=20 > The current default is a maximum segment size of 32 MB and a maximum tota= l size of 8 GB. This is often too much for a) and not > enough for b), which means that lots of users must change the defaults. >=20 > This patch increases the default limits (nearly) to the maximum, which is= perfect for case b). The defaults are used after boot and as > the initial value for each new namespace. >=20 > Admins/distros that need a protection against a) should reduce the limits= and/or enable shm_rmid_forced. >=20 > Further notes: > - The patch only changes default, overrides behave as before: > # sysctl kernel.shmall=3D33554432 > would recreate the previous limit for SHMMAX (for the current namespace= ). >=20 > - Disabling sysv shm allocation is possible with: > # sysctl kernel.shmall=3D0 > (not a new feature, also per-namespace) >=20 > - The limits are intentionally set to a value slightly less than ULONG_MA= X, > to avoid triggering overflows in user space apps. > [not unreasonable, see http://marc.info/?l=3Dlinux-mm&m=3D1396383343301= 27] >=20 > Signed-off-by: Manfred Spraul > Reported-by: Davidlohr Bueso > Cc: mtk.manpages@gmail.com Acked-by: KOSAKI Motohiro -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by kanga.kvack.org (Postfix) with ESMTP id E19766B0070 for ; Tue, 22 Apr 2014 22:54:03 -0400 (EDT) Received: by mail-pa0-f48.google.com with SMTP id hz1so279211pad.7 for ; Tue, 22 Apr 2014 19:54:03 -0700 (PDT) Received: from g2t2354.austin.hp.com (g2t2354.austin.hp.com. [15.217.128.53]) by mx.google.com with ESMTPS id fn10si22994018pad.197.2014.04.22.19.54.02 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Apr 2014 19:54:02 -0700 (PDT) Message-ID: <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> Subject: [PATCH 5/4] ipc,shm: minor cleanups From: Davidlohr Bueso Date: Tue, 22 Apr 2014 19:53:56 -0700 In-Reply-To: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Manfred Spraul Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org - Breakup long function names/args. - Cleaup variable declaration. - s/current->mm/mm Signed-off-by: Davidlohr Bueso --- ipc/shm.c | 40 +++++++++++++++++----------------------- 1 file changed, 17 insertions(+), 23 deletions(-) diff --git a/ipc/shm.c b/ipc/shm.c index f000696..584d02e 100644 --- a/ipc/shm.c +++ b/ipc/shm.c @@ -480,15 +480,13 @@ static const struct vm_operations_struct shm_vm_ops = { static int newseg(struct ipc_namespace *ns, struct ipc_params *params) { key_t key = params->key; - int shmflg = params->flg; + int id, error, shmflg = params->flg; size_t size = params->u.size; - int error; - struct shmid_kernel *shp; size_t numpages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT; - struct file *file; char name[13]; - int id; vm_flags_t acctflag = 0; + struct shmid_kernel *shp; + struct file *file; if (size < SHMMIN || size > ns->shm_ctlmax) return -EINVAL; @@ -681,7 +679,8 @@ copy_shmid_from_user(struct shmid64_ds *out, void __user *buf, int version) } } -static inline unsigned long copy_shminfo_to_user(void __user *buf, struct shminfo64 *in, int version) +static inline unsigned long copy_shminfo_to_user(void __user *buf, + struct shminfo64 *in, int version) { switch (version) { case IPC_64: @@ -711,8 +710,8 @@ static inline unsigned long copy_shminfo_to_user(void __user *buf, struct shminf * Calculate and add used RSS and swap pages of a shm. * Called with shm_ids.rwsem held as a reader */ -static void shm_add_rss_swap(struct shmid_kernel *shp, - unsigned long *rss_add, unsigned long *swp_add) +static void shm_add_rss_swap(struct shmid_kernel *shp, unsigned long *rss_add, + unsigned long *swp_add) { struct inode *inode; @@ -739,7 +738,7 @@ static void shm_add_rss_swap(struct shmid_kernel *shp, * Called with shm_ids.rwsem held as a reader */ static void shm_get_stat(struct ipc_namespace *ns, unsigned long *rss, - unsigned long *swp) + unsigned long *swp) { int next_id; int total, in_use; @@ -1047,21 +1046,16 @@ out_unlock1: long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr, unsigned long shmlba) { - struct shmid_kernel *shp; - unsigned long addr; - unsigned long size; + unsigned long addr, size, flags, prot, populate = 0; struct file *file; - int err; - unsigned long flags; - unsigned long prot; - int acc_mode; + int acc_mode, err = -EINVAL; struct ipc_namespace *ns; struct shm_file_data *sfd; + struct shmid_kernel *shp; struct path path; fmode_t f_mode; - unsigned long populate = 0; + struct mm_struct *mm = current->mm; - err = -EINVAL; if (shmid < 0) goto out; else if ((addr = (ulong)shmaddr)) { @@ -1161,20 +1155,20 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr, if (err) goto out_fput; - down_write(¤t->mm->mmap_sem); + down_write(&mm->mmap_sem); if (addr && !(shmflg & SHM_REMAP)) { err = -EINVAL; if (addr + size < addr) goto invalid; - if (find_vma_intersection(current->mm, addr, addr + size)) + if (find_vma_intersection(mm, addr, addr + size)) goto invalid; /* * If shm segment goes below stack, make sure there is some * space left for the stack to grow (at least 4 pages). */ - if (addr < current->mm->start_stack && - addr > current->mm->start_stack - size - PAGE_SIZE * 5) + if (addr < mm->start_stack && + addr > mm->start_stack - size - PAGE_SIZE * 5) goto invalid; } @@ -1184,7 +1178,7 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr, if (IS_ERR_VALUE(addr)) err = (long)addr; invalid: - up_write(¤t->mm->mmap_sem); + up_write(&mm->mmap_sem); if (populate) mm_populate(addr, populate); -- 1.8.1.4 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by kanga.kvack.org (Postfix) with ESMTP id 290956B0070 for ; Wed, 23 Apr 2014 01:05:52 -0400 (EDT) Received: by mail-ee0-f48.google.com with SMTP id b57so287189eek.35 for ; Tue, 22 Apr 2014 22:05:51 -0700 (PDT) Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [2a00:1450:4013:c00::22b]) by mx.google.com with ESMTPS id z2si1326155eeo.64.2014.04.22.22.05.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Apr 2014 22:05:50 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id e53so290897eek.30 for ; Tue, 22 Apr 2014 22:05:50 -0700 (PDT) Message-ID: <53574867.5010108@gmail.com> Date: Wed, 23 Apr 2014 06:58:15 +0200 From: "Michael Kerrisk (man-pages)" MIME-Version: 1.0 Subject: Re: [PATCH 1/4] ipc/shm.c: check for ulong overflows in shmat References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> In-Reply-To: <1398090397-2397-2-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky Cc: mtk.manpages@gmail.com, LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org On 04/21/2014 04:26 PM, Manfred Spraul wrote: > find_vma_intersection does not work as intended if addr+size overflows. > The patch adds a manual check before the call to find_vma_intersection. > > Signed-off-by: Manfred Spraul > --- > ipc/shm.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/ipc/shm.c b/ipc/shm.c > index 7645961..382e2fb 100644 > --- a/ipc/shm.c > +++ b/ipc/shm.c > @@ -1160,6 +1160,9 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr, > down_write(¤t->mm->mmap_sem); > if (addr && !(shmflg & SHM_REMAP)) { > err = -EINVAL; > + if (addr + size < addr) > + goto invalid; > + > if (find_vma_intersection(current->mm, addr, addr + size)) > goto invalid; > /* > Acked-by: Michael Kerrisk -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by kanga.kvack.org (Postfix) with ESMTP id 2AB176B0070 for ; Wed, 23 Apr 2014 01:05:54 -0400 (EDT) Received: by mail-ee0-f44.google.com with SMTP id e49so291635eek.31 for ; Tue, 22 Apr 2014 22:05:53 -0700 (PDT) Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [2a00:1450:4013:c00::22b]) by mx.google.com with ESMTPS id d5si1306663eei.148.2014.04.22.22.05.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Apr 2014 22:05:52 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id e53so287710eek.16 for ; Tue, 22 Apr 2014 22:05:52 -0700 (PDT) Message-ID: <53574888.4090602@gmail.com> Date: Wed, 23 Apr 2014 06:58:48 +0200 From: "Michael Kerrisk (man-pages)" MIME-Version: 1.0 Subject: Re: [PATCH 2/4] ipc/shm.c: check for overflows of shm_tot References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> In-Reply-To: <1398090397-2397-3-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky Cc: mtk.manpages@gmail.com, LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org On 04/21/2014 04:26 PM, Manfred Spraul wrote: > shm_tot counts the total number of pages used by shm segments. > > If SHMALL is ULONG_MAX (or nearly ULONG_MAX), then the number > can overflow. Subsequent calls to shmctl(,SHM_INFO,) would return > wrong values for shm_tot. > > The patch adds a detection for overflows. > > Signed-off-by: Manfred Spraul > --- > ipc/shm.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/ipc/shm.c b/ipc/shm.c > index 382e2fb..2dfa3d6 100644 > --- a/ipc/shm.c > +++ b/ipc/shm.c > @@ -493,7 +493,8 @@ static int newseg(struct ipc_namespace *ns, struct ipc_params *params) > if (size < SHMMIN || size > ns->shm_ctlmax) > return -EINVAL; > > - if (ns->shm_tot + numpages > ns->shm_ctlall) > + if (ns->shm_tot + numpages < ns->shm_tot || > + ns->shm_tot + numpages > ns->shm_ctlall) > return -ENOSPC; > > shp = ipc_rcu_alloc(sizeof(*shp)); > Acked-by: Michael Kerrisk -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by kanga.kvack.org (Postfix) with ESMTP id E5FB26B0071 for ; Wed, 23 Apr 2014 01:05:56 -0400 (EDT) Received: by mail-ee0-f43.google.com with SMTP id e53so287752eek.16 for ; Tue, 22 Apr 2014 22:05:56 -0700 (PDT) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [2a00:1450:4013:c00::22c]) by mx.google.com with ESMTPS id g45si1304199eev.160.2014.04.22.22.05.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Apr 2014 22:05:55 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id e49so296717eek.3 for ; Tue, 22 Apr 2014 22:05:55 -0700 (PDT) Message-ID: <535748AD.9000804@gmail.com> Date: Wed, 23 Apr 2014 06:59:25 +0200 From: "Michael Kerrisk (man-pages)" MIME-Version: 1.0 Subject: Re: [PATCH 3/4] ipc/shm.c: check for integer overflow during shmget. References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> <1398090397-2397-4-git-send-email-manfred@colorfullife.com> In-Reply-To: <1398090397-2397-4-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky Cc: mtk.manpages@gmail.com, LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org On 04/21/2014 04:26 PM, Manfred Spraul wrote: > SHMMAX is the upper limit for the size of a shared memory segment, > counted in bytes. The actual allocation is that size, rounded up to > the next full page. > Add a check that prevents the creation of segments where the > rounded up size causes an integer overflow. > > Signed-off-by: Manfred Spraul > --- > ipc/shm.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/ipc/shm.c b/ipc/shm.c > index 2dfa3d6..f000696 100644 > --- a/ipc/shm.c > +++ b/ipc/shm.c > @@ -493,6 +493,9 @@ static int newseg(struct ipc_namespace *ns, struct ipc_params *params) > if (size < SHMMIN || size > ns->shm_ctlmax) > return -EINVAL; > > + if (numpages << PAGE_SHIFT < size) > + return -ENOSPC; > + > if (ns->shm_tot + numpages < ns->shm_tot || > ns->shm_tot + numpages > ns->shm_ctlall) > return -ENOSPC; > Acked-by: Michael Kerrisk -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by kanga.kvack.org (Postfix) with ESMTP id DFB4B6B0073 for ; Wed, 23 Apr 2014 01:05:58 -0400 (EDT) Received: by mail-ee0-f50.google.com with SMTP id c13so288394eek.23 for ; Tue, 22 Apr 2014 22:05:58 -0700 (PDT) Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [2a00:1450:4013:c00::232]) by mx.google.com with ESMTPS id q5si1268508eem.321.2014.04.22.22.05.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Apr 2014 22:05:57 -0700 (PDT) Received: by mail-ee0-f50.google.com with SMTP id c13so282809eek.37 for ; Tue, 22 Apr 2014 22:05:57 -0700 (PDT) Message-ID: <5357490E.1010505@gmail.com> Date: Wed, 23 Apr 2014 07:01:02 +0200 From: "Michael Kerrisk (man-pages)" MIME-Version: 1.0 Subject: Re: [PATCH 4/4] ipc/shm.c: Increase the defaults for SHMALL, SHMMAX. References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> <1398090397-2397-4-git-send-email-manfred@colorfullife.com> <1398090397-2397-5-git-send-email-manfred@colorfullife.com> In-Reply-To: <1398090397-2397-5-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky Cc: mtk.manpages@gmail.com, LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org On 04/21/2014 04:26 PM, Manfred Spraul wrote: > System V shared memory > > a) can be abused to trigger out-of-memory conditions and the standard > measures against out-of-memory do not work: > > - it is not possible to use setrlimit to limit the size of shm segments. > > - segments can exist without association with any processes, thus > the oom-killer is unable to free that memory. > > b) is typically used for shared information - today often multiple GB. > (e.g. database shared buffers) > > The current default is a maximum segment size of 32 MB and a maximum total > size of 8 GB. This is often too much for a) and not enough for b), which > means that lots of users must change the defaults. > > This patch increases the default limits (nearly) to the maximum, which is > perfect for case b). The defaults are used after boot and as the initial > value for each new namespace. > > Admins/distros that need a protection against a) should reduce the limits > and/or enable shm_rmid_forced. > > Further notes: > - The patch only changes default, overrides behave as before: > # sysctl kernel.shmall=33554432 > would recreate the previous limit for SHMMAX (for the current namespace). > > - Disabling sysv shm allocation is possible with: > # sysctl kernel.shmall=0 > (not a new feature, also per-namespace) > > - The limits are intentionally set to a value slightly less than ULONG_MAX, > to avoid triggering overflows in user space apps. > [not unreasonable, see http://marc.info/?l=linux-mm&m=139638334330127] > > Signed-off-by: Manfred Spraul > Reported-by: Davidlohr Bueso > Cc: mtk.manpages@gmail.com > --- > include/linux/shm.h | 3 +-- > include/uapi/linux/shm.h | 8 +++----- > 2 files changed, 4 insertions(+), 7 deletions(-) > > diff --git a/include/linux/shm.h b/include/linux/shm.h > index 1e2cd2e..57d7770 100644 > --- a/include/linux/shm.h > +++ b/include/linux/shm.h > @@ -3,9 +3,8 @@ > > #include > #include > - > -#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) */ > #include > + > struct shmid_kernel /* private to the kernel */ > { > struct kern_ipc_perm shm_perm; > diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h > index 78b6941..74e786d 100644 > --- a/include/uapi/linux/shm.h > +++ b/include/uapi/linux/shm.h > @@ -9,15 +9,13 @@ > > /* > * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can > - * be increased by sysctl > + * be modified by sysctl. > */ > > -#define SHMMAX 0x2000000 /* max shared seg size (bytes) */ > #define SHMMIN 1 /* min shared seg size (bytes) */ > #define SHMMNI 4096 /* max num of segs system wide */ > -#ifndef __KERNEL__ > -#define SHMALL (SHMMAX/getpagesize()*(SHMMNI/16)) > -#endif > +#define SHMMAX (ULONG_MAX - (1L<<24)) /* max shared seg size (bytes) */ > +#define SHMALL (ULONG_MAX - (1L<<24)) /* max shm system wide (pages) */ > #define SHMSEG SHMMNI /* max shared segs per process */ Acked-by: Michael Kerrisk -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by kanga.kvack.org (Postfix) with ESMTP id 52F156B0070 for ; Wed, 23 Apr 2014 01:07:52 -0400 (EDT) Received: by mail-ee0-f42.google.com with SMTP id d17so292970eek.15 for ; Tue, 22 Apr 2014 22:07:51 -0700 (PDT) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [2a00:1450:4013:c00::22c]) by mx.google.com with ESMTPS id 43si1301739eer.207.2014.04.22.22.07.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Apr 2014 22:07:51 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id e49so297595eek.3 for ; Tue, 22 Apr 2014 22:07:50 -0700 (PDT) Message-ID: <53574AA5.1060205@gmail.com> Date: Wed, 23 Apr 2014 07:07:49 +0200 From: "Michael Kerrisk (man-pages)" MIME-Version: 1.0 Subject: Re: [PATCH 5/4] ipc,shm: minor cleanups References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso , Manfred Spraul Cc: mtk.manpages@gmail.com, Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org On 04/23/2014 04:53 AM, Davidlohr Bueso wrote: > - Breakup long function names/args. > - Cleaup variable declaration. > - s/current->mm/mm > > Signed-off-by: Davidlohr Bueso > --- > ipc/shm.c | 40 +++++++++++++++++----------------------- > 1 file changed, 17 insertions(+), 23 deletions(-) > > diff --git a/ipc/shm.c b/ipc/shm.c > index f000696..584d02e 100644 > --- a/ipc/shm.c > +++ b/ipc/shm.c > @@ -480,15 +480,13 @@ static const struct vm_operations_struct shm_vm_ops = { > static int newseg(struct ipc_namespace *ns, struct ipc_params *params) > { > key_t key = params->key; > - int shmflg = params->flg; > + int id, error, shmflg = params->flg; It's largely a matter of taste (and I may be in a minority), and I know there's certainly precedent in the kernel code, but I don't much like the style of mixing variable declarations that have initializers, with other unrelated declarations (e.g., variables without initializers). What is the gain? One less line of text? That's (IMO) more than offset by the small loss of readability. Cheers, Michael > size_t size = params->u.size; > - int error; > - struct shmid_kernel *shp; > size_t numpages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT; > - struct file *file; > char name[13]; > - int id; > vm_flags_t acctflag = 0; > + struct shmid_kernel *shp; > + struct file *file; > > if (size < SHMMIN || size > ns->shm_ctlmax) > return -EINVAL; > @@ -681,7 +679,8 @@ copy_shmid_from_user(struct shmid64_ds *out, void __user *buf, int version) > } > } > > -static inline unsigned long copy_shminfo_to_user(void __user *buf, struct shminfo64 *in, int version) > +static inline unsigned long copy_shminfo_to_user(void __user *buf, > + struct shminfo64 *in, int version) > { > switch (version) { > case IPC_64: > @@ -711,8 +710,8 @@ static inline unsigned long copy_shminfo_to_user(void __user *buf, struct shminf > * Calculate and add used RSS and swap pages of a shm. > * Called with shm_ids.rwsem held as a reader > */ > -static void shm_add_rss_swap(struct shmid_kernel *shp, > - unsigned long *rss_add, unsigned long *swp_add) > +static void shm_add_rss_swap(struct shmid_kernel *shp, unsigned long *rss_add, > + unsigned long *swp_add) > { > struct inode *inode; > > @@ -739,7 +738,7 @@ static void shm_add_rss_swap(struct shmid_kernel *shp, > * Called with shm_ids.rwsem held as a reader > */ > static void shm_get_stat(struct ipc_namespace *ns, unsigned long *rss, > - unsigned long *swp) > + unsigned long *swp) > { > int next_id; > int total, in_use; > @@ -1047,21 +1046,16 @@ out_unlock1: > long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr, > unsigned long shmlba) > { > - struct shmid_kernel *shp; > - unsigned long addr; > - unsigned long size; > + unsigned long addr, size, flags, prot, populate = 0; > struct file *file; > - int err; > - unsigned long flags; > - unsigned long prot; > - int acc_mode; > + int acc_mode, err = -EINVAL; > struct ipc_namespace *ns; > struct shm_file_data *sfd; > + struct shmid_kernel *shp; > struct path path; > fmode_t f_mode; > - unsigned long populate = 0; > + struct mm_struct *mm = current->mm; > > - err = -EINVAL; > if (shmid < 0) > goto out; > else if ((addr = (ulong)shmaddr)) { > @@ -1161,20 +1155,20 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr, > if (err) > goto out_fput; > > - down_write(¤t->mm->mmap_sem); > + down_write(&mm->mmap_sem); > if (addr && !(shmflg & SHM_REMAP)) { > err = -EINVAL; > if (addr + size < addr) > goto invalid; > > - if (find_vma_intersection(current->mm, addr, addr + size)) > + if (find_vma_intersection(mm, addr, addr + size)) > goto invalid; > /* > * If shm segment goes below stack, make sure there is some > * space left for the stack to grow (at least 4 pages). > */ > - if (addr < current->mm->start_stack && > - addr > current->mm->start_stack - size - PAGE_SIZE * 5) > + if (addr < mm->start_stack && > + addr > mm->start_stack - size - PAGE_SIZE * 5) > goto invalid; > } > > @@ -1184,7 +1178,7 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr, > if (IS_ERR_VALUE(addr)) > err = (long)addr; > invalid: > - up_write(¤t->mm->mmap_sem); > + up_write(&mm->mmap_sem); > if (populate) > mm_populate(addr, populate); > > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by kanga.kvack.org (Postfix) with ESMTP id ADA3B6B0070 for ; Wed, 23 Apr 2014 01:25:50 -0400 (EDT) Received: by mail-ob0-f174.google.com with SMTP id gq1so507374obb.33 for ; Tue, 22 Apr 2014 22:25:50 -0700 (PDT) Received: from g4t3426.houston.hp.com (g4t3426.houston.hp.com. [15.201.208.54]) by mx.google.com with ESMTPS id pu6si33127768oeb.106.2014.04.22.22.25.49 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Apr 2014 22:25:50 -0700 (PDT) Message-ID: <1398230745.27667.2.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 5/4] ipc,shm: minor cleanups From: Davidlohr Bueso Date: Tue, 22 Apr 2014 22:25:45 -0700 In-Reply-To: <53574AA5.1060205@gmail.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> <53574AA5.1060205@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: "Michael Kerrisk (man-pages)" Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org On Wed, 2014-04-23 at 07:07 +0200, Michael Kerrisk (man-pages) wrote: > On 04/23/2014 04:53 AM, Davidlohr Bueso wrote: > > - Breakup long function names/args. > > - Cleaup variable declaration. > > - s/current->mm/mm > > > > Signed-off-by: Davidlohr Bueso > > --- > > ipc/shm.c | 40 +++++++++++++++++----------------------- > > 1 file changed, 17 insertions(+), 23 deletions(-) > > > > diff --git a/ipc/shm.c b/ipc/shm.c > > index f000696..584d02e 100644 > > --- a/ipc/shm.c > > +++ b/ipc/shm.c > > @@ -480,15 +480,13 @@ static const struct vm_operations_struct shm_vm_ops = { > > static int newseg(struct ipc_namespace *ns, struct ipc_params *params) > > { > > key_t key = params->key; > > - int shmflg = params->flg; > > + int id, error, shmflg = params->flg; > > It's largely a matter of taste (and I may be in a minority), and I know > there's certainly precedent in the kernel code, but I don't much like the > style of mixing variable declarations that have initializers, with other > unrelated declarations (e.g., variables without initializers). What is > the gain? One less line of text? That's (IMO) more than offset by the > small loss of readability. Yes, it's taste. And yes, your in the minority, at least in many core kernel components and ipc. Thanks, Davidlohr -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by kanga.kvack.org (Postfix) with ESMTP id 73C5A6B0070 for ; Wed, 23 Apr 2014 01:28:57 -0400 (EDT) Received: by mail-ee0-f53.google.com with SMTP id b57so303925eek.12 for ; Tue, 22 Apr 2014 22:28:56 -0700 (PDT) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [2a00:1450:4013:c00::22c]) by mx.google.com with ESMTPS id q5si1356107eem.321.2014.04.22.22.28.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Apr 2014 22:28:56 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id e49so303858eek.31 for ; Tue, 22 Apr 2014 22:28:55 -0700 (PDT) Message-ID: <53574F94.4060402@gmail.com> Date: Wed, 23 Apr 2014 07:28:52 +0200 From: "Michael Kerrisk (man-pages)" MIME-Version: 1.0 Subject: Re: [PATCH 5/4] ipc,shm: minor cleanups References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> <53574AA5.1060205@gmail.com> <1398230745.27667.2.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1398230745.27667.2.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso Cc: mtk.manpages@gmail.com, Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org On 04/23/2014 07:25 AM, Davidlohr Bueso wrote: > On Wed, 2014-04-23 at 07:07 +0200, Michael Kerrisk (man-pages) wrote: >> On 04/23/2014 04:53 AM, Davidlohr Bueso wrote: >>> - Breakup long function names/args. >>> - Cleaup variable declaration. >>> - s/current->mm/mm >>> >>> Signed-off-by: Davidlohr Bueso >>> --- >>> ipc/shm.c | 40 +++++++++++++++++----------------------- >>> 1 file changed, 17 insertions(+), 23 deletions(-) >>> >>> diff --git a/ipc/shm.c b/ipc/shm.c >>> index f000696..584d02e 100644 >>> --- a/ipc/shm.c >>> +++ b/ipc/shm.c >>> @@ -480,15 +480,13 @@ static const struct vm_operations_struct shm_vm_ops = { >>> static int newseg(struct ipc_namespace *ns, struct ipc_params *params) >>> { >>> key_t key = params->key; >>> - int shmflg = params->flg; >>> + int id, error, shmflg = params->flg; >> >> It's largely a matter of taste (and I may be in a minority), and I know >> there's certainly precedent in the kernel code, but I don't much like the >> style of mixing variable declarations that have initializers, with other >> unrelated declarations (e.g., variables without initializers). What is >> the gain? One less line of text? That's (IMO) more than offset by the >> small loss of readability. > > Yes, it's taste. And yes, your in the minority, at least in many core > kernel components and ipc. I figured so. Just giving the minority a small voice ;-). -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by kanga.kvack.org (Postfix) with ESMTP id 8C5AB6B0037 for ; Wed, 23 Apr 2014 14:18:41 -0400 (EDT) Received: by mail-ee0-f44.google.com with SMTP id e49so1060382eek.31 for ; Wed, 23 Apr 2014 11:18:40 -0700 (PDT) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by mx.google.com with ESMTPS id r9si4306566eew.288.2014.04.23.11.18.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Apr 2014 11:18:40 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id t10so1045375eei.5 for ; Wed, 23 Apr 2014 11:18:39 -0700 (PDT) Message-ID: <535803FC.1040605@colorfullife.com> Date: Wed, 23 Apr 2014 20:18:36 +0200 From: Manfred Spraul MIME-Version: 1.0 Subject: Re: [PATCH 5/4] ipc,shm: minor cleanups References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org On 04/23/2014 04:53 AM, Davidlohr Bueso wrote: > - Breakup long function names/args. > - Cleaup variable declaration. s/Cleaup/Cleanup/ > - s/current->mm/mm > > Signed-off-by: Davidlohr Bueso Signed-off-by: Manfred Spraul > @@ -681,7 +679,8 @@ copy_shmid_from_user(struct shmid64_ds *out, void __user *buf, int version) > } > } > > -static inline unsigned long copy_shminfo_to_user(void __user *buf, struct shminfo64 *in, int version) > +static inline unsigned long copy_shminfo_to_user(void __user *buf, > + struct shminfo64 *in, int version) Checkpatch still complains - does removing one tab help? -- Manfred -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by kanga.kvack.org (Postfix) with ESMTP id 03B496B0037 for ; Wed, 23 Apr 2014 18:27:58 -0400 (EDT) Received: by mail-pd0-f171.google.com with SMTP id r10so1211149pdi.2 for ; Wed, 23 Apr 2014 15:27:58 -0700 (PDT) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org. [140.211.169.12]) by mx.google.com with ESMTP id qf5si1407057pac.88.2014.04.23.15.27.57 for ; Wed, 23 Apr 2014 15:27:57 -0700 (PDT) Date: Wed, 23 Apr 2014 15:27:55 -0700 From: Andrew Morton Subject: Re: [PATCH 5/4] ipc,shm: minor cleanups Message-Id: <20140423152755.7f323cfd0e6901a2907afca8@linux-foundation.org> In-Reply-To: <1398230745.27667.2.camel@buesod1.americas.hpqcorp.net> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> <53574AA5.1060205@gmail.com> <1398230745.27667.2.camel@buesod1.americas.hpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso Cc: "Michael Kerrisk (man-pages)" , Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org On Tue, 22 Apr 2014 22:25:45 -0700 Davidlohr Bueso wrote: > On Wed, 2014-04-23 at 07:07 +0200, Michael Kerrisk (man-pages) wrote: > > On 04/23/2014 04:53 AM, Davidlohr Bueso wrote: > > > - Breakup long function names/args. > > > - Cleaup variable declaration. > > > - s/current->mm/mm > > > > > > Signed-off-by: Davidlohr Bueso > > > --- > > > ipc/shm.c | 40 +++++++++++++++++----------------------- > > > 1 file changed, 17 insertions(+), 23 deletions(-) > > > > > > diff --git a/ipc/shm.c b/ipc/shm.c > > > index f000696..584d02e 100644 > > > --- a/ipc/shm.c > > > +++ b/ipc/shm.c > > > @@ -480,15 +480,13 @@ static const struct vm_operations_struct shm_vm_ops = { > > > static int newseg(struct ipc_namespace *ns, struct ipc_params *params) > > > { > > > key_t key = params->key; > > > - int shmflg = params->flg; > > > + int id, error, shmflg = params->flg; > > > > It's largely a matter of taste (and I may be in a minority), and I know > > there's certainly precedent in the kernel code, but I don't much like the > > style of mixing variable declarations that have initializers, with other > > unrelated declarations (e.g., variables without initializers). What is > > the gain? One less line of text? That's (IMO) more than offset by the > > small loss of readability. > > Yes, it's taste. And yes, your in the minority, at least in many core > kernel components and ipc. I'm with Michael. - Putting multiple definitions on the same line (whether or not they are initialized there) makes it impossible to add little comments documenting them. And we need more little comments documenting locals. - Having multiple definitions on the same line is maddening when the time comes to resolve patch conflicts. And it increases the likelihood of conflicts in the first place. - It makes it much harder to *find* a definition. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by kanga.kvack.org (Postfix) with ESMTP id C19EE6B0035 for ; Wed, 23 Apr 2014 18:35:27 -0400 (EDT) Received: by mail-pd0-f181.google.com with SMTP id w10so1226818pde.12 for ; Wed, 23 Apr 2014 15:35:27 -0700 (PDT) Received: from ozlabs.org (ozlabs.org. [103.22.144.67]) by mx.google.com with ESMTPS id db3si1404663pbc.359.2014.04.23.15.35.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Apr 2014 15:35:26 -0700 (PDT) Date: Thu, 24 Apr 2014 08:35:15 +1000 From: Stephen Rothwell Subject: Re: [PATCH 5/4] ipc,shm: minor cleanups Message-Id: <20140424083515.b113760f062072e69d1899ac@canb.auug.org.au> In-Reply-To: <20140423152755.7f323cfd0e6901a2907afca8@linux-foundation.org> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> <53574AA5.1060205@gmail.com> <1398230745.27667.2.camel@buesod1.americas.hpqcorp.net> <20140423152755.7f323cfd0e6901a2907afca8@linux-foundation.org> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA256"; boundary="Signature=_Thu__24_Apr_2014_08_35_15_+1000_wcig3Jp=HffsP76." Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton Cc: Davidlohr Bueso , "Michael Kerrisk (man-pages)" , Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org --Signature=_Thu__24_Apr_2014_08_35_15_+1000_wcig3Jp=HffsP76. Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 23 Apr 2014 15:27:55 -0700 Andrew Morton wrote: > > On Tue, 22 Apr 2014 22:25:45 -0700 Davidlohr Bueso wro= te: >=20 > > On Wed, 2014-04-23 at 07:07 +0200, Michael Kerrisk (man-pages) wrote: > > > On 04/23/2014 04:53 AM, Davidlohr Bueso wrote: > > > > - Breakup long function names/args. > > > > - Cleaup variable declaration. > > > > - s/current->mm/mm > > > >=20 > > > > Signed-off-by: Davidlohr Bueso > > > > --- > > > > ipc/shm.c | 40 +++++++++++++++++----------------------- > > > > 1 file changed, 17 insertions(+), 23 deletions(-) > > > >=20 > > > > diff --git a/ipc/shm.c b/ipc/shm.c > > > > index f000696..584d02e 100644 > > > > --- a/ipc/shm.c > > > > +++ b/ipc/shm.c > > > > @@ -480,15 +480,13 @@ static const struct vm_operations_struct shm_= vm_ops =3D { > > > > static int newseg(struct ipc_namespace *ns, struct ipc_params *par= ams) > > > > { > > > > key_t key =3D params->key; > > > > - int shmflg =3D params->flg; > > > > + int id, error, shmflg =3D params->flg; > > >=20 > > > It's largely a matter of taste (and I may be in a minority), and I kn= ow > > > there's certainly precedent in the kernel code, but I don't much like= the=20 > > > style of mixing variable declarations that have initializers, with ot= her > > > unrelated declarations (e.g., variables without initializers). What i= s=20 > > > the gain? One less line of text? That's (IMO) more than offset by the= =20 > > > small loss of readability. > >=20 > > Yes, it's taste. And yes, your in the minority, at least in many core > > kernel components and ipc. >=20 > I'm with Michael. >=20 > - Putting multiple definitions on the same line (whether or not they > are initialized there) makes it impossible to add little comments > documenting them. And we need more little comments documenting > locals. >=20 > - Having multiple definitions on the same line is maddening when the > time comes to resolve patch conflicts. And it increases the > likelihood of conflicts in the first place. >=20 > - It makes it much harder to *find* a definition. And it changes a line that has nothing to do with the patch. Sometimes the minority are right :-) --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au --Signature=_Thu__24_Apr_2014_08_35_15_+1000_wcig3Jp=HffsP76. Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCAAGBQJTWEApAAoJEMDTa8Ir7ZwVh5MP/AjyWRpF1vz5tM8Xy0uStunV +sWsjHOtwRV3FoSoVtFMFhrUVT3wGE4eBy8VIIdSPyk+sfUQ3JRRUCl49Sdy29A8 S2PMPZpqCFaKjNs0P/K+0lFIoq/GHROwFQsgyZtCmEpLGHP4Yc3mZGMwugbosy7I fpdJcYBG63GbHrkadTp7OnL5tKb604isrkGr1tDw9VYiOovlq/u3huXX8QAX/zqB Z65QBQy8R/CzAVD6I6VfVCXWwZ54obPbF3sjmq0IH7cjrY/wi9FB+LIDBPckyHR1 0ca0hDmSn0MB+OWAPeJJgrq7p0v3MjxQdzAcfiRznR/GKBlP1t7cYEiqDJl+DhaB D876joQXDoUqkxclT42LbR0vyCUy6SRMNPvXWZz/XrS6JA9Gssi2cgDgCu1NbvP5 p1MPZPXO4Tnk4iqFezp09U7QAY0gUat742b9dv8jyKozupYkEzpkduZfTei6S5kJ PZn0ykE32RAWNo2Js16thsfyYHXFEqjpv70l/MIfnjJ5BEidxYOz0GXmc/vDy/iq ixFXmTZhWeC+uPoudUf7fBzPLFcxs1M1HBxPhwFZw//A3Kq54Y5Ls+etPJ922s3j ftCgIEGgac/CiUbVLRogIYCfs2rzs29EvFZEyy/TPm627onH/yeAOcnuOrT/ClHG nXbrJfzMpgXzC5/plvbd =18lG -----END PGP SIGNATURE----- --Signature=_Thu__24_Apr_2014_08_35_15_+1000_wcig3Jp=HffsP76.-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by kanga.kvack.org (Postfix) with ESMTP id B067B6B0035 for ; Thu, 24 Apr 2014 01:38:32 -0400 (EDT) Received: by mail-ee0-f41.google.com with SMTP id t10so1409474eei.28 for ; Wed, 23 Apr 2014 22:38:31 -0700 (PDT) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [2a00:1450:4013:c00::22c]) by mx.google.com with ESMTPS id d5si6605107eei.268.2014.04.23.22.38.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Apr 2014 22:38:30 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id e49so1369951eek.17 for ; Wed, 23 Apr 2014 22:38:30 -0700 (PDT) Message-ID: <53589E8E.1040000@gmail.com> Date: Thu, 24 Apr 2014 07:18:06 +0200 From: "Michael Kerrisk (man-pages)" MIME-Version: 1.0 Subject: Re: [PATCH 5/4] ipc,shm: minor cleanups References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> <53574AA5.1060205@gmail.com> <1398230745.27667.2.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1398230745.27667.2.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso Cc: mtk.manpages@gmail.com, Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org On 04/23/2014 07:25 AM, Davidlohr Bueso wrote: > On Wed, 2014-04-23 at 07:07 +0200, Michael Kerrisk (man-pages) wrote: >> On 04/23/2014 04:53 AM, Davidlohr Bueso wrote: >>> - Breakup long function names/args. >>> - Cleaup variable declaration. >>> - s/current->mm/mm >>> >>> Signed-off-by: Davidlohr Bueso >>> --- >>> ipc/shm.c | 40 +++++++++++++++++----------------------- >>> 1 file changed, 17 insertions(+), 23 deletions(-) >>> >>> diff --git a/ipc/shm.c b/ipc/shm.c >>> index f000696..584d02e 100644 >>> --- a/ipc/shm.c >>> +++ b/ipc/shm.c >>> @@ -480,15 +480,13 @@ static const struct vm_operations_struct shm_vm_ops = { >>> static int newseg(struct ipc_namespace *ns, struct ipc_params *params) >>> { >>> key_t key = params->key; >>> - int shmflg = params->flg; >>> + int id, error, shmflg = params->flg; >> >> It's largely a matter of taste (and I may be in a minority), and I know >> there's certainly precedent in the kernel code, but I don't much like the >> style of mixing variable declarations that have initializers, with other >> unrelated declarations (e.g., variables without initializers). What is >> the gain? One less line of text? That's (IMO) more than offset by the >> small loss of readability. > > Yes, it's taste. And yes, your in the minority, at least in many core > kernel components and ipc. Davidlohr, So, noting that the minority is less small than we thought, I'll just add this: I'd have appreciated it if your reply had been less dismissive, and you'd actually responded to my concrete point about loss of readability. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by kanga.kvack.org (Postfix) with ESMTP id 630EB6B0036 for ; Thu, 24 Apr 2014 13:21:42 -0400 (EDT) Received: by mail-oa0-f53.google.com with SMTP id j17so2964861oag.40 for ; Thu, 24 Apr 2014 10:21:42 -0700 (PDT) Received: from g4t3427.houston.hp.com (g4t3427.houston.hp.com. [15.201.208.55]) by mx.google.com with ESMTPS id sm4si4034813obb.130.2014.04.24.10.21.41 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 24 Apr 2014 10:21:41 -0700 (PDT) Message-ID: <1398360099.2744.8.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 5/4] ipc,shm: minor cleanups From: Davidlohr Bueso Date: Thu, 24 Apr 2014 10:21:39 -0700 In-Reply-To: <53589E8E.1040000@gmail.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> <53574AA5.1060205@gmail.com> <1398230745.27667.2.camel@buesod1.americas.hpqcorp.net> <53589E8E.1040000@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: "Michael Kerrisk (man-pages)" Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org On Thu, 2014-04-24 at 07:18 +0200, Michael Kerrisk (man-pages) wrote: > On 04/23/2014 07:25 AM, Davidlohr Bueso wrote: > > On Wed, 2014-04-23 at 07:07 +0200, Michael Kerrisk (man-pages) wrote: > >> On 04/23/2014 04:53 AM, Davidlohr Bueso wrote: > >>> - Breakup long function names/args. > >>> - Cleaup variable declaration. > >>> - s/current->mm/mm > >>> > >>> Signed-off-by: Davidlohr Bueso > >>> --- > >>> ipc/shm.c | 40 +++++++++++++++++----------------------- > >>> 1 file changed, 17 insertions(+), 23 deletions(-) > >>> > >>> diff --git a/ipc/shm.c b/ipc/shm.c > >>> index f000696..584d02e 100644 > >>> --- a/ipc/shm.c > >>> +++ b/ipc/shm.c > >>> @@ -480,15 +480,13 @@ static const struct vm_operations_struct shm_vm_ops = { > >>> static int newseg(struct ipc_namespace *ns, struct ipc_params *params) > >>> { > >>> key_t key = params->key; > >>> - int shmflg = params->flg; > >>> + int id, error, shmflg = params->flg; > >> > >> It's largely a matter of taste (and I may be in a minority), and I know > >> there's certainly precedent in the kernel code, but I don't much like the > >> style of mixing variable declarations that have initializers, with other > >> unrelated declarations (e.g., variables without initializers). What is > >> the gain? One less line of text? That's (IMO) more than offset by the > >> small loss of readability. > > > > Yes, it's taste. And yes, your in the minority, at least in many core > > kernel components and ipc. > > Davidlohr, > > So, noting that the minority is less small than we thought, I'll just > add this: I'd have appreciated it if your reply had been less > dismissive, and you'd actually responded to my concrete point about > loss of readability. Apologies, I didn't mean to sound dismissive. It's just that I don't like arguing over this kind of things. The idea of the cleanups wasn't "lets remove LoC", but more "lets make the style suck less" -- and believe me, ipc code is pretty darn ugly wrt. Over the last few months we've improved it some, but still so much horror. The changes I make are aligned with the general coding style we have in the rest of the kernel, but yes, ultimately it comes down to taste. Anyway, I am in favor of single line declarations with initializers which are *meaningful*. The variables I moved around are not. Thanks, Davidlohr -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by kanga.kvack.org (Postfix) with ESMTP id C5BE66B0037 for ; Fri, 2 May 2014 09:16:59 -0400 (EDT) Received: by mail-qa0-f52.google.com with SMTP id cm18so3147869qab.25 for ; Fri, 02 May 2014 06:16:59 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [2607:f8b0:400d:c00::22e]) by mx.google.com with ESMTPS id j6si14022329qan.32.2014.05.02.06.16.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 May 2014 06:16:59 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id w8so4195203qac.5 for ; Fri, 02 May 2014 06:16:59 -0700 (PDT) MIME-Version: 1.0 Reply-To: mtk.manpages@gmail.com In-Reply-To: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> From: "Michael Kerrisk (man-pages)" Date: Fri, 2 May 2014 15:16:39 +0200 Message-ID: Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Manfred Spraul Cc: Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" Hi Manfred, On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul wrote: > Hi all, > > the increase of SHMMAX/SHMALL is now a 4 patch series. > I don't have ideas how to improve it further. On the assumption that your patches are heading to mainline, could you send me a man-pages patch for the changes? Thanks, Michael > The change itself is trivial, the only problem are interger overflows. > The overflows are not new, but if we make huge values the default, > then the code should be free from overflows. > > SHMMAX: > > - shmmem_file_setup places a hard limit on the segment size: > MAX_LFS_FILESIZE. > > On 32-bit, the limit is > 1 TB, i.e. 4 GB-1 byte segments are > possible. Rounded up to full pages the actual allocated size > is 0. --> must be fixed, patch 3 > > - shmat: > - find_vma_intersection does not handle overflows properly. > --> must be fixed, patch 1 > > - the rest is fine, do_mmap_pgoff limits mappings to TASK_SIZE > and checks for overflows (i.e.: map 2 GB, starting from > addr=2.5GB fails). > > SHMALL: > - after creating 8192 segments size (1L<<63)-1, shm_tot overflows and > returns 0. --> must be fixed, patch 2. > > User space: > - Obviuosly, there could be overflows in user space. There is nothing > we can do, only use values smaller than ULONG_MAX. > I ended with "ULONG_MAX - 1L<<24": > > - TASK_SIZE cannot be used because it is the size of the current > task. Could be 4G if it's a 32-bit task on a 64-bit kernel. > > - The maximum size is not standardized across archs: > I found TASK_MAX_SIZE, TASK_SIZE_MAX and TASK_SIZE_64. > > - Just in case some arch revives a 4G/4G split, nearly > ULONG_MAX is a valid segment size. > > - Using "0" as a magic value for infinity is even worse, because > right now 0 means 0, i.e. fail all allocations. > > Andrew: Could you add it into -akpm and move it towards linux-next? > > -- > Manfred -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by kanga.kvack.org (Postfix) with ESMTP id 508CB6B0035 for ; Tue, 6 May 2014 16:06:51 -0400 (EDT) Received: by mail-pd0-f180.google.com with SMTP id y10so3211470pdj.25 for ; Tue, 06 May 2014 13:06:50 -0700 (PDT) Received: from g2t2352.austin.hp.com (g2t2352.austin.hp.com. [15.217.128.51]) by mx.google.com with ESMTPS id iv2si614794pbd.426.2014.05.06.13.06.49 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 06 May 2014 13:06:50 -0700 (PDT) Message-ID: <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL From: Davidlohr Bueso Date: Tue, 06 May 2014 13:06:40 -0700 In-Reply-To: References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: mtk.manpages@gmail.com Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" On Fri, 2014-05-02 at 15:16 +0200, Michael Kerrisk (man-pages) wrote: > Hi Manfred, > > On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul > wrote: > > Hi all, > > > > the increase of SHMMAX/SHMALL is now a 4 patch series. > > I don't have ideas how to improve it further. > > On the assumption that your patches are heading to mainline, could you > send me a man-pages patch for the changes? Btw, I think that the code could still use some love wrt documentation. Andrew, please consider this for -next if folks agree. Thanks. 8<---------------------------------------------------------- From: Davidlohr Bueso Subject: [PATCH] ipc,shm: document new limits in the uapi header This is useful in the future and allows users to better understand the reasoning behind the changes. Also use UL as we're dealing with it anyways. Signed-off-by: Davidlohr Bueso --- include/uapi/linux/shm.h | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h index 74e786d..e37fb08 100644 --- a/include/uapi/linux/shm.h +++ b/include/uapi/linux/shm.h @@ -8,17 +8,19 @@ #endif /* - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can - * be modified by sysctl. + * SHMMNI, SHMMAX and SHMALL are the default upper limits which can be + * modified by sysctl. Both SHMMAX and SHMALL have their default values + * to the maximum limit which is as large as it can be without helping + * userspace overflow the values. There is really nothing the kernel + * can do to avoid this any variables. It is therefore not advised to + * make them any larger. This is suitable for both 32 and 64-bit systems. */ - #define SHMMIN 1 /* min shared seg size (bytes) */ #define SHMMNI 4096 /* max num of segs system wide */ -#define SHMMAX (ULONG_MAX - (1L<<24)) /* max shared seg size (bytes) */ -#define SHMALL (ULONG_MAX - (1L<<24)) /* max shm system wide (pages) */ +#define SHMMAX (ULONG_MAX - (1UL << 24)) /* max shared seg size (bytes) */ +#define SHMALL (ULONG_MAX - (1UL << 24)) /* max shm system wide (pages) */ #define SHMSEG SHMMNI /* max shared segs per process */ - /* Obsolete, used only for backwards compatibility and libc5 compiles */ struct shmid_ds { struct ipc_perm shm_perm; /* operation perms */ -- 1.8.1.4 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) by kanga.kvack.org (Postfix) with ESMTP id A9E806B0035 for ; Tue, 6 May 2014 16:40:44 -0400 (EDT) Received: by mail-qg0-f44.google.com with SMTP id i50so33368qgf.31 for ; Tue, 06 May 2014 13:40:44 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [2607:f8b0:400d:c04::236]) by mx.google.com with ESMTPS id g10si3416741qge.17.2014.05.06.13.40.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 May 2014 13:40:44 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id q108so33130qgd.27 for ; Tue, 06 May 2014 13:40:44 -0700 (PDT) MIME-Version: 1.0 Reply-To: mtk.manpages@gmail.com In-Reply-To: <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> From: "Michael Kerrisk (man-pages)" Date: Tue, 6 May 2014 22:40:23 +0200 Message-ID: Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" Hi Davidlohr, On Tue, May 6, 2014 at 10:06 PM, Davidlohr Bueso wrote: > On Fri, 2014-05-02 at 15:16 +0200, Michael Kerrisk (man-pages) wrote: >> Hi Manfred, >> >> On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul >> wrote: >> > Hi all, >> > >> > the increase of SHMMAX/SHMALL is now a 4 patch series. >> > I don't have ideas how to improve it further. >> >> On the assumption that your patches are heading to mainline, could you >> send me a man-pages patch for the changes? > > Btw, I think that the code could still use some love wrt documentation. (Agreed.) > Andrew, please consider this for -next if folks agree. Thanks. > > 8<---------------------------------------------------------- > > From: Davidlohr Bueso > Subject: [PATCH] ipc,shm: document new limits in the uapi header > > This is useful in the future and allows users to > better understand the reasoning behind the changes. > > Also use UL as we're dealing with it anyways. > > Signed-off-by: Davidlohr Bueso > --- > include/uapi/linux/shm.h | 14 ++++++++------ > 1 file changed, 8 insertions(+), 6 deletions(-) > > diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h > index 74e786d..e37fb08 100644 > --- a/include/uapi/linux/shm.h > +++ b/include/uapi/linux/shm.h > @@ -8,17 +8,19 @@ > #endif > > /* > - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can Something is wrong in the line above (missing word(s)?) ("are upper limits are defaults") > - * be modified by sysctl. > + * SHMMNI, SHMMAX and SHMALL are the default upper limits which can be > + * modified by sysctl. Both SHMMAX and SHMALL have their default values > + * to the maximum limit which is as large as it can be without helping > + * userspace overflow the values. There is really nothing the kernel > + * can do to avoid this any variables. It is therefore not advised to Something is missing in that last line. > + * make them any larger. This is suitable for both 32 and 64-bit systems. "This" is not so clear. I suggest replacing with an actual noun. > */ > - > #define SHMMIN 1 /* min shared seg size (bytes) */ > #define SHMMNI 4096 /* max num of segs system wide */ > -#define SHMMAX (ULONG_MAX - (1L<<24)) /* max shared seg size (bytes) */ > -#define SHMALL (ULONG_MAX - (1L<<24)) /* max shm system wide (pages) */ > +#define SHMMAX (ULONG_MAX - (1UL << 24)) /* max shared seg size (bytes) */ > +#define SHMALL (ULONG_MAX - (1UL << 24)) /* max shm system wide (pages) */ > #define SHMSEG SHMMNI /* max shared segs per process */ > > - > /* Obsolete, used only for backwards compatibility and libc5 compiles */ > struct shmid_ds { > struct ipc_perm shm_perm; /* operation perms */ Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yh0-f47.google.com (mail-yh0-f47.google.com [209.85.213.47]) by kanga.kvack.org (Postfix) with ESMTP id 3B4FE6B0035 for ; Tue, 6 May 2014 16:43:35 -0400 (EDT) Received: by mail-yh0-f47.google.com with SMTP id a41so29239yho.34 for ; Tue, 06 May 2014 13:43:34 -0700 (PDT) Received: from g5t1627.atlanta.hp.com (g5t1627.atlanta.hp.com. [15.192.137.10]) by mx.google.com with ESMTPS id w3si17011574yhb.168.2014.05.06.13.43.34 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 06 May 2014 13:43:34 -0700 (PDT) Message-ID: <1399409007.13799.24.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL From: Davidlohr Bueso Date: Tue, 06 May 2014 13:43:27 -0700 In-Reply-To: <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: mtk.manpages@gmail.com Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" On Tue, 2014-05-06 at 13:06 -0700, Davidlohr Bueso wrote: > On Fri, 2014-05-02 at 15:16 +0200, Michael Kerrisk (man-pages) wrote: > > Hi Manfred, > > > > On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul > > wrote: > > > Hi all, > > > > > > the increase of SHMMAX/SHMALL is now a 4 patch series. > > > I don't have ideas how to improve it further. > > > > On the assumption that your patches are heading to mainline, could you > > send me a man-pages patch for the changes? > > Btw, I think that the code could still use some love wrt documentation. > Andrew, please consider this for -next if folks agree. Thanks. > > 8<---------------------------------------------------------- > > From: Davidlohr Bueso > Subject: [PATCH] ipc,shm: document new limits in the uapi header > > This is useful in the future and allows users to > better understand the reasoning behind the changes. > > Also use UL as we're dealing with it anyways. > > Signed-off-by: Davidlohr Bueso > --- > include/uapi/linux/shm.h | 14 ++++++++------ > 1 file changed, 8 insertions(+), 6 deletions(-) > > diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h > index 74e786d..e37fb08 100644 > --- a/include/uapi/linux/shm.h > +++ b/include/uapi/linux/shm.h > @@ -8,17 +8,19 @@ > #endif > > /* > - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can > - * be modified by sysctl. > + * SHMMNI, SHMMAX and SHMALL are the default upper limits which can be > + * modified by sysctl. Both SHMMAX and SHMALL have their default values > + * to the maximum limit which is as large as it can be without helping > + * userspace overflow the values. There is really nothing the kernel > + * can do to avoid this any variables. It is therefore not advised to ^^^^^^^^^^ should be 'further', sorry. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by kanga.kvack.org (Postfix) with ESMTP id 56EF76B0035 for ; Tue, 6 May 2014 18:08:06 -0400 (EDT) Received: by mail-pa0-f49.google.com with SMTP id lj1so109244pab.22 for ; Tue, 06 May 2014 15:08:05 -0700 (PDT) Received: from g2t2354.austin.hp.com (g2t2354.austin.hp.com. [15.217.128.53]) by mx.google.com with ESMTPS id lp6si1402974pab.241.2014.05.06.15.08.05 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 06 May 2014 15:08:05 -0700 (PDT) Message-ID: <1399414081.30629.2.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL From: Davidlohr Bueso Date: Tue, 06 May 2014 15:08:01 -0700 In-Reply-To: References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: mtk.manpages@gmail.com Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" On Tue, 2014-05-06 at 22:40 +0200, Michael Kerrisk (man-pages) wrote: > Hi Davidlohr, > > On Tue, May 6, 2014 at 10:06 PM, Davidlohr Bueso wrote: > > On Fri, 2014-05-02 at 15:16 +0200, Michael Kerrisk (man-pages) wrote: > >> Hi Manfred, > >> > >> On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul > >> wrote: > >> > Hi all, > >> > > >> > the increase of SHMMAX/SHMALL is now a 4 patch series. > >> > I don't have ideas how to improve it further. > >> > >> On the assumption that your patches are heading to mainline, could you > >> send me a man-pages patch for the changes? > > > > Btw, I think that the code could still use some love wrt documentation. > > (Agreed.) > > > Andrew, please consider this for -next if folks agree. Thanks. > > > > 8<---------------------------------------------------------- > > > > From: Davidlohr Bueso > > Subject: [PATCH] ipc,shm: document new limits in the uapi header > > > > This is useful in the future and allows users to > > better understand the reasoning behind the changes. > > > > Also use UL as we're dealing with it anyways. > > > > Signed-off-by: Davidlohr Bueso > > --- > > include/uapi/linux/shm.h | 14 ++++++++------ > > 1 file changed, 8 insertions(+), 6 deletions(-) > > > > diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h > > index 74e786d..e37fb08 100644 > > --- a/include/uapi/linux/shm.h > > +++ b/include/uapi/linux/shm.h > > @@ -8,17 +8,19 @@ > > #endif > > > > /* > > - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can > > Something is wrong in the line above (missing word(s)?) ("are upper > limits are defaults") > > > - * be modified by sysctl. > > + * SHMMNI, SHMMAX and SHMALL are the default upper limits which can be > > + * modified by sysctl. Both SHMMAX and SHMALL have their default values > > + * to the maximum limit which is as large as it can be without helping > > + * userspace overflow the values. There is really nothing the kernel > > + * can do to avoid this any variables. It is therefore not advised to > > Something is missing in that last line. > > > + * make them any larger. This is suitable for both 32 and 64-bit systems. > > "This" is not so clear. I suggest replacing with an actual noun. Good point. Perhaps 'These values are ...' would do instead. Thanks, Davidlohr -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by kanga.kvack.org (Postfix) with ESMTP id C76E96B0035 for ; Wed, 7 May 2014 13:49:27 -0400 (EDT) Received: by mail-ee0-f43.google.com with SMTP id d17so988149eek.2 for ; Wed, 07 May 2014 10:49:27 -0700 (PDT) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [2a00:1450:4013:c00::230]) by mx.google.com with ESMTPS id 43si17015836eei.55.2014.05.07.10.49.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 May 2014 10:49:26 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id e49so977200eek.7 for ; Wed, 07 May 2014 10:49:25 -0700 (PDT) Message-ID: <5369C43D.1000206@gmail.com> Date: Wed, 07 May 2014 07:27:25 +0200 From: "Michael Kerrisk (man-pages)" MIME-Version: 1.0 Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> <1399414081.30629.2.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1399414081.30629.2.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso Cc: mtk.manpages@gmail.com, Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" On 05/07/2014 12:08 AM, Davidlohr Bueso wrote: > On Tue, 2014-05-06 at 22:40 +0200, Michael Kerrisk (man-pages) wrote: >> Hi Davidlohr, >> >> On Tue, May 6, 2014 at 10:06 PM, Davidlohr Bueso wrote: >>> On Fri, 2014-05-02 at 15:16 +0200, Michael Kerrisk (man-pages) wrote: >>>> Hi Manfred, >>>> >>>> On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul >>>> wrote: >>>>> Hi all, >>>>> >>>>> the increase of SHMMAX/SHMALL is now a 4 patch series. >>>>> I don't have ideas how to improve it further. >>>> >>>> On the assumption that your patches are heading to mainline, could you >>>> send me a man-pages patch for the changes? >>> >>> Btw, I think that the code could still use some love wrt documentation. >> >> (Agreed.) >> >>> Andrew, please consider this for -next if folks agree. Thanks. >>> >>> 8<---------------------------------------------------------- >>> >>> From: Davidlohr Bueso >>> Subject: [PATCH] ipc,shm: document new limits in the uapi header >>> >>> This is useful in the future and allows users to >>> better understand the reasoning behind the changes. >>> >>> Also use UL as we're dealing with it anyways. >>> >>> Signed-off-by: Davidlohr Bueso >>> --- >>> include/uapi/linux/shm.h | 14 ++++++++------ >>> 1 file changed, 8 insertions(+), 6 deletions(-) >>> >>> diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h >>> index 74e786d..e37fb08 100644 >>> --- a/include/uapi/linux/shm.h >>> +++ b/include/uapi/linux/shm.h >>> @@ -8,17 +8,19 @@ >>> #endif >>> >>> /* >>> - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can >> >> Something is wrong in the line above (missing word(s)?) ("are upper >> limits are defaults") >> >>> - * be modified by sysctl. >>> + * SHMMNI, SHMMAX and SHMALL are the default upper limits which can be >>> + * modified by sysctl. Both SHMMAX and SHMALL have their default values >>> + * to the maximum limit which is as large as it can be without helping >>> + * userspace overflow the values. There is really nothing the kernel >>> + * can do to avoid this any variables. It is therefore not advised to >> >> Something is missing in that last line. >> >>> + * make them any larger. This is suitable for both 32 and 64-bit systems. >> >> "This" is not so clear. I suggest replacing with an actual noun. > > Good point. Perhaps 'These values are ...' would do instead. That's better. Did you miss the first point I raised above? Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by kanga.kvack.org (Postfix) with ESMTP id 049686B0035 for ; Wed, 7 May 2014 14:22:48 -0400 (EDT) Received: by mail-ob0-f173.google.com with SMTP id wm4so1700175obc.18 for ; Wed, 07 May 2014 11:22:48 -0700 (PDT) Received: from g4t3427.houston.hp.com (g4t3427.houston.hp.com. [15.201.208.55]) by mx.google.com with ESMTPS id pu6si11407047oeb.70.2014.05.07.11.22.47 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 07 May 2014 11:22:48 -0700 (PDT) Message-ID: <1399486965.4567.9.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL From: Davidlohr Bueso Date: Wed, 07 May 2014 11:22:45 -0700 In-Reply-To: <5369C43D.1000206@gmail.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> <1399414081.30629.2.camel@buesod1.americas.hpqcorp.net> <5369C43D.1000206@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: "Michael Kerrisk (man-pages)" Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" On Wed, 2014-05-07 at 07:27 +0200, Michael Kerrisk (man-pages) wrote: > On 05/07/2014 12:08 AM, Davidlohr Bueso wrote: > > On Tue, 2014-05-06 at 22:40 +0200, Michael Kerrisk (man-pages) wrote: > >> Hi Davidlohr, > >> > >> On Tue, May 6, 2014 at 10:06 PM, Davidlohr Bueso wrote: > >>> On Fri, 2014-05-02 at 15:16 +0200, Michael Kerrisk (man-pages) wrote: > >>>> Hi Manfred, > >>>> > >>>> On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul > >>>> wrote: > >>>>> Hi all, > >>>>> > >>>>> the increase of SHMMAX/SHMALL is now a 4 patch series. > >>>>> I don't have ideas how to improve it further. > >>>> > >>>> On the assumption that your patches are heading to mainline, could you > >>>> send me a man-pages patch for the changes? > >>> > >>> Btw, I think that the code could still use some love wrt documentation. > >> > >> (Agreed.) > >> > >>> Andrew, please consider this for -next if folks agree. Thanks. > >>> > >>> 8<---------------------------------------------------------- > >>> > >>> From: Davidlohr Bueso > >>> Subject: [PATCH] ipc,shm: document new limits in the uapi header > >>> > >>> This is useful in the future and allows users to > >>> better understand the reasoning behind the changes. > >>> > >>> Also use UL as we're dealing with it anyways. > >>> > >>> Signed-off-by: Davidlohr Bueso > >>> --- > >>> include/uapi/linux/shm.h | 14 ++++++++------ > >>> 1 file changed, 8 insertions(+), 6 deletions(-) > >>> > >>> diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h > >>> index 74e786d..e37fb08 100644 > >>> --- a/include/uapi/linux/shm.h > >>> +++ b/include/uapi/linux/shm.h > >>> @@ -8,17 +8,19 @@ > >>> #endif > >>> > >>> /* > >>> - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can > >> > >> Something is wrong in the line above (missing word(s)?) ("are upper > >> limits are defaults") > >> > >>> - * be modified by sysctl. > >>> + * SHMMNI, SHMMAX and SHMALL are the default upper limits which can be > >>> + * modified by sysctl. Both SHMMAX and SHMALL have their default values > >>> + * to the maximum limit which is as large as it can be without helping > >>> + * userspace overflow the values. There is really nothing the kernel > >>> + * can do to avoid this any variables. It is therefore not advised to > >> > >> Something is missing in that last line. > >> > >>> + * make them any larger. This is suitable for both 32 and 64-bit systems. > >> > >> "This" is not so clear. I suggest replacing with an actual noun. > > > > Good point. Perhaps 'These values are ...' would do instead. > > That's better. > > Did you miss the first point I raised above? No, actually our emails crossed paths and I had sent a suggestion before I replied to yours: https://lkml.org/lkml/2014/5/6/613 Thanks. Davidlohr -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by kanga.kvack.org (Postfix) with ESMTP id 08FA86B0035 for ; Wed, 7 May 2014 15:17:37 -0400 (EDT) Received: by mail-oa0-f45.google.com with SMTP id l6so1805055oag.4 for ; Wed, 07 May 2014 12:17:36 -0700 (PDT) Received: from g4t3425.houston.hp.com (g4t3425.houston.hp.com. [15.201.208.53]) by mx.google.com with ESMTPS id b5si11502459obq.32.2014.05.07.12.17.36 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 07 May 2014 12:17:36 -0700 (PDT) Message-ID: <1399490251.4567.24.camel@buesod1.americas.hpqcorp.net> Subject: [PATCH v2] ipc,shm: document new limits in the uapi header From: Davidlohr Bueso Date: Wed, 07 May 2014 12:17:31 -0700 In-Reply-To: <1399486965.4567.9.camel@buesod1.americas.hpqcorp.net> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> <1399414081.30629.2.camel@buesod1.americas.hpqcorp.net> <5369C43D.1000206@gmail.com> <1399486965.4567.9.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: "Michael Kerrisk (man-pages)" Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" This is useful in the future and allows users to better understand the reasoning behind the changes. Signed-off-by: Davidlohr Bueso --- include/uapi/linux/shm.h | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h index 74e786d..3400b6e 100644 --- a/include/uapi/linux/shm.h +++ b/include/uapi/linux/shm.h @@ -8,17 +8,20 @@ #endif /* - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can - * be modified by sysctl. + * SHMMNI, SHMMAX and SHMALL are the default upper limits which can be + * modified by sysctl. Both SHMMAX and SHMALL have their default values + * to the maximum limit which is as large as it can be without helping + * userspace overflow the values. There is really nothing the kernel + * can do to avoid this any further. It is therefore not advised to + * make them any larger. These limits are suitable for both 32 and + * 64-bit systems. */ - #define SHMMIN 1 /* min shared seg size (bytes) */ #define SHMMNI 4096 /* max num of segs system wide */ -#define SHMMAX (ULONG_MAX - (1L<<24)) /* max shared seg size (bytes) */ -#define SHMALL (ULONG_MAX - (1L<<24)) /* max shm system wide (pages) */ +#define SHMMAX (ULONG_MAX - (1UL << 24)) /* max shared seg size (bytes) */ +#define SHMALL (ULONG_MAX - (1UL << 24)) /* max shm system wide (pages) */ #define SHMSEG SHMMNI /* max shared segs per process */ - /* Obsolete, used only for backwards compatibility and libc5 compiles */ struct shmid_ds { struct ipc_perm shm_perm; /* operation perms */ -- 1.8.1.4 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by kanga.kvack.org (Postfix) with ESMTP id 9D4086B0036 for ; Sun, 11 May 2014 16:46:34 -0400 (EDT) Received: by mail-ob0-f174.google.com with SMTP id uz6so7168401obc.5 for ; Sun, 11 May 2014 13:46:34 -0700 (PDT) Received: from g4t3427.houston.hp.com (g4t3427.houston.hp.com. [15.201.208.55]) by mx.google.com with ESMTPS id ea3si9852924obb.81.2014.05.11.13.46.33 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 11 May 2014 13:46:33 -0700 (PDT) Message-ID: <1399841186.8629.6.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH v2] ipc,shm: document new limits in the uapi header From: Davidlohr Bueso Date: Sun, 11 May 2014 13:46:26 -0700 In-Reply-To: References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> <1399414081.30629.2.camel@buesod1.americas.hpqcorp.net> <5369C43D.1000206@gmail.com> <1399486965.4567.9.camel@buesod1.americas.hpqcorp.net> <1399490251.4567.24.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: mtk.manpages@gmail.com Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" On Fri, 2014-05-09 at 10:44 +0200, Michael Kerrisk (man-pages) wrote: > On Wed, May 7, 2014 at 9:17 PM, Davidlohr Bueso wrote: > > This is useful in the future and allows users to > > better understand the reasoning behind the changes. > > > > Signed-off-by: Davidlohr Bueso > > --- > > include/uapi/linux/shm.h | 15 +++++++++------ > > 1 file changed, 9 insertions(+), 6 deletions(-) > > > > diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h > > index 74e786d..3400b6e 100644 > > --- a/include/uapi/linux/shm.h > > +++ b/include/uapi/linux/shm.h > > @@ -8,17 +8,20 @@ > > #endif > > > > /* > > - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can > > - * be modified by sysctl. > > + * SHMMNI, SHMMAX and SHMALL are the default upper limits which can be > > + * modified by sysctl. Both SHMMAX and SHMALL have their default values > > + * to the maximum limit which is as large as it can be without helping > > + * userspace overflow the values. There is really nothing the kernel > > + * can do to avoid this any further. It is therefore not advised to > > + * make them any larger. These limits are suitable for both 32 and > > + * 64-bit systems. > > I somehow find that text still rather impenetrable. What about this: > > SHMMNI, SHMMAX and SHMALL are default upper limits which can be > modified by sysctl. The SHMMAX and SHMALL values have been chosen to > be as large possible without facilitating scenarios where userspace > causes overflows when adjusting the limits via operations of the form > "retrieve current limit; add X; update limit". It is therefore not > advised to make SHMMAX and SHMALL any larger. These limits are > suitable for both 32 and 64-bit systems. I don't really have much preference, imho both read pretty much the same, specially considering this is still code after all. If you guys really prefer updating it, let me know and I'll send a v3. But perhaps your text is a bit more suitable in the svipc manpage? Thanks, Davidlohr -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by kanga.kvack.org (Postfix) with ESMTP id 3250C6B005C for ; Mon, 12 May 2014 21:35:18 -0400 (EDT) Received: by mail-oa0-f51.google.com with SMTP id n16so9270531oag.10 for ; Mon, 12 May 2014 18:35:18 -0700 (PDT) Received: from g4t3426.houston.hp.com (g4t3426.houston.hp.com. [15.201.208.54]) by mx.google.com with ESMTPS id l1si14237095obh.80.2014.05.12.18.35.17 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 12 May 2014 18:35:17 -0700 (PDT) Message-ID: <1399944913.2648.56.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH v2] ipc,shm: document new limits in the uapi header From: Davidlohr Bueso Date: Mon, 12 May 2014 18:35:13 -0700 In-Reply-To: References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> <1399414081.30629.2.camel@buesod1.americas.hpqcorp.net> <5369C43D.1000206@gmail.com> <1399486965.4567.9.camel@buesod1.americas.hpqcorp.net> <1399490251.4567.24.camel@buesod1.americas.hpqcorp.net> <1399841186.8629.6.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: mtk.manpages@gmail.com Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" On Mon, 2014-05-12 at 09:44 +0200, Michael Kerrisk (man-pages) wrote: > Hi Davidlohr, > > On Sun, May 11, 2014 at 10:46 PM, Davidlohr Bueso wrote: > > On Fri, 2014-05-09 at 10:44 +0200, Michael Kerrisk (man-pages) wrote: > >> On Wed, May 7, 2014 at 9:17 PM, Davidlohr Bueso wrote: > >> > This is useful in the future and allows users to > >> > better understand the reasoning behind the changes. > >> > > >> > Signed-off-by: Davidlohr Bueso > >> > --- > >> > include/uapi/linux/shm.h | 15 +++++++++------ > >> > 1 file changed, 9 insertions(+), 6 deletions(-) > >> > > >> > diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h > >> > index 74e786d..3400b6e 100644 > >> > --- a/include/uapi/linux/shm.h > >> > +++ b/include/uapi/linux/shm.h > >> > @@ -8,17 +8,20 @@ > >> > #endif > >> > > >> > /* > >> > - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can > >> > - * be modified by sysctl. > >> > + * SHMMNI, SHMMAX and SHMALL are the default upper limits which can be > >> > + * modified by sysctl. Both SHMMAX and SHMALL have their default values > >> > + * to the maximum limit which is as large as it can be without helping > >> > + * userspace overflow the values. There is really nothing the kernel > >> > + * can do to avoid this any further. It is therefore not advised to > >> > + * make them any larger. These limits are suitable for both 32 and > >> > + * 64-bit systems. > >> > >> I somehow find that text still rather impenetrable. What about this: > >> > >> SHMMNI, SHMMAX and SHMALL are default upper limits which can be > >> modified by sysctl. The SHMMAX and SHMALL values have been chosen to > >> be as large possible without facilitating scenarios where userspace > >> causes overflows when adjusting the limits via operations of the form > >> "retrieve current limit; add X; update limit". It is therefore not > >> advised to make SHMMAX and SHMALL any larger. These limits are > >> suitable for both 32 and 64-bit systems. > > > > I don't really have much preference, imho both read pretty much the > > same, specially considering this is still code after all. If you guys > > really prefer updating it, let me know and I'll send a v3. But perhaps > > your text is a bit more suitable in the svipc manpage? > > The problem is that part of your text is still broken grammatically In > particular, the piece "Both SHMMAX and SHMALL have their default > values to the maximum limit" at the very least lacks a word. That's > what prompted me to propose the alternative, rather than just say > "this is wrong"--and I thought that I might as well make a more > thoroughgoing attempt at helping improve the text. > > I agree that text something like this should land in the man page at > some point, but as long as we're going to the trouble to improve the > comments in the code, let's make them as good and helpful as we can. Fair enough, and I trust your grammar corrections over mine ;) Thanks for taking a closer look. I've added your text below. 8<------------------------------------------ From: Davidlohr Bueso Subject: [PATCH v3] ipc,shm: document new limits in the uapi header This is useful in the future and allows users to better understand the reasoning behind the changes. Signed-off-by: Davidlohr Bueso --- include/uapi/linux/shm.h | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h index 74e786d..1fbf24e 100644 --- a/include/uapi/linux/shm.h +++ b/include/uapi/linux/shm.h @@ -8,17 +8,20 @@ #endif /* - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can - * be modified by sysctl. + * SHMMNI, SHMMAX and SHMALL are default upper limits which can be + * modified by sysctl. The SHMMAX and SHMALL values have been chosen to + * be as large possible without facilitating scenarios where userspace + * causes overflows when adjusting the limits via operations of the form + * "retrieve current limit; add X; update limit". It is therefore not + * advised to make SHMMAX and SHMALL any larger. These limits are + * suitable for both 32 and 64-bit systems. */ - #define SHMMIN 1 /* min shared seg size (bytes) */ #define SHMMNI 4096 /* max num of segs system wide */ -#define SHMMAX (ULONG_MAX - (1L<<24)) /* max shared seg size (bytes) */ -#define SHMALL (ULONG_MAX - (1L<<24)) /* max shm system wide (pages) */ +#define SHMMAX (ULONG_MAX - (1UL << 24)) /* max shared seg size (bytes) */ +#define SHMALL (ULONG_MAX - (1UL << 24)) /* max shm system wide (pages) */ #define SHMSEG SHMMNI /* max shared segs per process */ - /* Obsolete, used only for backwards compatibility and libc5 compiles */ struct shmid_ds { struct ipc_perm shm_perm; /* operation perms */ -- 1.8.1.4 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael Kerrisk (man-pages)" Subject: Re: [PATCH v2] ipc,shm: document new limits in the uapi header Date: Fri, 9 May 2014 10:44:11 +0200 Message-ID: References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> <1399414081.30629.2.camel@buesod1.americas.hpqcorp.net> <5369C43D.1000206@gmail.com> <1399486965.4567.9.camel@buesod1.americas.hpqcorp.net> <1399490251.4567.24.camel@buesod1.americas.hpqcorp.net> Reply-To: mtk.manpages@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <1399490251.4567.24.camel@buesod1.americas.hpqcorp.net> Sender: linux-kernel-owner@vger.kernel.org To: Davidlohr Bueso Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" List-Id: linux-mm.kvack.org On Wed, May 7, 2014 at 9:17 PM, Davidlohr Bueso wrote: > This is useful in the future and allows users to > better understand the reasoning behind the changes. > > Signed-off-by: Davidlohr Bueso > --- > include/uapi/linux/shm.h | 15 +++++++++------ > 1 file changed, 9 insertions(+), 6 deletions(-) > > diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h > index 74e786d..3400b6e 100644 > --- a/include/uapi/linux/shm.h > +++ b/include/uapi/linux/shm.h > @@ -8,17 +8,20 @@ > #endif > > /* > - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can > - * be modified by sysctl. > + * SHMMNI, SHMMAX and SHMALL are the default upper limits which can be > + * modified by sysctl. Both SHMMAX and SHMALL have their default values > + * to the maximum limit which is as large as it can be without helping > + * userspace overflow the values. There is really nothing the kernel > + * can do to avoid this any further. It is therefore not advised to > + * make them any larger. These limits are suitable for both 32 and > + * 64-bit systems. I somehow find that text still rather impenetrable. What about this: SHMMNI, SHMMAX and SHMALL are default upper limits which can be modified by sysctl. The SHMMAX and SHMALL values have been chosen to be as large possible without facilitating scenarios where userspace causes overflows when adjusting the limits via operations of the form "retrieve current limit; add X; update limit". It is therefore not advised to make SHMMAX and SHMALL any larger. These limits are suitable for both 32 and 64-bit systems. ? Cheers, Michael > */ > - > #define SHMMIN 1 /* min shared seg size (bytes) */ > #define SHMMNI 4096 /* max num of segs system wide */ > -#define SHMMAX (ULONG_MAX - (1L<<24)) /* max shared seg size (bytes) */ > -#define SHMALL (ULONG_MAX - (1L<<24)) /* max shm system wide (pages) */ > +#define SHMMAX (ULONG_MAX - (1UL << 24)) /* max shared seg size (bytes) */ > +#define SHMALL (ULONG_MAX - (1UL << 24)) /* max shm system wide (pages) */ > #define SHMSEG SHMMNI /* max shared segs per process */ > > - > /* Obsolete, used only for backwards compatibility and libc5 compiles */ > struct shmid_ds { > struct ipc_perm shm_perm; /* operation perms */ > -- > 1.8.1.4 > > > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael Kerrisk (man-pages)" Subject: Re: [PATCH v2] ipc,shm: document new limits in the uapi header Date: Mon, 12 May 2014 09:44:13 +0200 Message-ID: References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> <1399414081.30629.2.camel@buesod1.americas.hpqcorp.net> <5369C43D.1000206@gmail.com> <1399486965.4567.9.camel@buesod1.americas.hpqcorp.net> <1399490251.4567.24.camel@buesod1.americas.hpqcorp.net> <1399841186.8629.6.camel@buesod1.americas.hpqcorp.net> Reply-To: mtk.manpages@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <1399841186.8629.6.camel@buesod1.americas.hpqcorp.net> Sender: linux-kernel-owner@vger.kernel.org To: Davidlohr Bueso Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" List-Id: linux-mm.kvack.org Hi Davidlohr, On Sun, May 11, 2014 at 10:46 PM, Davidlohr Bueso wrote: > On Fri, 2014-05-09 at 10:44 +0200, Michael Kerrisk (man-pages) wrote: >> On Wed, May 7, 2014 at 9:17 PM, Davidlohr Bueso wrote: >> > This is useful in the future and allows users to >> > better understand the reasoning behind the changes. >> > >> > Signed-off-by: Davidlohr Bueso >> > --- >> > include/uapi/linux/shm.h | 15 +++++++++------ >> > 1 file changed, 9 insertions(+), 6 deletions(-) >> > >> > diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h >> > index 74e786d..3400b6e 100644 >> > --- a/include/uapi/linux/shm.h >> > +++ b/include/uapi/linux/shm.h >> > @@ -8,17 +8,20 @@ >> > #endif >> > >> > /* >> > - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can >> > - * be modified by sysctl. >> > + * SHMMNI, SHMMAX and SHMALL are the default upper limits which can be >> > + * modified by sysctl. Both SHMMAX and SHMALL have their default values >> > + * to the maximum limit which is as large as it can be without helping >> > + * userspace overflow the values. There is really nothing the kernel >> > + * can do to avoid this any further. It is therefore not advised to >> > + * make them any larger. These limits are suitable for both 32 and >> > + * 64-bit systems. >> >> I somehow find that text still rather impenetrable. What about this: >> >> SHMMNI, SHMMAX and SHMALL are default upper limits which can be >> modified by sysctl. The SHMMAX and SHMALL values have been chosen to >> be as large possible without facilitating scenarios where userspace >> causes overflows when adjusting the limits via operations of the form >> "retrieve current limit; add X; update limit". It is therefore not >> advised to make SHMMAX and SHMALL any larger. These limits are >> suitable for both 32 and 64-bit systems. > > I don't really have much preference, imho both read pretty much the > same, specially considering this is still code after all. If you guys > really prefer updating it, let me know and I'll send a v3. But perhaps > your text is a bit more suitable in the svipc manpage? The problem is that part of your text is still broken grammatically In particular, the piece "Both SHMMAX and SHMALL have their default values to the maximum limit" at the very least lacks a word. That's what prompted me to propose the alternative, rather than just say "this is wrong"--and I thought that I might as well make a more thoroughgoing attempt at helping improve the text. I agree that text something like this should land in the man page at some point, but as long as we're going to the trouble to improve the comments in the code, let's make them as good and helpful as we can. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael Kerrisk (man-pages)" Subject: Re: [PATCH v2] ipc,shm: document new limits in the uapi header Date: Tue, 13 May 2014 08:06:21 +0200 Message-ID: References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> <1399414081.30629.2.camel@buesod1.americas.hpqcorp.net> <5369C43D.1000206@gmail.com> <1399486965.4567.9.camel@buesod1.americas.hpqcorp.net> <1399490251.4567.24.camel@buesod1.americas.hpqcorp.net> <1399841186.8629.6.camel@buesod1.americas.hpqcorp.net> <1399944913.2648.56.camel@buesod1.americas.hpqcorp.net> Reply-To: mtk.manpages@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <1399944913.2648.56.camel@buesod1.americas.hpqcorp.net> Sender: linux-kernel-owner@vger.kernel.org To: Davidlohr Bueso Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" List-Id: linux-mm.kvack.org On Tue, May 13, 2014 at 3:35 AM, Davidlohr Bueso wrote: > On Mon, 2014-05-12 at 09:44 +0200, Michael Kerrisk (man-pages) wrote: [...] >> The problem is that part of your text is still broken grammatically In >> particular, the piece "Both SHMMAX and SHMALL have their default >> values to the maximum limit" at the very least lacks a word. That's >> what prompted me to propose the alternative, rather than just say >> "this is wrong"--and I thought that I might as well make a more >> thoroughgoing attempt at helping improve the text. >> >> I agree that text something like this should land in the man page at >> some point, but as long as we're going to the trouble to improve the >> comments in the code, let's make them as good and helpful as we can. > > Fair enough, and I trust your grammar corrections over mine ;) Thanks > for taking a closer look. I've added your text below. Thanks. Acked-by: Michael Kerrisk Cheers,' Michael > 8<------------------------------------------ > From: Davidlohr Bueso > Subject: [PATCH v3] ipc,shm: document new limits in the uapi header > > This is useful in the future and allows users to > better understand the reasoning behind the changes. > > Signed-off-by: Davidlohr Bueso > --- > include/uapi/linux/shm.h | 15 +++++++++------ > 1 file changed, 9 insertions(+), 6 deletions(-) > > diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h > index 74e786d..1fbf24e 100644 > --- a/include/uapi/linux/shm.h > +++ b/include/uapi/linux/shm.h > @@ -8,17 +8,20 @@ > #endif > > /* > - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can > - * be modified by sysctl. > + * SHMMNI, SHMMAX and SHMALL are default upper limits which can be > + * modified by sysctl. The SHMMAX and SHMALL values have been chosen to > + * be as large possible without facilitating scenarios where userspace > + * causes overflows when adjusting the limits via operations of the form > + * "retrieve current limit; add X; update limit". It is therefore not > + * advised to make SHMMAX and SHMALL any larger. These limits are > + * suitable for both 32 and 64-bit systems. > */ > - > #define SHMMIN 1 /* min shared seg size (bytes) */ > #define SHMMNI 4096 /* max num of segs system wide */ > -#define SHMMAX (ULONG_MAX - (1L<<24)) /* max shared seg size (bytes) */ > -#define SHMALL (ULONG_MAX - (1L<<24)) /* max shm system wide (pages) */ > +#define SHMMAX (ULONG_MAX - (1UL << 24)) /* max shared seg size (bytes) */ > +#define SHMALL (ULONG_MAX - (1UL << 24)) /* max shm system wide (pages) */ > #define SHMSEG SHMMNI /* max shared segs per process */ > > - > /* Obsolete, used only for backwards compatibility and libc5 compiles */ > struct shmid_ds { > struct ipc_perm shm_perm; /* operation perms */ > -- > 1.8.1.4 > > > > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by kanga.kvack.org (Postfix) with ESMTP id EBB376B0031 for ; Tue, 3 Jun 2014 15:26:05 -0400 (EDT) Received: by mail-ob0-f176.google.com with SMTP id wo20so6520156obc.7 for ; Tue, 03 Jun 2014 12:26:05 -0700 (PDT) Received: from g4t3426.houston.hp.com (g4t3426.houston.hp.com. [15.201.208.54]) by mx.google.com with ESMTPS id h1si276106obf.69.2014.06.03.12.26.05 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Jun 2014 12:26:05 -0700 (PDT) Message-ID: <1401823560.4911.2.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL From: Davidlohr Bueso Date: Tue, 03 Jun 2014 12:26:00 -0700 In-Reply-To: References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: mtk.manpages@gmail.com Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" On Fri, 2014-05-02 at 15:16 +0200, Michael Kerrisk (man-pages) wrote: > Hi Manfred, > > On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul > wrote: > > Hi all, > > > > the increase of SHMMAX/SHMALL is now a 4 patch series. > > I don't have ideas how to improve it further. > > On the assumption that your patches are heading to mainline, could you > send me a man-pages patch for the changes? It seems we're still behind here and the 3.16 merge window is already opened. Please consider this, and again feel free to add/modify as necessary. I think adding a note as below is enough and was hesitant to add a lot of details... Thanks. 8<-------------------------------------------------- From: Davidlohr Bueso Subject: [PATCH] shmget.2: document new limits for shmmax/shmall These limits have been recently enlarged and modifying them is no longer really necessary. Update the manpage. Signed-off-by: Davidlohr Bueso --- man2/shmget.2 | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/man2/shmget.2 b/man2/shmget.2 index f781048..77764ea 100644 --- a/man2/shmget.2 +++ b/man2/shmget.2 @@ -299,6 +299,11 @@ with 8kB page size, it yields 2^20 (1048576). On Linux, this limit can be read and modified via .IR /proc/sys/kernel/shmall . +As of Linux 3.16, the default value for this limit is increased to +.B ULONG_MAX - 2^24 +pages, which is as large as it can be without helping userspace overflow +the values. Modifying this limit is therefore discouraged. This is suitable +for both 32 and 64-bit systems. .TP .B SHMMAX Maximum size in bytes for a shared memory segment. @@ -306,6 +311,12 @@ Since Linux 2.2, the default value of this limit is 0x2000000 (32MB). On Linux, this limit can be read and modified via .IR /proc/sys/kernel/shmmax . +As of Linux 3.16, the default value for this limit is increased from 32Mb +to +.B ULONG_MAX - 2^24 +bytes, which is as large as it can be without helping userspace overflow +the values. Modifying this limit is therefore discouraged. This is suitable +for both 32 and 64-bit systems. .TP .B SHMMIN Minimum size in bytes for a shared memory segment: implementation -- 1.8.1.4 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by kanga.kvack.org (Postfix) with ESMTP id 4BBA16B0035 for ; Tue, 23 Sep 2014 01:24:30 -0400 (EDT) Received: by mail-lb0-f175.google.com with SMTP id w7so2420021lbi.34 for ; Mon, 22 Sep 2014 22:24:29 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [2a00:1450:4010:c04::22b]) by mx.google.com with ESMTPS id rb9si17067530lbb.31.2014.09.22.22.24.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Sep 2014 22:24:28 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id l4so8078287lbv.30 for ; Mon, 22 Sep 2014 22:24:28 -0700 (PDT) Message-ID: <54210407.1000602@gmail.com> Date: Tue, 23 Sep 2014 07:24:23 +0200 From: "Michael Kerrisk (man-pages)" MIME-Version: 1.0 Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1401823560.4911.2.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1401823560.4911.2.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso Cc: mtk.manpages@gmail.com, Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" On 06/03/2014 09:26 PM, Davidlohr Bueso wrote: > On Fri, 2014-05-02 at 15:16 +0200, Michael Kerrisk (man-pages) wrote: >> Hi Manfred, >> >> On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul >> wrote: >>> Hi all, >>> >>> the increase of SHMMAX/SHMALL is now a 4 patch series. >>> I don't have ideas how to improve it further. >> >> On the assumption that your patches are heading to mainline, could you >> send me a man-pages patch for the changes? > > It seems we're still behind here and the 3.16 merge window is already > opened. Please consider this, and again feel free to add/modify as > necessary. I think adding a note as below is enough and was hesitant to > add a lot of details... Thanks. > > 8<-------------------------------------------------- > From: Davidlohr Bueso > Subject: [PATCH] shmget.2: document new limits for shmmax/shmall > > These limits have been recently enlarged and > modifying them is no longer really necessary. > Update the manpage. > > Signed-off-by: Davidlohr Bueso > --- > man2/shmget.2 | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/man2/shmget.2 b/man2/shmget.2 > index f781048..77764ea 100644 > --- a/man2/shmget.2 > +++ b/man2/shmget.2 > @@ -299,6 +299,11 @@ with 8kB page size, it yields 2^20 (1048576). > > On Linux, this limit can be read and modified via > .IR /proc/sys/kernel/shmall . > +As of Linux 3.16, the default value for this limit is increased to > +.B ULONG_MAX - 2^24 > +pages, which is as large as it can be without helping userspace overflow > +the values. Modifying this limit is therefore discouraged. This is suitable > +for both 32 and 64-bit systems. > .TP > .B SHMMAX > Maximum size in bytes for a shared memory segment. > @@ -306,6 +311,12 @@ Since Linux 2.2, the default value of this limit is 0x2000000 (32MB). > > On Linux, this limit can be read and modified via > .IR /proc/sys/kernel/shmmax . > +As of Linux 3.16, the default value for this limit is increased from 32Mb > +to > +.B ULONG_MAX - 2^24 > +bytes, which is as large as it can be without helping userspace overflow > +the values. Modifying this limit is therefore discouraged. This is suitable > +for both 32 and 64-bit systems. > .TP > .B SHMMIN > Minimum size in bytes for a shared memory segment: implementation David, I applied various pieces from your patch on top of material that I already had, so that now we have the text below describing these limits. Comments/suggestions/improvements from all welcome. Cheers, Michael SHMALL System-wide limit on the number of pages of shared memory. On Linux, this limit can be read and modified via /proc/sys/kernel/shmall. Since Linux 3.16, the default value for this limit is: ULONG_MAX - 2^24 The effect of this value (which is suitable for both 32-bit and 64-bit systems) is to impose no limitation on allocations. This value, rather than ULONG_MAX, was choa?? sen as the default to prevent some cases where historical applications simply raised the existing limit without first checking its current value. Such applications would cause the value to overflow if the limit was set at ULONG_MAX. From Linux 2.4 up to Linux 3.15, the default value for this limit was: SHMMAX / PAGE_SIZE * (SHMMNI / 16) If SHMMAX and SHMMNI were not modified, then multiplying the result of this formula by the page size (to get a value in bytes) yielded a value of 8 GB as the limit on the total memory used by all shared memory segments. SHMMAX Maximum size in bytes for a shared memory segment. On Linux, this limit can be read and modified via /proc/sys/kernel/shmmax. Since Linux 3.16, the default value for this limit is: ULONG_MAX - 2^24 The effect of this value (which is suitable for both 32-bit and 64-bit systems) is to impose no limitation on allocations. See the description of SHMALL for a discusa?? sion of why this default value (rather than ULONG_MAX) is used. From Linux 2.2 up to Linux 3.15, the default value of this limit was 0x2000000 (32MB). Because it is not possible to map just part of a shared memory segment, the amount of virtual memory places another limit on the maximum size of a usable segment: for example, on i386 the largest segments that can be mapped have a size of around 2.8 GB, and on x86_64 the limit is around 127 TB. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by kanga.kvack.org (Postfix) with ESMTP id 3B0D26B0035 for ; Wed, 24 Sep 2014 04:02:18 -0400 (EDT) Received: by mail-pa0-f47.google.com with SMTP id et14so8140929pad.34 for ; Wed, 24 Sep 2014 01:02:17 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (homie.mail.dreamhost.com. [208.97.132.208]) by mx.google.com with ESMTP id zq1si10468477pac.44.2014.09.24.01.02.16 for ; Wed, 24 Sep 2014 01:02:17 -0700 (PDT) Message-ID: <1411545734.30630.4.camel@linux-t7sj.site> Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL From: Davidlohr Bueso Date: Wed, 24 Sep 2014 10:02:14 +0200 In-Reply-To: <54210407.1000602@gmail.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1401823560.4911.2.camel@buesod1.americas.hpqcorp.net> <54210407.1000602@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: "Michael Kerrisk (man-pages)" Cc: Manfred Spraul , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" On Tue, 2014-09-23 at 07:24 +0200, Michael Kerrisk (man-pages) wrote: > David, > > I applied various pieces from your patch on top of material > that I already had, so that now we have the text below describing > these limits. Comments/suggestions/improvements from all welcome. Looks good, thanks! -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754734AbaDSLoA (ORCPT ); Sat, 19 Apr 2014 07:44:00 -0400 Received: from mail-ee0-f50.google.com ([74.125.83.50]:42252 "EHLO mail-ee0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751638AbaDSLn5 (ORCPT ); Sat, 19 Apr 2014 07:43:57 -0400 From: Manfred Spraul To: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky Cc: LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org, Manfred Spraul Subject: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL Date: Sat, 19 Apr 2014 13:43:37 +0200 Message-Id: <1397907821-29319-1-git-send-email-manfred@colorfullife.com> X-Mailer: git-send-email 1.9.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, the increase of SHMMAX/SHMALL is now a 4 patch series, and still not ready for merging (see at the end, TASK_SIZE and s390). If we increase the default limits for SHMMAX and SHMALL, integer overflows could happen: SHMMAX: - shmmem_file_setup places a hard limit on the segment size: MAX_LFS_FILESIZE. on 32-bit, the limit is > 1 TB. --> 32-bit: 4 GB-1 segments are possible. Rounded up to full pages the actual allocated size is 0. --> patch 3 on 64-bit, this is 0x7fff ffff ffff ffff --> no chance for an overflow. - shmat: - find_vma_intersection does not handle overflows properly --> patch 1. - do_mmap_pgoff limits mappings to TASK_SIZE 3 GB on 32-bit (assuming x86) 47 bits on 64-bit (assuming x86) - do_mmap_pgoff checks for overflows: map 2 GB, starting from addr=2.5GB fails. SHMALL: - after creating 8192 segments size (1L<<63)-1, shm_tot overflows and returns 0. --> patch 2. And finally: Patch 4, increase the limits to ULONG_MAX Open points: - Better ideas to handle uapi: Is it worth the effort to get access to TASK_SIZE? I would say no. - Better ideas with regards to SHMALL? The values are probably large enough, but still arbitrary. - The TASK_SIZE definition for e.g. S390 differs: It's not a constant, instead it is the current task size for current. And it seems that the task size can change based on (virtual) memory pressure (s390_mmap_check()). For new namespaces, this might have interesting effects, i.e. this must be fixed. -- Manfred From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751592AbaDUObp (ORCPT ); Mon, 21 Apr 2014 10:31:45 -0400 Received: from mail-ee0-f43.google.com ([74.125.83.43]:33115 "EHLO mail-ee0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751073AbaDUObk (ORCPT ); Mon, 21 Apr 2014 10:31:40 -0400 From: Manfred Spraul To: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky Cc: LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org, Manfred Spraul Subject: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL Date: Mon, 21 Apr 2014 16:26:33 +0200 Message-Id: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> X-Mailer: git-send-email 1.9.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, the increase of SHMMAX/SHMALL is now a 4 patch series. I don't have ideas how to improve it further. The change itself is trivial, the only problem are interger overflows. The overflows are not new, but if we make huge values the default, then the code should be free from overflows. SHMMAX: - shmmem_file_setup places a hard limit on the segment size: MAX_LFS_FILESIZE. On 32-bit, the limit is > 1 TB, i.e. 4 GB-1 byte segments are possible. Rounded up to full pages the actual allocated size is 0. --> must be fixed, patch 3 - shmat: - find_vma_intersection does not handle overflows properly. --> must be fixed, patch 1 - the rest is fine, do_mmap_pgoff limits mappings to TASK_SIZE and checks for overflows (i.e.: map 2 GB, starting from addr=2.5GB fails). SHMALL: - after creating 8192 segments size (1L<<63)-1, shm_tot overflows and returns 0. --> must be fixed, patch 2. User space: - Obviuosly, there could be overflows in user space. There is nothing we can do, only use values smaller than ULONG_MAX. I ended with "ULONG_MAX - 1L<<24": - TASK_SIZE cannot be used because it is the size of the current task. Could be 4G if it's a 32-bit task on a 64-bit kernel. - The maximum size is not standardized across archs: I found TASK_MAX_SIZE, TASK_SIZE_MAX and TASK_SIZE_64. - Just in case some arch revives a 4G/4G split, nearly ULONG_MAX is a valid segment size. - Using "0" as a magic value for infinity is even worse, because right now 0 means 0, i.e. fail all allocations. Andrew: Could you add it into -akpm and move it towards linux-next? -- Manfred From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751723AbaDUObr (ORCPT ); Mon, 21 Apr 2014 10:31:47 -0400 Received: from mail-ee0-f42.google.com ([74.125.83.42]:34218 "EHLO mail-ee0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751617AbaDUObq (ORCPT ); Mon, 21 Apr 2014 10:31:46 -0400 From: Manfred Spraul To: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky Cc: LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org, Manfred Spraul Subject: [PATCH 2/4] ipc/shm.c: check for overflows of shm_tot Date: Mon, 21 Apr 2014 16:26:35 +0200 Message-Id: <1398090397-2397-3-git-send-email-manfred@colorfullife.com> X-Mailer: git-send-email 1.9.0 In-Reply-To: <1398090397-2397-2-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org shm_tot counts the total number of pages used by shm segments. If SHMALL is ULONG_MAX (or nearly ULONG_MAX), then the number can overflow. Subsequent calls to shmctl(,SHM_INFO,) would return wrong values for shm_tot. The patch adds a detection for overflows. Signed-off-by: Manfred Spraul --- ipc/shm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ipc/shm.c b/ipc/shm.c index 382e2fb..2dfa3d6 100644 --- a/ipc/shm.c +++ b/ipc/shm.c @@ -493,7 +493,8 @@ static int newseg(struct ipc_namespace *ns, struct ipc_params *params) if (size < SHMMIN || size > ns->shm_ctlmax) return -EINVAL; - if (ns->shm_tot + numpages > ns->shm_ctlall) + if (ns->shm_tot + numpages < ns->shm_tot || + ns->shm_tot + numpages > ns->shm_ctlall) return -ENOSPC; shp = ipc_rcu_alloc(sizeof(*shp)); -- 1.9.0 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752235AbaDUOb7 (ORCPT ); Mon, 21 Apr 2014 10:31:59 -0400 Received: from mail-ee0-f41.google.com ([74.125.83.41]:40541 "EHLO mail-ee0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751795AbaDUObv (ORCPT ); Mon, 21 Apr 2014 10:31:51 -0400 From: Manfred Spraul To: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky Cc: LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org, Manfred Spraul Subject: [PATCH 4/4] ipc/shm.c: Increase the defaults for SHMALL, SHMMAX. Date: Mon, 21 Apr 2014 16:26:37 +0200 Message-Id: <1398090397-2397-5-git-send-email-manfred@colorfullife.com> X-Mailer: git-send-email 1.9.0 In-Reply-To: <1398090397-2397-4-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> <1398090397-2397-4-git-send-email-manfred@colorfullife.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org System V shared memory a) can be abused to trigger out-of-memory conditions and the standard measures against out-of-memory do not work: - it is not possible to use setrlimit to limit the size of shm segments. - segments can exist without association with any processes, thus the oom-killer is unable to free that memory. b) is typically used for shared information - today often multiple GB. (e.g. database shared buffers) The current default is a maximum segment size of 32 MB and a maximum total size of 8 GB. This is often too much for a) and not enough for b), which means that lots of users must change the defaults. This patch increases the default limits (nearly) to the maximum, which is perfect for case b). The defaults are used after boot and as the initial value for each new namespace. Admins/distros that need a protection against a) should reduce the limits and/or enable shm_rmid_forced. Further notes: - The patch only changes default, overrides behave as before: # sysctl kernel.shmall=33554432 would recreate the previous limit for SHMMAX (for the current namespace). - Disabling sysv shm allocation is possible with: # sysctl kernel.shmall=0 (not a new feature, also per-namespace) - The limits are intentionally set to a value slightly less than ULONG_MAX, to avoid triggering overflows in user space apps. [not unreasonable, see http://marc.info/?l=linux-mm&m=139638334330127] Signed-off-by: Manfred Spraul Reported-by: Davidlohr Bueso Cc: mtk.manpages@gmail.com --- include/linux/shm.h | 3 +-- include/uapi/linux/shm.h | 8 +++----- 2 files changed, 4 insertions(+), 7 deletions(-) diff --git a/include/linux/shm.h b/include/linux/shm.h index 1e2cd2e..57d7770 100644 --- a/include/linux/shm.h +++ b/include/linux/shm.h @@ -3,9 +3,8 @@ #include #include - -#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) */ #include + struct shmid_kernel /* private to the kernel */ { struct kern_ipc_perm shm_perm; diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h index 78b6941..74e786d 100644 --- a/include/uapi/linux/shm.h +++ b/include/uapi/linux/shm.h @@ -9,15 +9,13 @@ /* * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can - * be increased by sysctl + * be modified by sysctl. */ -#define SHMMAX 0x2000000 /* max shared seg size (bytes) */ #define SHMMIN 1 /* min shared seg size (bytes) */ #define SHMMNI 4096 /* max num of segs system wide */ -#ifndef __KERNEL__ -#define SHMALL (SHMMAX/getpagesize()*(SHMMNI/16)) -#endif +#define SHMMAX (ULONG_MAX - (1L<<24)) /* max shared seg size (bytes) */ +#define SHMALL (ULONG_MAX - (1L<<24)) /* max shm system wide (pages) */ #define SHMSEG SHMMNI /* max shared segs per process */ -- 1.9.0 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752093AbaDUOby (ORCPT ); Mon, 21 Apr 2014 10:31:54 -0400 Received: from mail-ee0-f49.google.com ([74.125.83.49]:63634 "EHLO mail-ee0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751639AbaDUObr (ORCPT ); Mon, 21 Apr 2014 10:31:47 -0400 From: Manfred Spraul To: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky Cc: LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org, Manfred Spraul Subject: [PATCH 3/4] ipc/shm.c: check for integer overflow during shmget. Date: Mon, 21 Apr 2014 16:26:36 +0200 Message-Id: <1398090397-2397-4-git-send-email-manfred@colorfullife.com> X-Mailer: git-send-email 1.9.0 In-Reply-To: <1398090397-2397-3-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org SHMMAX is the upper limit for the size of a shared memory segment, counted in bytes. The actual allocation is that size, rounded up to the next full page. Add a check that prevents the creation of segments where the rounded up size causes an integer overflow. Signed-off-by: Manfred Spraul --- ipc/shm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ipc/shm.c b/ipc/shm.c index 2dfa3d6..f000696 100644 --- a/ipc/shm.c +++ b/ipc/shm.c @@ -493,6 +493,9 @@ static int newseg(struct ipc_namespace *ns, struct ipc_params *params) if (size < SHMMIN || size > ns->shm_ctlmax) return -EINVAL; + if (numpages << PAGE_SHIFT < size) + return -ENOSPC; + if (ns->shm_tot + numpages < ns->shm_tot || ns->shm_tot + numpages > ns->shm_ctlall) return -ENOSPC; -- 1.9.0 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752454AbaDUOct (ORCPT ); Mon, 21 Apr 2014 10:32:49 -0400 Received: from mail-ee0-f54.google.com ([74.125.83.54]:33331 "EHLO mail-ee0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751546AbaDUObn (ORCPT ); Mon, 21 Apr 2014 10:31:43 -0400 From: Manfred Spraul To: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky Cc: LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org, Manfred Spraul Subject: [PATCH 1/4] ipc/shm.c: check for ulong overflows in shmat Date: Mon, 21 Apr 2014 16:26:34 +0200 Message-Id: <1398090397-2397-2-git-send-email-manfred@colorfullife.com> X-Mailer: git-send-email 1.9.0 In-Reply-To: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org find_vma_intersection does not work as intended if addr+size overflows. The patch adds a manual check before the call to find_vma_intersection. Signed-off-by: Manfred Spraul --- ipc/shm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ipc/shm.c b/ipc/shm.c index 7645961..382e2fb 100644 --- a/ipc/shm.c +++ b/ipc/shm.c @@ -1160,6 +1160,9 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr, down_write(¤t->mm->mmap_sem); if (addr && !(shmflg & SHM_REMAP)) { err = -EINVAL; + if (addr + size < addr) + goto invalid; + if (find_vma_intersection(current->mm, addr, addr + size)) goto invalid; /* -- 1.9.0 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753261AbaDURZN (ORCPT ); Mon, 21 Apr 2014 13:25:13 -0400 Received: from g5t1625.atlanta.hp.com ([15.192.137.8]:24317 "EHLO g5t1625.atlanta.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753163AbaDURZK (ORCPT ); Mon, 21 Apr 2014 13:25:10 -0400 Message-ID: <1398101106.2623.6.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL From: Davidlohr Bueso To: Manfred Spraul Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Date: Mon, 21 Apr 2014 10:25:06 -0700 In-Reply-To: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote: > Hi all, > > the increase of SHMMAX/SHMALL is now a 4 patch series. > I don't have ideas how to improve it further. Manfred, is there any difference between this set and the one you sent a couple of days ago? > > The change itself is trivial, the only problem are interger overflows. > The overflows are not new, but if we make huge values the default, > then the code should be free from overflows. > > SHMMAX: > > - shmmem_file_setup places a hard limit on the segment size: > MAX_LFS_FILESIZE. > > On 32-bit, the limit is > 1 TB, i.e. 4 GB-1 byte segments are > possible. Rounded up to full pages the actual allocated size > is 0. --> must be fixed, patch 3 > > - shmat: > - find_vma_intersection does not handle overflows properly. > --> must be fixed, patch 1 > > - the rest is fine, do_mmap_pgoff limits mappings to TASK_SIZE > and checks for overflows (i.e.: map 2 GB, starting from > addr=2.5GB fails). > > SHMALL: > - after creating 8192 segments size (1L<<63)-1, shm_tot overflows and > returns 0. --> must be fixed, patch 2. > > User space: > - Obviuosly, there could be overflows in user space. There is nothing > we can do, only use values smaller than ULONG_MAX. > I ended with "ULONG_MAX - 1L<<24": > > - TASK_SIZE cannot be used because it is the size of the current > task. Could be 4G if it's a 32-bit task on a 64-bit kernel. > > - The maximum size is not standardized across archs: > I found TASK_MAX_SIZE, TASK_SIZE_MAX and TASK_SIZE_64. > > - Just in case some arch revives a 4G/4G split, nearly > ULONG_MAX is a valid segment size. > > - Using "0" as a magic value for infinity is even worse, because > right now 0 means 0, i.e. fail all allocations. Sorry but I don't quite get this. Using 0 eliminates the need for all these patches, no? I mean overflows have existed since forever, and taking this route would naturally solve the problem. 0 allocations are a no no anyways. I do agree with the series iff we endup taking this 'increase the limit size approach'. But I just don't see the need. Thanks, Davidlohr From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751765AbaDVEXi (ORCPT ); Tue, 22 Apr 2014 00:23:38 -0400 Received: from mail-ee0-f47.google.com ([74.125.83.47]:32973 "EHLO mail-ee0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750716AbaDVEXe (ORCPT ); Tue, 22 Apr 2014 00:23:34 -0400 Message-ID: <5355EEC2.4010304@colorfullife.com> Date: Tue, 22 Apr 2014 06:23:30 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Davidlohr Bueso CC: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398101106.2623.6.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1398101106.2623.6.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/21/2014 07:25 PM, Davidlohr Bueso wrote: > On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote: >> Hi all, >> >> the increase of SHMMAX/SHMALL is now a 4 patch series. >> I don't have ideas how to improve it further. > Manfred, is there any difference between this set and the one you sent a > couple of days ago? a) I updated the comments. b) the initial set used TASK_SIZE, not I switch to ULONG_MAX-(1L<<24) >> - Using "0" as a magic value for infinity is even worse, because >> right now 0 means 0, i.e. fail all allocations. > Sorry but I don't quite get this. Using 0 eliminates the need for all > these patches, no? I mean overflows have existed since forever, and > taking this route would naturally solve the problem. 0 allocations are a > no no anyways. No. The patches are required to handle e.g. shmget(,ULONG_MAX,): Right now, shmget(,ULONG_MAX,) results in a 0-byte segment. The risk of using 0 is that it reverses the current behavior: Up to now, # sysctl kernel.shmall=0 disables allocations. If we define 0 a infinity, then the same configuration would allow unlimited allocations. -- Manfred From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755260AbaDVSSS (ORCPT ); Tue, 22 Apr 2014 14:18:18 -0400 Received: from g2t2352.austin.hp.com ([15.217.128.51]:55240 "EHLO g2t2352.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751222AbaDVSSQ (ORCPT ); Tue, 22 Apr 2014 14:18:16 -0400 Message-ID: <1398190693.2473.7.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL From: Davidlohr Bueso To: Manfred Spraul Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Date: Tue, 22 Apr 2014 11:18:13 -0700 In-Reply-To: <5355EEC2.4010304@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398101106.2623.6.camel@buesod1.americas.hpqcorp.net> <5355EEC2.4010304@colorfullife.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2014-04-22 at 06:23 +0200, Manfred Spraul wrote: > On 04/21/2014 07:25 PM, Davidlohr Bueso wrote: > > On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote: > >> Hi all, > >> > >> the increase of SHMMAX/SHMALL is now a 4 patch series. > >> I don't have ideas how to improve it further. > > Manfred, is there any difference between this set and the one you sent a > > couple of days ago? > a) I updated the comments. > b) the initial set used TASK_SIZE, not I switch to ULONG_MAX-(1L<<24) > > >> - Using "0" as a magic value for infinity is even worse, because > >> right now 0 means 0, i.e. fail all allocations. > > Sorry but I don't quite get this. Using 0 eliminates the need for all > > these patches, no? I mean overflows have existed since forever, and > > taking this route would naturally solve the problem. 0 allocations are a > > no no anyways. > No. The patches are required to handle e.g. shmget(,ULONG_MAX,): > Right now, shmget(,ULONG_MAX,) results in a 0-byte segment. Ok, I was mixing 'issues' then. > The risk of using 0 is that it reverses the current behavior: > Up to now, > # sysctl kernel.shmall=0 > disables allocations. > If we define 0 a infinity, then the same configuration would allow > unlimited allocations. Right, but as I mentioned, this also contradicts the fact that shmmin cannot be 0. And again, I don't know who's correct here. Do any standards mention this? I haven't found anything, and hard-codding shmmin to 1 seems to be different among OSs, Linux choosing to do so. This difference must also be commented in the manpage. That said, I believe that violating this "feature" and forbidding disabling shm would probably have a more severe penalty (security, perhaps) for users who rely on this. So while I'm really annoyed that we "cannot" use 0 because of this, I'm going to give up arguing. I believe you approach is the safer way of going. Thanks a lot for looking into this, Manfred. Davidlohr From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755367AbaDVSSl (ORCPT ); Tue, 22 Apr 2014 14:18:41 -0400 Received: from g2t2353.austin.hp.com ([15.217.128.52]:39369 "EHLO g2t2353.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751222AbaDVSSk (ORCPT ); Tue, 22 Apr 2014 14:18:40 -0400 Message-ID: <1398190717.2473.8.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 1/4] ipc/shm.c: check for ulong overflows in shmat From: Davidlohr Bueso To: Manfred Spraul Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Date: Tue, 22 Apr 2014 11:18:37 -0700 In-Reply-To: <1398090397-2397-2-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote: > find_vma_intersection does not work as intended if addr+size overflows. > The patch adds a manual check before the call to find_vma_intersection. > > Signed-off-by: Manfred Spraul Acked-by: Davidlohr Bueso From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755444AbaDVSS7 (ORCPT ); Tue, 22 Apr 2014 14:18:59 -0400 Received: from g6t1526.atlanta.hp.com ([15.193.200.69]:30254 "EHLO g6t1526.atlanta.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751222AbaDVSS4 (ORCPT ); Tue, 22 Apr 2014 14:18:56 -0400 Message-ID: <1398190732.2473.9.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 2/4] ipc/shm.c: check for overflows of shm_tot From: Davidlohr Bueso To: Manfred Spraul Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Date: Tue, 22 Apr 2014 11:18:52 -0700 In-Reply-To: <1398090397-2397-3-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote: > shm_tot counts the total number of pages used by shm segments. > > If SHMALL is ULONG_MAX (or nearly ULONG_MAX), then the number > can overflow. Subsequent calls to shmctl(,SHM_INFO,) would return > wrong values for shm_tot. > > The patch adds a detection for overflows. > > Signed-off-by: Manfred Spraul Acked-by: Davidlohr Bueso From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755493AbaDVSTM (ORCPT ); Tue, 22 Apr 2014 14:19:12 -0400 Received: from g5t1626.atlanta.hp.com ([15.192.137.9]:57653 "EHLO g5t1626.atlanta.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751222AbaDVSTI (ORCPT ); Tue, 22 Apr 2014 14:19:08 -0400 Message-ID: <1398190745.2473.10.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 3/4] ipc/shm.c: check for integer overflow during shmget. From: Davidlohr Bueso To: Manfred Spraul Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Date: Tue, 22 Apr 2014 11:19:05 -0700 In-Reply-To: <1398090397-2397-4-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> <1398090397-2397-4-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote: > SHMMAX is the upper limit for the size of a shared memory segment, > counted in bytes. The actual allocation is that size, rounded up to > the next full page. > Add a check that prevents the creation of segments where the > rounded up size causes an integer overflow. > > Signed-off-by: Manfred Spraul Acked-by: Davidlohr Bueso From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753718AbaDVSVU (ORCPT ); Tue, 22 Apr 2014 14:21:20 -0400 Received: from g2t2353.austin.hp.com ([15.217.128.52]:40189 "EHLO g2t2353.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750811AbaDVSVS (ORCPT ); Tue, 22 Apr 2014 14:21:18 -0400 Message-ID: <1398190871.2473.12.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 4/4] ipc/shm.c: Increase the defaults for SHMALL, SHMMAX. From: Davidlohr Bueso To: Manfred Spraul Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Date: Tue, 22 Apr 2014 11:21:11 -0700 In-Reply-To: <1398090397-2397-5-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> <1398090397-2397-4-git-send-email-manfred@colorfullife.com> <1398090397-2397-5-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote: > System V shared memory > > a) can be abused to trigger out-of-memory conditions and the standard > measures against out-of-memory do not work: > > - it is not possible to use setrlimit to limit the size of shm segments. > > - segments can exist without association with any processes, thus > the oom-killer is unable to free that memory. > > b) is typically used for shared information - today often multiple GB. > (e.g. database shared buffers) > > The current default is a maximum segment size of 32 MB and a maximum total > size of 8 GB. This is often too much for a) and not enough for b), which > means that lots of users must change the defaults. > > This patch increases the default limits (nearly) to the maximum, which is > perfect for case b). The defaults are used after boot and as the initial > value for each new namespace. > > Admins/distros that need a protection against a) should reduce the limits > and/or enable shm_rmid_forced. > > Further notes: > - The patch only changes default, overrides behave as before: > # sysctl kernel.shmall=33554432 > would recreate the previous limit for SHMMAX (for the current namespace). > > - Disabling sysv shm allocation is possible with: > # sysctl kernel.shmall=0 > (not a new feature, also per-namespace) > > - The limits are intentionally set to a value slightly less than ULONG_MAX, > to avoid triggering overflows in user space apps. > [not unreasonable, see http://marc.info/?l=linux-mm&m=139638334330127] > > Signed-off-by: Manfred Spraul > Reported-by: Davidlohr Bueso > Cc: mtk.manpages@gmail.com Signed-off-by: Davidlohr Bueso With one comment below. > --- > include/linux/shm.h | 3 +-- > include/uapi/linux/shm.h | 8 +++----- > 2 files changed, 4 insertions(+), 7 deletions(-) > > diff --git a/include/linux/shm.h b/include/linux/shm.h > index 1e2cd2e..57d7770 100644 > --- a/include/linux/shm.h > +++ b/include/linux/shm.h > @@ -3,9 +3,8 @@ > > #include > #include > - > -#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) */ > #include > + > struct shmid_kernel /* private to the kernel */ > { > struct kern_ipc_perm shm_perm; > diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h > index 78b6941..74e786d 100644 > --- a/include/uapi/linux/shm.h > +++ b/include/uapi/linux/shm.h > @@ -9,15 +9,13 @@ > > /* > * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can > - * be increased by sysctl > + * be modified by sysctl. > */ > > -#define SHMMAX 0x2000000 /* max shared seg size (bytes) */ > #define SHMMIN 1 /* min shared seg size (bytes) */ > #define SHMMNI 4096 /* max num of segs system wide */ > -#ifndef __KERNEL__ > -#define SHMALL (SHMMAX/getpagesize()*(SHMMNI/16)) > -#endif > +#define SHMMAX (ULONG_MAX - (1L<<24)) /* max shared seg size (bytes) */ > +#define SHMALL (ULONG_MAX - (1L<<24)) /* max shm system wide (pages) */ It's quite clear in the changelog, but could you please add a big fat comment explaining this option, and that there's no point in enlarging it. In fact if the user wants to make it bigger, we should display some printk_once mentioning that this is the upper limit. Thanks, Davidlohr From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754347AbaDVS24 (ORCPT ); Tue, 22 Apr 2014 14:28:56 -0400 Received: from g5t1625.atlanta.hp.com ([15.192.137.8]:33879 "EHLO g5t1625.atlanta.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753229AbaDVS2z (ORCPT ); Tue, 22 Apr 2014 14:28:55 -0400 Message-ID: <1398191332.2473.14.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 4/4] ipc/shm.c: Increase the defaults for SHMALL, SHMMAX. From: Davidlohr Bueso To: Manfred Spraul Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Date: Tue, 22 Apr 2014 11:28:52 -0700 In-Reply-To: <1398090397-2397-5-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> <1398090397-2397-4-git-send-email-manfred@colorfullife.com> <1398090397-2397-5-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote: > System V shared memory > > a) can be abused to trigger out-of-memory conditions and the standard > measures against out-of-memory do not work: > > - it is not possible to use setrlimit to limit the size of shm segments. > > - segments can exist without association with any processes, thus > the oom-killer is unable to free that memory. > > b) is typically used for shared information - today often multiple GB. > (e.g. database shared buffers) > > The current default is a maximum segment size of 32 MB and a maximum total > size of 8 GB. This is often too much for a) and not enough for b), which > means that lots of users must change the defaults. Per Andrew's request, I think the following should go here from the changelog of my patch: Unix has historically required setting these limits for shared memory, and Linux inherited such behavior. The consequence of this is added complexity for users and administrators. One very common example are Database setup/installation documents and scripts, where users must manually calculate the values for these limits. This also requires (some) knowledge of how the underlying memory management works, thus causing, in many occasions, the limits to just be flat out wrong. Disabling these limits sooner could have saved companies a lot of time, headaches and money for support. But it's never too late, simplify users life now. > This patch increases the default limits (nearly) to the maximum, which is > perfect for case b). The defaults are used after boot and as the initial > value for each new namespace. > > Admins/distros that need a protection against a) should reduce the limits > and/or enable shm_rmid_forced. > > Further notes: > - The patch only changes default, overrides behave as before: > # sysctl kernel.shmall=33554432 > would recreate the previous limit for SHMMAX (for the current namespace). > > - Disabling sysv shm allocation is possible with: > # sysctl kernel.shmall=0 > (not a new feature, also per-namespace) > > - The limits are intentionally set to a value slightly less than ULONG_MAX, > to avoid triggering overflows in user space apps. > [not unreasonable, see http://marc.info/?l=linux-mm&m=139638334330127] > > Signed-off-by: Manfred Spraul > Reported-by: Davidlohr Bueso > Cc: mtk.manpages@gmail.com > --- > include/linux/shm.h | 3 +-- > include/uapi/linux/shm.h | 8 +++----- > 2 files changed, 4 insertions(+), 7 deletions(-) > > diff --git a/include/linux/shm.h b/include/linux/shm.h > index 1e2cd2e..57d7770 100644 > --- a/include/linux/shm.h > +++ b/include/linux/shm.h > @@ -3,9 +3,8 @@ > > #include > #include > - > -#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) */ > #include > + > struct shmid_kernel /* private to the kernel */ > { > struct kern_ipc_perm shm_perm; > diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h > index 78b6941..74e786d 100644 > --- a/include/uapi/linux/shm.h > +++ b/include/uapi/linux/shm.h > @@ -9,15 +9,13 @@ > > /* > * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can > - * be increased by sysctl > + * be modified by sysctl. > */ > > -#define SHMMAX 0x2000000 /* max shared seg size (bytes) */ > #define SHMMIN 1 /* min shared seg size (bytes) */ > #define SHMMNI 4096 /* max num of segs system wide */ > -#ifndef __KERNEL__ > -#define SHMALL (SHMMAX/getpagesize()*(SHMMNI/16)) > -#endif > +#define SHMMAX (ULONG_MAX - (1L<<24)) /* max shared seg size (bytes) */ > +#define SHMALL (ULONG_MAX - (1L<<24)) /* max shm system wide (pages) */ > #define SHMSEG SHMMNI /* max shared segs per process */ > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757611AbaDVUS7 (ORCPT ); Tue, 22 Apr 2014 16:18:59 -0400 Received: from fujitsu24.fnanic.fujitsu.com ([192.240.6.14]:43484 "EHLO fujitsu24.fnanic.fujitsu.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752602AbaDVUSy (ORCPT ); Tue, 22 Apr 2014 16:18:54 -0400 From: Motohiro Kosaki To: Davidlohr Bueso , Manfred Spraul CC: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , Motohiro Kosaki JP , "gthelen@google.com" , "aswin@hp.com" , "linux-mm@kvack.org" Date: Tue, 22 Apr 2014 13:15:44 -0700 Subject: RE: [PATCH 1/4] ipc/shm.c: check for ulong overflows in shmat Thread-Topic: [PATCH 1/4] ipc/shm.c: check for ulong overflows in shmat Thread-Index: Ac9eV05g8AatLGBhQXat4RU3I6X5TAAEDz8w Message-ID: <6B2BA408B38BA1478B473C31C3D2074E30989E9D7A@SV-EXCHANGE1.Corp.FC.LOCAL> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398190717.2473.8.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1398190717.2473.8.camel@buesod1.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96,1.0.14,0.0.0000 definitions=2014-04-22_07:2014-04-22,2014-04-22,1970-01-01 signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id s3MKJAMA011690 > > find_vma_intersection does not work as intended if addr+size overflows. > > The patch adds a manual check before the call to find_vma_intersection. > > > > Signed-off-by: Manfred Spraul > > Acked-by: Davidlohr Bueso Acked-by: KOSAKI Motohiro {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757672AbaDVUT3 (ORCPT ); Tue, 22 Apr 2014 16:19:29 -0400 Received: from fujitsu24.fnanic.fujitsu.com ([192.240.6.14]:43523 "EHLO fujitsu24.fnanic.fujitsu.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757120AbaDVUT0 convert rfc822-to-8bit (ORCPT ); Tue, 22 Apr 2014 16:19:26 -0400 From: Motohiro Kosaki To: Manfred Spraul , Davidlohr Bueso , Michael Kerrisk , "Martin Schwidefsky" CC: LKML , Andrew Morton , KAMEZAWA Hiroyuki , Motohiro Kosaki JP , "gthelen@google.com" , "aswin@hp.com" , "linux-mm@kvack.org" Date: Tue, 22 Apr 2014 13:17:15 -0700 Subject: RE: [PATCH 4/4] ipc/shm.c: Increase the defaults for SHMALL, SHMMAX. Thread-Topic: [PATCH 4/4] ipc/shm.c: Increase the defaults for SHMALL, SHMMAX. Thread-Index: Ac9dbnUTvQMbe/7bTAyv8Lpx+hrP8AA+VU4g Message-ID: <6B2BA408B38BA1478B473C31C3D2074E30989E9D84@SV-EXCHANGE1.Corp.FC.LOCAL> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> <1398090397-2397-4-git-send-email-manfred@colorfullife.com> <1398090397-2397-5-git-send-email-manfred@colorfullife.com> In-Reply-To: <1398090397-2397-5-git-send-email-manfred@colorfullife.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96,1.0.14,0.0.0000 definitions=2014-04-22_07:2014-04-22,2014-04-22,1970-01-01 signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > -----Original Message----- > From: Manfred Spraul [mailto:manfred@colorfullife.com] > Sent: Monday, April 21, 2014 10:27 AM > To: Davidlohr Bueso; Michael Kerrisk; Martin Schwidefsky > Cc: LKML; Andrew Morton; KAMEZAWA Hiroyuki; Motohiro Kosaki JP; gthelen@google.com; aswin@hp.com; linux-mm@kvack.org; > Manfred Spraul > Subject: [PATCH 4/4] ipc/shm.c: Increase the defaults for SHMALL, SHMMAX. > > System V shared memory > > a) can be abused to trigger out-of-memory conditions and the standard > measures against out-of-memory do not work: > > - it is not possible to use setrlimit to limit the size of shm segments. > > - segments can exist without association with any processes, thus > the oom-killer is unable to free that memory. > > b) is typically used for shared information - today often multiple GB. > (e.g. database shared buffers) > > The current default is a maximum segment size of 32 MB and a maximum total size of 8 GB. This is often too much for a) and not > enough for b), which means that lots of users must change the defaults. > > This patch increases the default limits (nearly) to the maximum, which is perfect for case b). The defaults are used after boot and as > the initial value for each new namespace. > > Admins/distros that need a protection against a) should reduce the limits and/or enable shm_rmid_forced. > > Further notes: > - The patch only changes default, overrides behave as before: > # sysctl kernel.shmall=33554432 > would recreate the previous limit for SHMMAX (for the current namespace). > > - Disabling sysv shm allocation is possible with: > # sysctl kernel.shmall=0 > (not a new feature, also per-namespace) > > - The limits are intentionally set to a value slightly less than ULONG_MAX, > to avoid triggering overflows in user space apps. > [not unreasonable, see http://marc.info/?l=linux-mm&m=139638334330127] > > Signed-off-by: Manfred Spraul > Reported-by: Davidlohr Bueso > Cc: mtk.manpages@gmail.com Acked-by: KOSAKI Motohiro From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757628AbaDVUTG (ORCPT ); Tue, 22 Apr 2014 16:19:06 -0400 Received: from fujitsu24.fnanic.fujitsu.com ([192.240.6.14]:43488 "EHLO fujitsu24.fnanic.fujitsu.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752602AbaDVUTC (ORCPT ); Tue, 22 Apr 2014 16:19:02 -0400 From: Motohiro Kosaki To: Davidlohr Bueso , Manfred Spraul CC: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , Motohiro Kosaki JP , "gthelen@google.com" , "aswin@hp.com" , "linux-mm@kvack.org" Date: Tue, 22 Apr 2014 13:16:11 -0700 Subject: RE: [PATCH 2/4] ipc/shm.c: check for overflows of shm_tot Thread-Topic: [PATCH 2/4] ipc/shm.c: check for overflows of shm_tot Thread-Index: Ac9eV1dNSCDEMlrZSliksQ0yynExBAAEE8Tg Message-ID: <6B2BA408B38BA1478B473C31C3D2074E30989E9D7E@SV-EXCHANGE1.Corp.FC.LOCAL> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> <1398190732.2473.9.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1398190732.2473.9.camel@buesod1.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96,1.0.14,0.0.0000 definitions=2014-04-22_07:2014-04-22,2014-04-22,1970-01-01 signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id s3ML79FA012699 > > shm_tot counts the total number of pages used by shm segments. > > > > If SHMALL is ULONG_MAX (or nearly ULONG_MAX), then the number can > > overflow. Subsequent calls to shmctl(,SHM_INFO,) would return wrong > > values for shm_tot. > > > > The patch adds a detection for overflows. > > > > Signed-off-by: Manfred Spraul > > Acked-by: Davidlohr Bueso Acked-by: KOSAKI Motohiro {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758555AbaDVVIz (ORCPT ); Tue, 22 Apr 2014 17:08:55 -0400 Received: from fujitsu25.fnanic.fujitsu.com ([192.240.6.15]:49759 "EHLO fujitsu25.fnanic.fujitsu.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752269AbaDVUSi (ORCPT ); Tue, 22 Apr 2014 16:18:38 -0400 From: Motohiro Kosaki To: Davidlohr Bueso , Manfred Spraul CC: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , Motohiro Kosaki JP , "gthelen@google.com" , "aswin@hp.com" , "linux-mm@kvack.org" Date: Tue, 22 Apr 2014 13:16:38 -0700 Subject: RE: [PATCH 3/4] ipc/shm.c: check for integer overflow during shmget. Thread-Topic: [PATCH 3/4] ipc/shm.c: check for integer overflow during shmget. Thread-Index: Ac9eV2DClosdxWOdShqJG1lf929rngAEFWSQ Message-ID: <6B2BA408B38BA1478B473C31C3D2074E30989E9D81@SV-EXCHANGE1.Corp.FC.LOCAL> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> <1398090397-2397-4-git-send-email-manfred@colorfullife.com> <1398190745.2473.10.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1398190745.2473.10.camel@buesod1.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96,1.0.14,0.0.0000 definitions=2014-04-22_07:2014-04-22,2014-04-22,1970-01-01 signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id s3ML92qA012712 > > SHMMAX is the upper limit for the size of a shared memory segment, > > counted in bytes. The actual allocation is that size, rounded up to > > the next full page. > > Add a check that prevents the creation of segments where the rounded > > up size causes an integer overflow. > > > > Signed-off-by: Manfred Spraul > > Acked-by: Davidlohr Bueso Acked-by: KOSAKI Motohiro {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755914AbaDWCyF (ORCPT ); Tue, 22 Apr 2014 22:54:05 -0400 Received: from g2t2354.austin.hp.com ([15.217.128.53]:40883 "EHLO g2t2354.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751248AbaDWCyD (ORCPT ); Tue, 22 Apr 2014 22:54:03 -0400 Message-ID: <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> Subject: [PATCH 5/4] ipc,shm: minor cleanups From: Davidlohr Bueso To: Manfred Spraul Cc: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Date: Tue, 22 Apr 2014 19:53:56 -0700 In-Reply-To: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org - Breakup long function names/args. - Cleaup variable declaration. - s/current->mm/mm Signed-off-by: Davidlohr Bueso --- ipc/shm.c | 40 +++++++++++++++++----------------------- 1 file changed, 17 insertions(+), 23 deletions(-) diff --git a/ipc/shm.c b/ipc/shm.c index f000696..584d02e 100644 --- a/ipc/shm.c +++ b/ipc/shm.c @@ -480,15 +480,13 @@ static const struct vm_operations_struct shm_vm_ops = { static int newseg(struct ipc_namespace *ns, struct ipc_params *params) { key_t key = params->key; - int shmflg = params->flg; + int id, error, shmflg = params->flg; size_t size = params->u.size; - int error; - struct shmid_kernel *shp; size_t numpages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT; - struct file *file; char name[13]; - int id; vm_flags_t acctflag = 0; + struct shmid_kernel *shp; + struct file *file; if (size < SHMMIN || size > ns->shm_ctlmax) return -EINVAL; @@ -681,7 +679,8 @@ copy_shmid_from_user(struct shmid64_ds *out, void __user *buf, int version) } } -static inline unsigned long copy_shminfo_to_user(void __user *buf, struct shminfo64 *in, int version) +static inline unsigned long copy_shminfo_to_user(void __user *buf, + struct shminfo64 *in, int version) { switch (version) { case IPC_64: @@ -711,8 +710,8 @@ static inline unsigned long copy_shminfo_to_user(void __user *buf, struct shminf * Calculate and add used RSS and swap pages of a shm. * Called with shm_ids.rwsem held as a reader */ -static void shm_add_rss_swap(struct shmid_kernel *shp, - unsigned long *rss_add, unsigned long *swp_add) +static void shm_add_rss_swap(struct shmid_kernel *shp, unsigned long *rss_add, + unsigned long *swp_add) { struct inode *inode; @@ -739,7 +738,7 @@ static void shm_add_rss_swap(struct shmid_kernel *shp, * Called with shm_ids.rwsem held as a reader */ static void shm_get_stat(struct ipc_namespace *ns, unsigned long *rss, - unsigned long *swp) + unsigned long *swp) { int next_id; int total, in_use; @@ -1047,21 +1046,16 @@ out_unlock1: long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr, unsigned long shmlba) { - struct shmid_kernel *shp; - unsigned long addr; - unsigned long size; + unsigned long addr, size, flags, prot, populate = 0; struct file *file; - int err; - unsigned long flags; - unsigned long prot; - int acc_mode; + int acc_mode, err = -EINVAL; struct ipc_namespace *ns; struct shm_file_data *sfd; + struct shmid_kernel *shp; struct path path; fmode_t f_mode; - unsigned long populate = 0; + struct mm_struct *mm = current->mm; - err = -EINVAL; if (shmid < 0) goto out; else if ((addr = (ulong)shmaddr)) { @@ -1161,20 +1155,20 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr, if (err) goto out_fput; - down_write(¤t->mm->mmap_sem); + down_write(&mm->mmap_sem); if (addr && !(shmflg & SHM_REMAP)) { err = -EINVAL; if (addr + size < addr) goto invalid; - if (find_vma_intersection(current->mm, addr, addr + size)) + if (find_vma_intersection(mm, addr, addr + size)) goto invalid; /* * If shm segment goes below stack, make sure there is some * space left for the stack to grow (at least 4 pages). */ - if (addr < current->mm->start_stack && - addr > current->mm->start_stack - size - PAGE_SIZE * 5) + if (addr < mm->start_stack && + addr > mm->start_stack - size - PAGE_SIZE * 5) goto invalid; } @@ -1184,7 +1178,7 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr, if (IS_ERR_VALUE(addr)) err = (long)addr; invalid: - up_write(¤t->mm->mmap_sem); + up_write(&mm->mmap_sem); if (populate) mm_populate(addr, populate); -- 1.8.1.4 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752767AbaDWFFw (ORCPT ); Wed, 23 Apr 2014 01:05:52 -0400 Received: from mail-ee0-f44.google.com ([74.125.83.44]:45647 "EHLO mail-ee0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751527AbaDWFFv (ORCPT ); Wed, 23 Apr 2014 01:05:51 -0400 Message-ID: <53574867.5010108@gmail.com> Date: Wed, 23 Apr 2014 06:58:15 +0200 From: "Michael Kerrisk (man-pages)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky CC: mtk.manpages@gmail.com, LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Subject: Re: [PATCH 1/4] ipc/shm.c: check for ulong overflows in shmat References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> In-Reply-To: <1398090397-2397-2-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/21/2014 04:26 PM, Manfred Spraul wrote: > find_vma_intersection does not work as intended if addr+size overflows. > The patch adds a manual check before the call to find_vma_intersection. > > Signed-off-by: Manfred Spraul > --- > ipc/shm.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/ipc/shm.c b/ipc/shm.c > index 7645961..382e2fb 100644 > --- a/ipc/shm.c > +++ b/ipc/shm.c > @@ -1160,6 +1160,9 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr, > down_write(¤t->mm->mmap_sem); > if (addr && !(shmflg & SHM_REMAP)) { > err = -EINVAL; > + if (addr + size < addr) > + goto invalid; > + > if (find_vma_intersection(current->mm, addr, addr + size)) > goto invalid; > /* > Acked-by: Michael Kerrisk -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752845AbaDWFF4 (ORCPT ); Wed, 23 Apr 2014 01:05:56 -0400 Received: from mail-ee0-f45.google.com ([74.125.83.45]:50296 "EHLO mail-ee0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751527AbaDWFFx (ORCPT ); Wed, 23 Apr 2014 01:05:53 -0400 Message-ID: <53574888.4090602@gmail.com> Date: Wed, 23 Apr 2014 06:58:48 +0200 From: "Michael Kerrisk (man-pages)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky CC: mtk.manpages@gmail.com, LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Subject: Re: [PATCH 2/4] ipc/shm.c: check for overflows of shm_tot References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> In-Reply-To: <1398090397-2397-3-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/21/2014 04:26 PM, Manfred Spraul wrote: > shm_tot counts the total number of pages used by shm segments. > > If SHMALL is ULONG_MAX (or nearly ULONG_MAX), then the number > can overflow. Subsequent calls to shmctl(,SHM_INFO,) would return > wrong values for shm_tot. > > The patch adds a detection for overflows. > > Signed-off-by: Manfred Spraul > --- > ipc/shm.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/ipc/shm.c b/ipc/shm.c > index 382e2fb..2dfa3d6 100644 > --- a/ipc/shm.c > +++ b/ipc/shm.c > @@ -493,7 +493,8 @@ static int newseg(struct ipc_namespace *ns, struct ipc_params *params) > if (size < SHMMIN || size > ns->shm_ctlmax) > return -EINVAL; > > - if (ns->shm_tot + numpages > ns->shm_ctlall) > + if (ns->shm_tot + numpages < ns->shm_tot || > + ns->shm_tot + numpages > ns->shm_ctlall) > return -ENOSPC; > > shp = ipc_rcu_alloc(sizeof(*shp)); > Acked-by: Michael Kerrisk -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752883AbaDWFGE (ORCPT ); Wed, 23 Apr 2014 01:06:04 -0400 Received: from mail-ee0-f53.google.com ([74.125.83.53]:41624 "EHLO mail-ee0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751527AbaDWFF6 (ORCPT ); Wed, 23 Apr 2014 01:05:58 -0400 Message-ID: <5357490E.1010505@gmail.com> Date: Wed, 23 Apr 2014 07:01:02 +0200 From: "Michael Kerrisk (man-pages)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky CC: mtk.manpages@gmail.com, LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Subject: Re: [PATCH 4/4] ipc/shm.c: Increase the defaults for SHMALL, SHMMAX. References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> <1398090397-2397-4-git-send-email-manfred@colorfullife.com> <1398090397-2397-5-git-send-email-manfred@colorfullife.com> In-Reply-To: <1398090397-2397-5-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/21/2014 04:26 PM, Manfred Spraul wrote: > System V shared memory > > a) can be abused to trigger out-of-memory conditions and the standard > measures against out-of-memory do not work: > > - it is not possible to use setrlimit to limit the size of shm segments. > > - segments can exist without association with any processes, thus > the oom-killer is unable to free that memory. > > b) is typically used for shared information - today often multiple GB. > (e.g. database shared buffers) > > The current default is a maximum segment size of 32 MB and a maximum total > size of 8 GB. This is often too much for a) and not enough for b), which > means that lots of users must change the defaults. > > This patch increases the default limits (nearly) to the maximum, which is > perfect for case b). The defaults are used after boot and as the initial > value for each new namespace. > > Admins/distros that need a protection against a) should reduce the limits > and/or enable shm_rmid_forced. > > Further notes: > - The patch only changes default, overrides behave as before: > # sysctl kernel.shmall=33554432 > would recreate the previous limit for SHMMAX (for the current namespace). > > - Disabling sysv shm allocation is possible with: > # sysctl kernel.shmall=0 > (not a new feature, also per-namespace) > > - The limits are intentionally set to a value slightly less than ULONG_MAX, > to avoid triggering overflows in user space apps. > [not unreasonable, see http://marc.info/?l=linux-mm&m=139638334330127] > > Signed-off-by: Manfred Spraul > Reported-by: Davidlohr Bueso > Cc: mtk.manpages@gmail.com > --- > include/linux/shm.h | 3 +-- > include/uapi/linux/shm.h | 8 +++----- > 2 files changed, 4 insertions(+), 7 deletions(-) > > diff --git a/include/linux/shm.h b/include/linux/shm.h > index 1e2cd2e..57d7770 100644 > --- a/include/linux/shm.h > +++ b/include/linux/shm.h > @@ -3,9 +3,8 @@ > > #include > #include > - > -#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) */ > #include > + > struct shmid_kernel /* private to the kernel */ > { > struct kern_ipc_perm shm_perm; > diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h > index 78b6941..74e786d 100644 > --- a/include/uapi/linux/shm.h > +++ b/include/uapi/linux/shm.h > @@ -9,15 +9,13 @@ > > /* > * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can > - * be increased by sysctl > + * be modified by sysctl. > */ > > -#define SHMMAX 0x2000000 /* max shared seg size (bytes) */ > #define SHMMIN 1 /* min shared seg size (bytes) */ > #define SHMMNI 4096 /* max num of segs system wide */ > -#ifndef __KERNEL__ > -#define SHMALL (SHMMAX/getpagesize()*(SHMMNI/16)) > -#endif > +#define SHMMAX (ULONG_MAX - (1L<<24)) /* max shared seg size (bytes) */ > +#define SHMALL (ULONG_MAX - (1L<<24)) /* max shm system wide (pages) */ > #define SHMSEG SHMMNI /* max shared segs per process */ Acked-by: Michael Kerrisk -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752965AbaDWFG2 (ORCPT ); Wed, 23 Apr 2014 01:06:28 -0400 Received: from mail-ee0-f48.google.com ([74.125.83.48]:41071 "EHLO mail-ee0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752809AbaDWFF4 (ORCPT ); Wed, 23 Apr 2014 01:05:56 -0400 Message-ID: <535748AD.9000804@gmail.com> Date: Wed, 23 Apr 2014 06:59:25 +0200 From: "Michael Kerrisk (man-pages)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky CC: mtk.manpages@gmail.com, LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Subject: Re: [PATCH 3/4] ipc/shm.c: check for integer overflow during shmget. References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398090397-2397-2-git-send-email-manfred@colorfullife.com> <1398090397-2397-3-git-send-email-manfred@colorfullife.com> <1398090397-2397-4-git-send-email-manfred@colorfullife.com> In-Reply-To: <1398090397-2397-4-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/21/2014 04:26 PM, Manfred Spraul wrote: > SHMMAX is the upper limit for the size of a shared memory segment, > counted in bytes. The actual allocation is that size, rounded up to > the next full page. > Add a check that prevents the creation of segments where the > rounded up size causes an integer overflow. > > Signed-off-by: Manfred Spraul > --- > ipc/shm.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/ipc/shm.c b/ipc/shm.c > index 2dfa3d6..f000696 100644 > --- a/ipc/shm.c > +++ b/ipc/shm.c > @@ -493,6 +493,9 @@ static int newseg(struct ipc_namespace *ns, struct ipc_params *params) > if (size < SHMMIN || size > ns->shm_ctlmax) > return -EINVAL; > > + if (numpages << PAGE_SHIFT < size) > + return -ENOSPC; > + > if (ns->shm_tot + numpages < ns->shm_tot || > ns->shm_tot + numpages > ns->shm_ctlall) > return -ENOSPC; > Acked-by: Michael Kerrisk -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753155AbaDWFHy (ORCPT ); Wed, 23 Apr 2014 01:07:54 -0400 Received: from mail-ee0-f44.google.com ([74.125.83.44]:35303 "EHLO mail-ee0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752158AbaDWFHv (ORCPT ); Wed, 23 Apr 2014 01:07:51 -0400 Message-ID: <53574AA5.1060205@gmail.com> Date: Wed, 23 Apr 2014 07:07:49 +0200 From: "Michael Kerrisk (man-pages)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Davidlohr Bueso , Manfred Spraul CC: mtk.manpages@gmail.com, Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Subject: Re: [PATCH 5/4] ipc,shm: minor cleanups References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/23/2014 04:53 AM, Davidlohr Bueso wrote: > - Breakup long function names/args. > - Cleaup variable declaration. > - s/current->mm/mm > > Signed-off-by: Davidlohr Bueso > --- > ipc/shm.c | 40 +++++++++++++++++----------------------- > 1 file changed, 17 insertions(+), 23 deletions(-) > > diff --git a/ipc/shm.c b/ipc/shm.c > index f000696..584d02e 100644 > --- a/ipc/shm.c > +++ b/ipc/shm.c > @@ -480,15 +480,13 @@ static const struct vm_operations_struct shm_vm_ops = { > static int newseg(struct ipc_namespace *ns, struct ipc_params *params) > { > key_t key = params->key; > - int shmflg = params->flg; > + int id, error, shmflg = params->flg; It's largely a matter of taste (and I may be in a minority), and I know there's certainly precedent in the kernel code, but I don't much like the style of mixing variable declarations that have initializers, with other unrelated declarations (e.g., variables without initializers). What is the gain? One less line of text? That's (IMO) more than offset by the small loss of readability. Cheers, Michael > size_t size = params->u.size; > - int error; > - struct shmid_kernel *shp; > size_t numpages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT; > - struct file *file; > char name[13]; > - int id; > vm_flags_t acctflag = 0; > + struct shmid_kernel *shp; > + struct file *file; > > if (size < SHMMIN || size > ns->shm_ctlmax) > return -EINVAL; > @@ -681,7 +679,8 @@ copy_shmid_from_user(struct shmid64_ds *out, void __user *buf, int version) > } > } > > -static inline unsigned long copy_shminfo_to_user(void __user *buf, struct shminfo64 *in, int version) > +static inline unsigned long copy_shminfo_to_user(void __user *buf, > + struct shminfo64 *in, int version) > { > switch (version) { > case IPC_64: > @@ -711,8 +710,8 @@ static inline unsigned long copy_shminfo_to_user(void __user *buf, struct shminf > * Calculate and add used RSS and swap pages of a shm. > * Called with shm_ids.rwsem held as a reader > */ > -static void shm_add_rss_swap(struct shmid_kernel *shp, > - unsigned long *rss_add, unsigned long *swp_add) > +static void shm_add_rss_swap(struct shmid_kernel *shp, unsigned long *rss_add, > + unsigned long *swp_add) > { > struct inode *inode; > > @@ -739,7 +738,7 @@ static void shm_add_rss_swap(struct shmid_kernel *shp, > * Called with shm_ids.rwsem held as a reader > */ > static void shm_get_stat(struct ipc_namespace *ns, unsigned long *rss, > - unsigned long *swp) > + unsigned long *swp) > { > int next_id; > int total, in_use; > @@ -1047,21 +1046,16 @@ out_unlock1: > long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr, > unsigned long shmlba) > { > - struct shmid_kernel *shp; > - unsigned long addr; > - unsigned long size; > + unsigned long addr, size, flags, prot, populate = 0; > struct file *file; > - int err; > - unsigned long flags; > - unsigned long prot; > - int acc_mode; > + int acc_mode, err = -EINVAL; > struct ipc_namespace *ns; > struct shm_file_data *sfd; > + struct shmid_kernel *shp; > struct path path; > fmode_t f_mode; > - unsigned long populate = 0; > + struct mm_struct *mm = current->mm; > > - err = -EINVAL; > if (shmid < 0) > goto out; > else if ((addr = (ulong)shmaddr)) { > @@ -1161,20 +1155,20 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr, > if (err) > goto out_fput; > > - down_write(¤t->mm->mmap_sem); > + down_write(&mm->mmap_sem); > if (addr && !(shmflg & SHM_REMAP)) { > err = -EINVAL; > if (addr + size < addr) > goto invalid; > > - if (find_vma_intersection(current->mm, addr, addr + size)) > + if (find_vma_intersection(mm, addr, addr + size)) > goto invalid; > /* > * If shm segment goes below stack, make sure there is some > * space left for the stack to grow (at least 4 pages). > */ > - if (addr < current->mm->start_stack && > - addr > current->mm->start_stack - size - PAGE_SIZE * 5) > + if (addr < mm->start_stack && > + addr > mm->start_stack - size - PAGE_SIZE * 5) > goto invalid; > } > > @@ -1184,7 +1178,7 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr, > if (IS_ERR_VALUE(addr)) > err = (long)addr; > invalid: > - up_write(¤t->mm->mmap_sem); > + up_write(&mm->mmap_sem); > if (populate) > mm_populate(addr, populate); > > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753273AbaDWF0n (ORCPT ); Wed, 23 Apr 2014 01:26:43 -0400 Received: from g4t3426.houston.hp.com ([15.201.208.54]:7897 "EHLO g4t3426.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752959AbaDWFZu (ORCPT ); Wed, 23 Apr 2014 01:25:50 -0400 Message-ID: <1398230745.27667.2.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 5/4] ipc,shm: minor cleanups From: Davidlohr Bueso To: "Michael Kerrisk (man-pages)" Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Date: Tue, 22 Apr 2014 22:25:45 -0700 In-Reply-To: <53574AA5.1060205@gmail.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> <53574AA5.1060205@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2014-04-23 at 07:07 +0200, Michael Kerrisk (man-pages) wrote: > On 04/23/2014 04:53 AM, Davidlohr Bueso wrote: > > - Breakup long function names/args. > > - Cleaup variable declaration. > > - s/current->mm/mm > > > > Signed-off-by: Davidlohr Bueso > > --- > > ipc/shm.c | 40 +++++++++++++++++----------------------- > > 1 file changed, 17 insertions(+), 23 deletions(-) > > > > diff --git a/ipc/shm.c b/ipc/shm.c > > index f000696..584d02e 100644 > > --- a/ipc/shm.c > > +++ b/ipc/shm.c > > @@ -480,15 +480,13 @@ static const struct vm_operations_struct shm_vm_ops = { > > static int newseg(struct ipc_namespace *ns, struct ipc_params *params) > > { > > key_t key = params->key; > > - int shmflg = params->flg; > > + int id, error, shmflg = params->flg; > > It's largely a matter of taste (and I may be in a minority), and I know > there's certainly precedent in the kernel code, but I don't much like the > style of mixing variable declarations that have initializers, with other > unrelated declarations (e.g., variables without initializers). What is > the gain? One less line of text? That's (IMO) more than offset by the > small loss of readability. Yes, it's taste. And yes, your in the minority, at least in many core kernel components and ipc. Thanks, Davidlohr From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753000AbaDWF26 (ORCPT ); Wed, 23 Apr 2014 01:28:58 -0400 Received: from mail-ee0-f53.google.com ([74.125.83.53]:38874 "EHLO mail-ee0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751436AbaDWF24 (ORCPT ); Wed, 23 Apr 2014 01:28:56 -0400 Message-ID: <53574F94.4060402@gmail.com> Date: Wed, 23 Apr 2014 07:28:52 +0200 From: "Michael Kerrisk (man-pages)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Davidlohr Bueso CC: mtk.manpages@gmail.com, Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Subject: Re: [PATCH 5/4] ipc,shm: minor cleanups References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> <53574AA5.1060205@gmail.com> <1398230745.27667.2.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1398230745.27667.2.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/23/2014 07:25 AM, Davidlohr Bueso wrote: > On Wed, 2014-04-23 at 07:07 +0200, Michael Kerrisk (man-pages) wrote: >> On 04/23/2014 04:53 AM, Davidlohr Bueso wrote: >>> - Breakup long function names/args. >>> - Cleaup variable declaration. >>> - s/current->mm/mm >>> >>> Signed-off-by: Davidlohr Bueso >>> --- >>> ipc/shm.c | 40 +++++++++++++++++----------------------- >>> 1 file changed, 17 insertions(+), 23 deletions(-) >>> >>> diff --git a/ipc/shm.c b/ipc/shm.c >>> index f000696..584d02e 100644 >>> --- a/ipc/shm.c >>> +++ b/ipc/shm.c >>> @@ -480,15 +480,13 @@ static const struct vm_operations_struct shm_vm_ops = { >>> static int newseg(struct ipc_namespace *ns, struct ipc_params *params) >>> { >>> key_t key = params->key; >>> - int shmflg = params->flg; >>> + int id, error, shmflg = params->flg; >> >> It's largely a matter of taste (and I may be in a minority), and I know >> there's certainly precedent in the kernel code, but I don't much like the >> style of mixing variable declarations that have initializers, with other >> unrelated declarations (e.g., variables without initializers). What is >> the gain? One less line of text? That's (IMO) more than offset by the >> small loss of readability. > > Yes, it's taste. And yes, your in the minority, at least in many core > kernel components and ipc. I figured so. Just giving the minority a small voice ;-). -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757749AbaDWSSn (ORCPT ); Wed, 23 Apr 2014 14:18:43 -0400 Received: from mail-ee0-f50.google.com ([74.125.83.50]:62828 "EHLO mail-ee0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752505AbaDWSSk (ORCPT ); Wed, 23 Apr 2014 14:18:40 -0400 Message-ID: <535803FC.1040605@colorfullife.com> Date: Wed, 23 Apr 2014 20:18:36 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Davidlohr Bueso CC: Davidlohr Bueso , Michael Kerrisk , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Subject: Re: [PATCH 5/4] ipc,shm: minor cleanups References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/23/2014 04:53 AM, Davidlohr Bueso wrote: > - Breakup long function names/args. > - Cleaup variable declaration. s/Cleaup/Cleanup/ > - s/current->mm/mm > > Signed-off-by: Davidlohr Bueso Signed-off-by: Manfred Spraul > @@ -681,7 +679,8 @@ copy_shmid_from_user(struct shmid64_ds *out, void __user *buf, int version) > } > } > > -static inline unsigned long copy_shminfo_to_user(void __user *buf, struct shminfo64 *in, int version) > +static inline unsigned long copy_shminfo_to_user(void __user *buf, > + struct shminfo64 *in, int version) Checkpatch still complains - does removing one tab help? -- Manfred From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751733AbaDWW17 (ORCPT ); Wed, 23 Apr 2014 18:27:59 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:59980 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751161AbaDWW15 (ORCPT ); Wed, 23 Apr 2014 18:27:57 -0400 Date: Wed, 23 Apr 2014 15:27:55 -0700 From: Andrew Morton To: Davidlohr Bueso Cc: "Michael Kerrisk (man-pages)" , Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Subject: Re: [PATCH 5/4] ipc,shm: minor cleanups Message-Id: <20140423152755.7f323cfd0e6901a2907afca8@linux-foundation.org> In-Reply-To: <1398230745.27667.2.camel@buesod1.americas.hpqcorp.net> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> <53574AA5.1060205@gmail.com> <1398230745.27667.2.camel@buesod1.americas.hpqcorp.net> X-Mailer: Sylpheed 3.2.0beta5 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 22 Apr 2014 22:25:45 -0700 Davidlohr Bueso wrote: > On Wed, 2014-04-23 at 07:07 +0200, Michael Kerrisk (man-pages) wrote: > > On 04/23/2014 04:53 AM, Davidlohr Bueso wrote: > > > - Breakup long function names/args. > > > - Cleaup variable declaration. > > > - s/current->mm/mm > > > > > > Signed-off-by: Davidlohr Bueso > > > --- > > > ipc/shm.c | 40 +++++++++++++++++----------------------- > > > 1 file changed, 17 insertions(+), 23 deletions(-) > > > > > > diff --git a/ipc/shm.c b/ipc/shm.c > > > index f000696..584d02e 100644 > > > --- a/ipc/shm.c > > > +++ b/ipc/shm.c > > > @@ -480,15 +480,13 @@ static const struct vm_operations_struct shm_vm_ops = { > > > static int newseg(struct ipc_namespace *ns, struct ipc_params *params) > > > { > > > key_t key = params->key; > > > - int shmflg = params->flg; > > > + int id, error, shmflg = params->flg; > > > > It's largely a matter of taste (and I may be in a minority), and I know > > there's certainly precedent in the kernel code, but I don't much like the > > style of mixing variable declarations that have initializers, with other > > unrelated declarations (e.g., variables without initializers). What is > > the gain? One less line of text? That's (IMO) more than offset by the > > small loss of readability. > > Yes, it's taste. And yes, your in the minority, at least in many core > kernel components and ipc. I'm with Michael. - Putting multiple definitions on the same line (whether or not they are initialized there) makes it impossible to add little comments documenting them. And we need more little comments documenting locals. - Having multiple definitions on the same line is maddening when the time comes to resolve patch conflicts. And it increases the likelihood of conflicts in the first place. - It makes it much harder to *find* a definition. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751792AbaDXFif (ORCPT ); Thu, 24 Apr 2014 01:38:35 -0400 Received: from mail-ee0-f43.google.com ([74.125.83.43]:52946 "EHLO mail-ee0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750860AbaDXFib (ORCPT ); Thu, 24 Apr 2014 01:38:31 -0400 Message-ID: <53589E8E.1040000@gmail.com> Date: Thu, 24 Apr 2014 07:18:06 +0200 From: "Michael Kerrisk (man-pages)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Davidlohr Bueso CC: mtk.manpages@gmail.com, Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Subject: Re: [PATCH 5/4] ipc,shm: minor cleanups References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> <53574AA5.1060205@gmail.com> <1398230745.27667.2.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1398230745.27667.2.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/23/2014 07:25 AM, Davidlohr Bueso wrote: > On Wed, 2014-04-23 at 07:07 +0200, Michael Kerrisk (man-pages) wrote: >> On 04/23/2014 04:53 AM, Davidlohr Bueso wrote: >>> - Breakup long function names/args. >>> - Cleaup variable declaration. >>> - s/current->mm/mm >>> >>> Signed-off-by: Davidlohr Bueso >>> --- >>> ipc/shm.c | 40 +++++++++++++++++----------------------- >>> 1 file changed, 17 insertions(+), 23 deletions(-) >>> >>> diff --git a/ipc/shm.c b/ipc/shm.c >>> index f000696..584d02e 100644 >>> --- a/ipc/shm.c >>> +++ b/ipc/shm.c >>> @@ -480,15 +480,13 @@ static const struct vm_operations_struct shm_vm_ops = { >>> static int newseg(struct ipc_namespace *ns, struct ipc_params *params) >>> { >>> key_t key = params->key; >>> - int shmflg = params->flg; >>> + int id, error, shmflg = params->flg; >> >> It's largely a matter of taste (and I may be in a minority), and I know >> there's certainly precedent in the kernel code, but I don't much like the >> style of mixing variable declarations that have initializers, with other >> unrelated declarations (e.g., variables without initializers). What is >> the gain? One less line of text? That's (IMO) more than offset by the >> small loss of readability. > > Yes, it's taste. And yes, your in the minority, at least in many core > kernel components and ipc. Davidlohr, So, noting that the minority is less small than we thought, I'll just add this: I'd have appreciated it if your reply had been less dismissive, and you'd actually responded to my concrete point about loss of readability. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758297AbaDXRVn (ORCPT ); Thu, 24 Apr 2014 13:21:43 -0400 Received: from g4t3427.houston.hp.com ([15.201.208.55]:1323 "EHLO g4t3427.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754038AbaDXRVm (ORCPT ); Thu, 24 Apr 2014 13:21:42 -0400 Message-ID: <1398360099.2744.8.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 5/4] ipc,shm: minor cleanups From: Davidlohr Bueso To: "Michael Kerrisk (man-pages)" Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , gthelen@google.com, aswin@hp.com, linux-mm@kvack.org Date: Thu, 24 Apr 2014 10:21:39 -0700 In-Reply-To: <53589E8E.1040000@gmail.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1398221636.6345.9.camel@buesod1.americas.hpqcorp.net> <53574AA5.1060205@gmail.com> <1398230745.27667.2.camel@buesod1.americas.hpqcorp.net> <53589E8E.1040000@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2014-04-24 at 07:18 +0200, Michael Kerrisk (man-pages) wrote: > On 04/23/2014 07:25 AM, Davidlohr Bueso wrote: > > On Wed, 2014-04-23 at 07:07 +0200, Michael Kerrisk (man-pages) wrote: > >> On 04/23/2014 04:53 AM, Davidlohr Bueso wrote: > >>> - Breakup long function names/args. > >>> - Cleaup variable declaration. > >>> - s/current->mm/mm > >>> > >>> Signed-off-by: Davidlohr Bueso > >>> --- > >>> ipc/shm.c | 40 +++++++++++++++++----------------------- > >>> 1 file changed, 17 insertions(+), 23 deletions(-) > >>> > >>> diff --git a/ipc/shm.c b/ipc/shm.c > >>> index f000696..584d02e 100644 > >>> --- a/ipc/shm.c > >>> +++ b/ipc/shm.c > >>> @@ -480,15 +480,13 @@ static const struct vm_operations_struct shm_vm_ops = { > >>> static int newseg(struct ipc_namespace *ns, struct ipc_params *params) > >>> { > >>> key_t key = params->key; > >>> - int shmflg = params->flg; > >>> + int id, error, shmflg = params->flg; > >> > >> It's largely a matter of taste (and I may be in a minority), and I know > >> there's certainly precedent in the kernel code, but I don't much like the > >> style of mixing variable declarations that have initializers, with other > >> unrelated declarations (e.g., variables without initializers). What is > >> the gain? One less line of text? That's (IMO) more than offset by the > >> small loss of readability. > > > > Yes, it's taste. And yes, your in the minority, at least in many core > > kernel components and ipc. > > Davidlohr, > > So, noting that the minority is less small than we thought, I'll just > add this: I'd have appreciated it if your reply had been less > dismissive, and you'd actually responded to my concrete point about > loss of readability. Apologies, I didn't mean to sound dismissive. It's just that I don't like arguing over this kind of things. The idea of the cleanups wasn't "lets remove LoC", but more "lets make the style suck less" -- and believe me, ipc code is pretty darn ugly wrt. Over the last few months we've improved it some, but still so much horror. The changes I make are aligned with the general coding style we have in the rest of the kernel, but yes, ultimately it comes down to taste. Anyway, I am in favor of single line declarations with initializers which are *meaningful*. The variables I moved around are not. Thanks, Davidlohr From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752288AbaEBNRB (ORCPT ); Fri, 2 May 2014 09:17:01 -0400 Received: from mail-qg0-f52.google.com ([209.85.192.52]:42209 "EHLO mail-qg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751940AbaEBNQ7 (ORCPT ); Fri, 2 May 2014 09:16:59 -0400 MIME-Version: 1.0 Reply-To: mtk.manpages@gmail.com In-Reply-To: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> From: "Michael Kerrisk (man-pages)" Date: Fri, 2 May 2014 15:16:39 +0200 Message-ID: Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL To: Manfred Spraul Cc: Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Manfred, On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul wrote: > Hi all, > > the increase of SHMMAX/SHMALL is now a 4 patch series. > I don't have ideas how to improve it further. On the assumption that your patches are heading to mainline, could you send me a man-pages patch for the changes? Thanks, Michael > The change itself is trivial, the only problem are interger overflows. > The overflows are not new, but if we make huge values the default, > then the code should be free from overflows. > > SHMMAX: > > - shmmem_file_setup places a hard limit on the segment size: > MAX_LFS_FILESIZE. > > On 32-bit, the limit is > 1 TB, i.e. 4 GB-1 byte segments are > possible. Rounded up to full pages the actual allocated size > is 0. --> must be fixed, patch 3 > > - shmat: > - find_vma_intersection does not handle overflows properly. > --> must be fixed, patch 1 > > - the rest is fine, do_mmap_pgoff limits mappings to TASK_SIZE > and checks for overflows (i.e.: map 2 GB, starting from > addr=2.5GB fails). > > SHMALL: > - after creating 8192 segments size (1L<<63)-1, shm_tot overflows and > returns 0. --> must be fixed, patch 2. > > User space: > - Obviuosly, there could be overflows in user space. There is nothing > we can do, only use values smaller than ULONG_MAX. > I ended with "ULONG_MAX - 1L<<24": > > - TASK_SIZE cannot be used because it is the size of the current > task. Could be 4G if it's a 32-bit task on a 64-bit kernel. > > - The maximum size is not standardized across archs: > I found TASK_MAX_SIZE, TASK_SIZE_MAX and TASK_SIZE_64. > > - Just in case some arch revives a 4G/4G split, nearly > ULONG_MAX is a valid segment size. > > - Using "0" as a magic value for infinity is even worse, because > right now 0 means 0, i.e. fail all allocations. > > Andrew: Could you add it into -akpm and move it towards linux-next? > > -- > Manfred -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754668AbaEFUGw (ORCPT ); Tue, 6 May 2014 16:06:52 -0400 Received: from g2t2352.austin.hp.com ([15.217.128.51]:31467 "EHLO g2t2352.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754179AbaEFUGu (ORCPT ); Tue, 6 May 2014 16:06:50 -0400 Message-ID: <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL From: Davidlohr Bueso To: mtk.manpages@gmail.com Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" Date: Tue, 06 May 2014 13:06:40 -0700 In-Reply-To: References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2014-05-02 at 15:16 +0200, Michael Kerrisk (man-pages) wrote: > Hi Manfred, > > On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul > wrote: > > Hi all, > > > > the increase of SHMMAX/SHMALL is now a 4 patch series. > > I don't have ideas how to improve it further. > > On the assumption that your patches are heading to mainline, could you > send me a man-pages patch for the changes? Btw, I think that the code could still use some love wrt documentation. Andrew, please consider this for -next if folks agree. Thanks. 8<---------------------------------------------------------- From: Davidlohr Bueso Subject: [PATCH] ipc,shm: document new limits in the uapi header This is useful in the future and allows users to better understand the reasoning behind the changes. Also use UL as we're dealing with it anyways. Signed-off-by: Davidlohr Bueso --- include/uapi/linux/shm.h | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h index 74e786d..e37fb08 100644 --- a/include/uapi/linux/shm.h +++ b/include/uapi/linux/shm.h @@ -8,17 +8,19 @@ #endif /* - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can - * be modified by sysctl. + * SHMMNI, SHMMAX and SHMALL are the default upper limits which can be + * modified by sysctl. Both SHMMAX and SHMALL have their default values + * to the maximum limit which is as large as it can be without helping + * userspace overflow the values. There is really nothing the kernel + * can do to avoid this any variables. It is therefore not advised to + * make them any larger. This is suitable for both 32 and 64-bit systems. */ - #define SHMMIN 1 /* min shared seg size (bytes) */ #define SHMMNI 4096 /* max num of segs system wide */ -#define SHMMAX (ULONG_MAX - (1L<<24)) /* max shared seg size (bytes) */ -#define SHMALL (ULONG_MAX - (1L<<24)) /* max shm system wide (pages) */ +#define SHMMAX (ULONG_MAX - (1UL << 24)) /* max shared seg size (bytes) */ +#define SHMALL (ULONG_MAX - (1UL << 24)) /* max shm system wide (pages) */ #define SHMSEG SHMMNI /* max shared segs per process */ - /* Obsolete, used only for backwards compatibility and libc5 compiles */ struct shmid_ds { struct ipc_perm shm_perm; /* operation perms */ -- 1.8.1.4 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755158AbaEFUkp (ORCPT ); Tue, 6 May 2014 16:40:45 -0400 Received: from mail-qg0-f43.google.com ([209.85.192.43]:50107 "EHLO mail-qg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751458AbaEFUko (ORCPT ); Tue, 6 May 2014 16:40:44 -0400 MIME-Version: 1.0 Reply-To: mtk.manpages@gmail.com In-Reply-To: <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> From: "Michael Kerrisk (man-pages)" Date: Tue, 6 May 2014 22:40:23 +0200 Message-ID: Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL To: Davidlohr Bueso Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Davidlohr, On Tue, May 6, 2014 at 10:06 PM, Davidlohr Bueso wrote: > On Fri, 2014-05-02 at 15:16 +0200, Michael Kerrisk (man-pages) wrote: >> Hi Manfred, >> >> On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul >> wrote: >> > Hi all, >> > >> > the increase of SHMMAX/SHMALL is now a 4 patch series. >> > I don't have ideas how to improve it further. >> >> On the assumption that your patches are heading to mainline, could you >> send me a man-pages patch for the changes? > > Btw, I think that the code could still use some love wrt documentation. (Agreed.) > Andrew, please consider this for -next if folks agree. Thanks. > > 8<---------------------------------------------------------- > > From: Davidlohr Bueso > Subject: [PATCH] ipc,shm: document new limits in the uapi header > > This is useful in the future and allows users to > better understand the reasoning behind the changes. > > Also use UL as we're dealing with it anyways. > > Signed-off-by: Davidlohr Bueso > --- > include/uapi/linux/shm.h | 14 ++++++++------ > 1 file changed, 8 insertions(+), 6 deletions(-) > > diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h > index 74e786d..e37fb08 100644 > --- a/include/uapi/linux/shm.h > +++ b/include/uapi/linux/shm.h > @@ -8,17 +8,19 @@ > #endif > > /* > - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can Something is wrong in the line above (missing word(s)?) ("are upper limits are defaults") > - * be modified by sysctl. > + * SHMMNI, SHMMAX and SHMALL are the default upper limits which can be > + * modified by sysctl. Both SHMMAX and SHMALL have their default values > + * to the maximum limit which is as large as it can be without helping > + * userspace overflow the values. There is really nothing the kernel > + * can do to avoid this any variables. It is therefore not advised to Something is missing in that last line. > + * make them any larger. This is suitable for both 32 and 64-bit systems. "This" is not so clear. I suggest replacing with an actual noun. > */ > - > #define SHMMIN 1 /* min shared seg size (bytes) */ > #define SHMMNI 4096 /* max num of segs system wide */ > -#define SHMMAX (ULONG_MAX - (1L<<24)) /* max shared seg size (bytes) */ > -#define SHMALL (ULONG_MAX - (1L<<24)) /* max shm system wide (pages) */ > +#define SHMMAX (ULONG_MAX - (1UL << 24)) /* max shared seg size (bytes) */ > +#define SHMALL (ULONG_MAX - (1UL << 24)) /* max shm system wide (pages) */ > #define SHMSEG SHMMNI /* max shared segs per process */ > > - > /* Obsolete, used only for backwards compatibility and libc5 compiles */ > struct shmid_ds { > struct ipc_perm shm_perm; /* operation perms */ Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756054AbaEFUnh (ORCPT ); Tue, 6 May 2014 16:43:37 -0400 Received: from g5t1627.atlanta.hp.com ([15.192.137.10]:14565 "EHLO g5t1627.atlanta.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755309AbaEFUnf (ORCPT ); Tue, 6 May 2014 16:43:35 -0400 Message-ID: <1399409007.13799.24.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL From: Davidlohr Bueso To: mtk.manpages@gmail.com Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" Date: Tue, 06 May 2014 13:43:27 -0700 In-Reply-To: <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2014-05-06 at 13:06 -0700, Davidlohr Bueso wrote: > On Fri, 2014-05-02 at 15:16 +0200, Michael Kerrisk (man-pages) wrote: > > Hi Manfred, > > > > On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul > > wrote: > > > Hi all, > > > > > > the increase of SHMMAX/SHMALL is now a 4 patch series. > > > I don't have ideas how to improve it further. > > > > On the assumption that your patches are heading to mainline, could you > > send me a man-pages patch for the changes? > > Btw, I think that the code could still use some love wrt documentation. > Andrew, please consider this for -next if folks agree. Thanks. > > 8<---------------------------------------------------------- > > From: Davidlohr Bueso > Subject: [PATCH] ipc,shm: document new limits in the uapi header > > This is useful in the future and allows users to > better understand the reasoning behind the changes. > > Also use UL as we're dealing with it anyways. > > Signed-off-by: Davidlohr Bueso > --- > include/uapi/linux/shm.h | 14 ++++++++------ > 1 file changed, 8 insertions(+), 6 deletions(-) > > diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h > index 74e786d..e37fb08 100644 > --- a/include/uapi/linux/shm.h > +++ b/include/uapi/linux/shm.h > @@ -8,17 +8,19 @@ > #endif > > /* > - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can > - * be modified by sysctl. > + * SHMMNI, SHMMAX and SHMALL are the default upper limits which can be > + * modified by sysctl. Both SHMMAX and SHMALL have their default values > + * to the maximum limit which is as large as it can be without helping > + * userspace overflow the values. There is really nothing the kernel > + * can do to avoid this any variables. It is therefore not advised to ^^^^^^^^^^ should be 'further', sorry. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754496AbaEFWIG (ORCPT ); Tue, 6 May 2014 18:08:06 -0400 Received: from g2t2354.austin.hp.com ([15.217.128.53]:44210 "EHLO g2t2354.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751473AbaEFWIF (ORCPT ); Tue, 6 May 2014 18:08:05 -0400 Message-ID: <1399414081.30629.2.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL From: Davidlohr Bueso To: mtk.manpages@gmail.com Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" Date: Tue, 06 May 2014 15:08:01 -0700 In-Reply-To: References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2014-05-06 at 22:40 +0200, Michael Kerrisk (man-pages) wrote: > Hi Davidlohr, > > On Tue, May 6, 2014 at 10:06 PM, Davidlohr Bueso wrote: > > On Fri, 2014-05-02 at 15:16 +0200, Michael Kerrisk (man-pages) wrote: > >> Hi Manfred, > >> > >> On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul > >> wrote: > >> > Hi all, > >> > > >> > the increase of SHMMAX/SHMALL is now a 4 patch series. > >> > I don't have ideas how to improve it further. > >> > >> On the assumption that your patches are heading to mainline, could you > >> send me a man-pages patch for the changes? > > > > Btw, I think that the code could still use some love wrt documentation. > > (Agreed.) > > > Andrew, please consider this for -next if folks agree. Thanks. > > > > 8<---------------------------------------------------------- > > > > From: Davidlohr Bueso > > Subject: [PATCH] ipc,shm: document new limits in the uapi header > > > > This is useful in the future and allows users to > > better understand the reasoning behind the changes. > > > > Also use UL as we're dealing with it anyways. > > > > Signed-off-by: Davidlohr Bueso > > --- > > include/uapi/linux/shm.h | 14 ++++++++------ > > 1 file changed, 8 insertions(+), 6 deletions(-) > > > > diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h > > index 74e786d..e37fb08 100644 > > --- a/include/uapi/linux/shm.h > > +++ b/include/uapi/linux/shm.h > > @@ -8,17 +8,19 @@ > > #endif > > > > /* > > - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can > > Something is wrong in the line above (missing word(s)?) ("are upper > limits are defaults") > > > - * be modified by sysctl. > > + * SHMMNI, SHMMAX and SHMALL are the default upper limits which can be > > + * modified by sysctl. Both SHMMAX and SHMALL have their default values > > + * to the maximum limit which is as large as it can be without helping > > + * userspace overflow the values. There is really nothing the kernel > > + * can do to avoid this any variables. It is therefore not advised to > > Something is missing in that last line. > > > + * make them any larger. This is suitable for both 32 and 64-bit systems. > > "This" is not so clear. I suggest replacing with an actual noun. Good point. Perhaps 'These values are ...' would do instead. Thanks, Davidlohr From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751977AbaEGRtj (ORCPT ); Wed, 7 May 2014 13:49:39 -0400 Received: from mail-ee0-f44.google.com ([74.125.83.44]:57487 "EHLO mail-ee0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751524AbaEGRt0 (ORCPT ); Wed, 7 May 2014 13:49:26 -0400 Message-ID: <5369C43D.1000206@gmail.com> Date: Wed, 07 May 2014 07:27:25 +0200 From: "Michael Kerrisk (man-pages)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Davidlohr Bueso CC: mtk.manpages@gmail.com, Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> <1399414081.30629.2.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1399414081.30629.2.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/07/2014 12:08 AM, Davidlohr Bueso wrote: > On Tue, 2014-05-06 at 22:40 +0200, Michael Kerrisk (man-pages) wrote: >> Hi Davidlohr, >> >> On Tue, May 6, 2014 at 10:06 PM, Davidlohr Bueso wrote: >>> On Fri, 2014-05-02 at 15:16 +0200, Michael Kerrisk (man-pages) wrote: >>>> Hi Manfred, >>>> >>>> On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul >>>> wrote: >>>>> Hi all, >>>>> >>>>> the increase of SHMMAX/SHMALL is now a 4 patch series. >>>>> I don't have ideas how to improve it further. >>>> >>>> On the assumption that your patches are heading to mainline, could you >>>> send me a man-pages patch for the changes? >>> >>> Btw, I think that the code could still use some love wrt documentation. >> >> (Agreed.) >> >>> Andrew, please consider this for -next if folks agree. Thanks. >>> >>> 8<---------------------------------------------------------- >>> >>> From: Davidlohr Bueso >>> Subject: [PATCH] ipc,shm: document new limits in the uapi header >>> >>> This is useful in the future and allows users to >>> better understand the reasoning behind the changes. >>> >>> Also use UL as we're dealing with it anyways. >>> >>> Signed-off-by: Davidlohr Bueso >>> --- >>> include/uapi/linux/shm.h | 14 ++++++++------ >>> 1 file changed, 8 insertions(+), 6 deletions(-) >>> >>> diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h >>> index 74e786d..e37fb08 100644 >>> --- a/include/uapi/linux/shm.h >>> +++ b/include/uapi/linux/shm.h >>> @@ -8,17 +8,19 @@ >>> #endif >>> >>> /* >>> - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can >> >> Something is wrong in the line above (missing word(s)?) ("are upper >> limits are defaults") >> >>> - * be modified by sysctl. >>> + * SHMMNI, SHMMAX and SHMALL are the default upper limits which can be >>> + * modified by sysctl. Both SHMMAX and SHMALL have their default values >>> + * to the maximum limit which is as large as it can be without helping >>> + * userspace overflow the values. There is really nothing the kernel >>> + * can do to avoid this any variables. It is therefore not advised to >> >> Something is missing in that last line. >> >>> + * make them any larger. This is suitable for both 32 and 64-bit systems. >> >> "This" is not so clear. I suggest replacing with an actual noun. > > Good point. Perhaps 'These values are ...' would do instead. That's better. Did you miss the first point I raised above? Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751899AbaEGSWt (ORCPT ); Wed, 7 May 2014 14:22:49 -0400 Received: from g4t3427.houston.hp.com ([15.201.208.55]:17364 "EHLO g4t3427.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751282AbaEGSWr (ORCPT ); Wed, 7 May 2014 14:22:47 -0400 Message-ID: <1399486965.4567.9.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL From: Davidlohr Bueso To: "Michael Kerrisk (man-pages)" Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" Date: Wed, 07 May 2014 11:22:45 -0700 In-Reply-To: <5369C43D.1000206@gmail.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> <1399414081.30629.2.camel@buesod1.americas.hpqcorp.net> <5369C43D.1000206@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2014-05-07 at 07:27 +0200, Michael Kerrisk (man-pages) wrote: > On 05/07/2014 12:08 AM, Davidlohr Bueso wrote: > > On Tue, 2014-05-06 at 22:40 +0200, Michael Kerrisk (man-pages) wrote: > >> Hi Davidlohr, > >> > >> On Tue, May 6, 2014 at 10:06 PM, Davidlohr Bueso wrote: > >>> On Fri, 2014-05-02 at 15:16 +0200, Michael Kerrisk (man-pages) wrote: > >>>> Hi Manfred, > >>>> > >>>> On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul > >>>> wrote: > >>>>> Hi all, > >>>>> > >>>>> the increase of SHMMAX/SHMALL is now a 4 patch series. > >>>>> I don't have ideas how to improve it further. > >>>> > >>>> On the assumption that your patches are heading to mainline, could you > >>>> send me a man-pages patch for the changes? > >>> > >>> Btw, I think that the code could still use some love wrt documentation. > >> > >> (Agreed.) > >> > >>> Andrew, please consider this for -next if folks agree. Thanks. > >>> > >>> 8<---------------------------------------------------------- > >>> > >>> From: Davidlohr Bueso > >>> Subject: [PATCH] ipc,shm: document new limits in the uapi header > >>> > >>> This is useful in the future and allows users to > >>> better understand the reasoning behind the changes. > >>> > >>> Also use UL as we're dealing with it anyways. > >>> > >>> Signed-off-by: Davidlohr Bueso > >>> --- > >>> include/uapi/linux/shm.h | 14 ++++++++------ > >>> 1 file changed, 8 insertions(+), 6 deletions(-) > >>> > >>> diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h > >>> index 74e786d..e37fb08 100644 > >>> --- a/include/uapi/linux/shm.h > >>> +++ b/include/uapi/linux/shm.h > >>> @@ -8,17 +8,19 @@ > >>> #endif > >>> > >>> /* > >>> - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can > >> > >> Something is wrong in the line above (missing word(s)?) ("are upper > >> limits are defaults") > >> > >>> - * be modified by sysctl. > >>> + * SHMMNI, SHMMAX and SHMALL are the default upper limits which can be > >>> + * modified by sysctl. Both SHMMAX and SHMALL have their default values > >>> + * to the maximum limit which is as large as it can be without helping > >>> + * userspace overflow the values. There is really nothing the kernel > >>> + * can do to avoid this any variables. It is therefore not advised to > >> > >> Something is missing in that last line. > >> > >>> + * make them any larger. This is suitable for both 32 and 64-bit systems. > >> > >> "This" is not so clear. I suggest replacing with an actual noun. > > > > Good point. Perhaps 'These values are ...' would do instead. > > That's better. > > Did you miss the first point I raised above? No, actually our emails crossed paths and I had sent a suggestion before I replied to yours: https://lkml.org/lkml/2014/5/6/613 Thanks. Davidlohr From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751899AbaEGTRl (ORCPT ); Wed, 7 May 2014 15:17:41 -0400 Received: from g4t3425.houston.hp.com ([15.201.208.53]:19349 "EHLO g4t3425.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751499AbaEGTRg (ORCPT ); Wed, 7 May 2014 15:17:36 -0400 Message-ID: <1399490251.4567.24.camel@buesod1.americas.hpqcorp.net> Subject: [PATCH v2] ipc,shm: document new limits in the uapi header From: Davidlohr Bueso To: "Michael Kerrisk (man-pages)" Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" Date: Wed, 07 May 2014 12:17:31 -0700 In-Reply-To: <1399486965.4567.9.camel@buesod1.americas.hpqcorp.net> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> <1399414081.30629.2.camel@buesod1.americas.hpqcorp.net> <5369C43D.1000206@gmail.com> <1399486965.4567.9.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is useful in the future and allows users to better understand the reasoning behind the changes. Signed-off-by: Davidlohr Bueso --- include/uapi/linux/shm.h | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h index 74e786d..3400b6e 100644 --- a/include/uapi/linux/shm.h +++ b/include/uapi/linux/shm.h @@ -8,17 +8,20 @@ #endif /* - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can - * be modified by sysctl. + * SHMMNI, SHMMAX and SHMALL are the default upper limits which can be + * modified by sysctl. Both SHMMAX and SHMALL have their default values + * to the maximum limit which is as large as it can be without helping + * userspace overflow the values. There is really nothing the kernel + * can do to avoid this any further. It is therefore not advised to + * make them any larger. These limits are suitable for both 32 and + * 64-bit systems. */ - #define SHMMIN 1 /* min shared seg size (bytes) */ #define SHMMNI 4096 /* max num of segs system wide */ -#define SHMMAX (ULONG_MAX - (1L<<24)) /* max shared seg size (bytes) */ -#define SHMALL (ULONG_MAX - (1L<<24)) /* max shm system wide (pages) */ +#define SHMMAX (ULONG_MAX - (1UL << 24)) /* max shared seg size (bytes) */ +#define SHMALL (ULONG_MAX - (1UL << 24)) /* max shm system wide (pages) */ #define SHMSEG SHMMNI /* max shared segs per process */ - /* Obsolete, used only for backwards compatibility and libc5 compiles */ struct shmid_ds { struct ipc_perm shm_perm; /* operation perms */ -- 1.8.1.4 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757531AbaEKUqf (ORCPT ); Sun, 11 May 2014 16:46:35 -0400 Received: from g4t3427.houston.hp.com ([15.201.208.55]:41755 "EHLO g4t3427.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751663AbaEKUqe (ORCPT ); Sun, 11 May 2014 16:46:34 -0400 Message-ID: <1399841186.8629.6.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH v2] ipc,shm: document new limits in the uapi header From: Davidlohr Bueso To: mtk.manpages@gmail.com Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" Date: Sun, 11 May 2014 13:46:26 -0700 In-Reply-To: References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> <1399414081.30629.2.camel@buesod1.americas.hpqcorp.net> <5369C43D.1000206@gmail.com> <1399486965.4567.9.camel@buesod1.americas.hpqcorp.net> <1399490251.4567.24.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2014-05-09 at 10:44 +0200, Michael Kerrisk (man-pages) wrote: > On Wed, May 7, 2014 at 9:17 PM, Davidlohr Bueso wrote: > > This is useful in the future and allows users to > > better understand the reasoning behind the changes. > > > > Signed-off-by: Davidlohr Bueso > > --- > > include/uapi/linux/shm.h | 15 +++++++++------ > > 1 file changed, 9 insertions(+), 6 deletions(-) > > > > diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h > > index 74e786d..3400b6e 100644 > > --- a/include/uapi/linux/shm.h > > +++ b/include/uapi/linux/shm.h > > @@ -8,17 +8,20 @@ > > #endif > > > > /* > > - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can > > - * be modified by sysctl. > > + * SHMMNI, SHMMAX and SHMALL are the default upper limits which can be > > + * modified by sysctl. Both SHMMAX and SHMALL have their default values > > + * to the maximum limit which is as large as it can be without helping > > + * userspace overflow the values. There is really nothing the kernel > > + * can do to avoid this any further. It is therefore not advised to > > + * make them any larger. These limits are suitable for both 32 and > > + * 64-bit systems. > > I somehow find that text still rather impenetrable. What about this: > > SHMMNI, SHMMAX and SHMALL are default upper limits which can be > modified by sysctl. The SHMMAX and SHMALL values have been chosen to > be as large possible without facilitating scenarios where userspace > causes overflows when adjusting the limits via operations of the form > "retrieve current limit; add X; update limit". It is therefore not > advised to make SHMMAX and SHMALL any larger. These limits are > suitable for both 32 and 64-bit systems. I don't really have much preference, imho both read pretty much the same, specially considering this is still code after all. If you guys really prefer updating it, let me know and I'll send a v3. But perhaps your text is a bit more suitable in the svipc manpage? Thanks, Davidlohr From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752555AbaEMBfT (ORCPT ); Mon, 12 May 2014 21:35:19 -0400 Received: from g4t3426.houston.hp.com ([15.201.208.54]:55354 "EHLO g4t3426.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751068AbaEMBfR (ORCPT ); Mon, 12 May 2014 21:35:17 -0400 Message-ID: <1399944913.2648.56.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH v2] ipc,shm: document new limits in the uapi header From: Davidlohr Bueso To: mtk.manpages@gmail.com Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" Date: Mon, 12 May 2014 18:35:13 -0700 In-Reply-To: References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1399406800.13799.20.camel@buesod1.americas.hpqcorp.net> <1399414081.30629.2.camel@buesod1.americas.hpqcorp.net> <5369C43D.1000206@gmail.com> <1399486965.4567.9.camel@buesod1.americas.hpqcorp.net> <1399490251.4567.24.camel@buesod1.americas.hpqcorp.net> <1399841186.8629.6.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2014-05-12 at 09:44 +0200, Michael Kerrisk (man-pages) wrote: > Hi Davidlohr, > > On Sun, May 11, 2014 at 10:46 PM, Davidlohr Bueso wrote: > > On Fri, 2014-05-09 at 10:44 +0200, Michael Kerrisk (man-pages) wrote: > >> On Wed, May 7, 2014 at 9:17 PM, Davidlohr Bueso wrote: > >> > This is useful in the future and allows users to > >> > better understand the reasoning behind the changes. > >> > > >> > Signed-off-by: Davidlohr Bueso > >> > --- > >> > include/uapi/linux/shm.h | 15 +++++++++------ > >> > 1 file changed, 9 insertions(+), 6 deletions(-) > >> > > >> > diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h > >> > index 74e786d..3400b6e 100644 > >> > --- a/include/uapi/linux/shm.h > >> > +++ b/include/uapi/linux/shm.h > >> > @@ -8,17 +8,20 @@ > >> > #endif > >> > > >> > /* > >> > - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can > >> > - * be modified by sysctl. > >> > + * SHMMNI, SHMMAX and SHMALL are the default upper limits which can be > >> > + * modified by sysctl. Both SHMMAX and SHMALL have their default values > >> > + * to the maximum limit which is as large as it can be without helping > >> > + * userspace overflow the values. There is really nothing the kernel > >> > + * can do to avoid this any further. It is therefore not advised to > >> > + * make them any larger. These limits are suitable for both 32 and > >> > + * 64-bit systems. > >> > >> I somehow find that text still rather impenetrable. What about this: > >> > >> SHMMNI, SHMMAX and SHMALL are default upper limits which can be > >> modified by sysctl. The SHMMAX and SHMALL values have been chosen to > >> be as large possible without facilitating scenarios where userspace > >> causes overflows when adjusting the limits via operations of the form > >> "retrieve current limit; add X; update limit". It is therefore not > >> advised to make SHMMAX and SHMALL any larger. These limits are > >> suitable for both 32 and 64-bit systems. > > > > I don't really have much preference, imho both read pretty much the > > same, specially considering this is still code after all. If you guys > > really prefer updating it, let me know and I'll send a v3. But perhaps > > your text is a bit more suitable in the svipc manpage? > > The problem is that part of your text is still broken grammatically In > particular, the piece "Both SHMMAX and SHMALL have their default > values to the maximum limit" at the very least lacks a word. That's > what prompted me to propose the alternative, rather than just say > "this is wrong"--and I thought that I might as well make a more > thoroughgoing attempt at helping improve the text. > > I agree that text something like this should land in the man page at > some point, but as long as we're going to the trouble to improve the > comments in the code, let's make them as good and helpful as we can. Fair enough, and I trust your grammar corrections over mine ;) Thanks for taking a closer look. I've added your text below. 8<------------------------------------------ From: Davidlohr Bueso Subject: [PATCH v3] ipc,shm: document new limits in the uapi header This is useful in the future and allows users to better understand the reasoning behind the changes. Signed-off-by: Davidlohr Bueso --- include/uapi/linux/shm.h | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h index 74e786d..1fbf24e 100644 --- a/include/uapi/linux/shm.h +++ b/include/uapi/linux/shm.h @@ -8,17 +8,20 @@ #endif /* - * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can - * be modified by sysctl. + * SHMMNI, SHMMAX and SHMALL are default upper limits which can be + * modified by sysctl. The SHMMAX and SHMALL values have been chosen to + * be as large possible without facilitating scenarios where userspace + * causes overflows when adjusting the limits via operations of the form + * "retrieve current limit; add X; update limit". It is therefore not + * advised to make SHMMAX and SHMALL any larger. These limits are + * suitable for both 32 and 64-bit systems. */ - #define SHMMIN 1 /* min shared seg size (bytes) */ #define SHMMNI 4096 /* max num of segs system wide */ -#define SHMMAX (ULONG_MAX - (1L<<24)) /* max shared seg size (bytes) */ -#define SHMALL (ULONG_MAX - (1L<<24)) /* max shm system wide (pages) */ +#define SHMMAX (ULONG_MAX - (1UL << 24)) /* max shared seg size (bytes) */ +#define SHMALL (ULONG_MAX - (1UL << 24)) /* max shm system wide (pages) */ #define SHMSEG SHMMNI /* max shared segs per process */ - /* Obsolete, used only for backwards compatibility and libc5 compiles */ struct shmid_ds { struct ipc_perm shm_perm; /* operation perms */ -- 1.8.1.4 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753988AbaFCT0I (ORCPT ); Tue, 3 Jun 2014 15:26:08 -0400 Received: from g4t3426.houston.hp.com ([15.201.208.54]:15120 "EHLO g4t3426.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751489AbaFCT0G (ORCPT ); Tue, 3 Jun 2014 15:26:06 -0400 Message-ID: <1401823560.4911.2.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL From: Davidlohr Bueso To: mtk.manpages@gmail.com Cc: Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" Date: Tue, 03 Jun 2014 12:26:00 -0700 In-Reply-To: References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2014-05-02 at 15:16 +0200, Michael Kerrisk (man-pages) wrote: > Hi Manfred, > > On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul > wrote: > > Hi all, > > > > the increase of SHMMAX/SHMALL is now a 4 patch series. > > I don't have ideas how to improve it further. > > On the assumption that your patches are heading to mainline, could you > send me a man-pages patch for the changes? It seems we're still behind here and the 3.16 merge window is already opened. Please consider this, and again feel free to add/modify as necessary. I think adding a note as below is enough and was hesitant to add a lot of details... Thanks. 8<-------------------------------------------------- From: Davidlohr Bueso Subject: [PATCH] shmget.2: document new limits for shmmax/shmall These limits have been recently enlarged and modifying them is no longer really necessary. Update the manpage. Signed-off-by: Davidlohr Bueso --- man2/shmget.2 | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/man2/shmget.2 b/man2/shmget.2 index f781048..77764ea 100644 --- a/man2/shmget.2 +++ b/man2/shmget.2 @@ -299,6 +299,11 @@ with 8kB page size, it yields 2^20 (1048576). On Linux, this limit can be read and modified via .IR /proc/sys/kernel/shmall . +As of Linux 3.16, the default value for this limit is increased to +.B ULONG_MAX - 2^24 +pages, which is as large as it can be without helping userspace overflow +the values. Modifying this limit is therefore discouraged. This is suitable +for both 32 and 64-bit systems. .TP .B SHMMAX Maximum size in bytes for a shared memory segment. @@ -306,6 +311,12 @@ Since Linux 2.2, the default value of this limit is 0x2000000 (32MB). On Linux, this limit can be read and modified via .IR /proc/sys/kernel/shmmax . +As of Linux 3.16, the default value for this limit is increased from 32Mb +to +.B ULONG_MAX - 2^24 +bytes, which is as large as it can be without helping userspace overflow +the values. Modifying this limit is therefore discouraged. This is suitable +for both 32 and 64-bit systems. .TP .B SHMMIN Minimum size in bytes for a shared memory segment: implementation -- 1.8.1.4 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753519AbaIWFYb (ORCPT ); Tue, 23 Sep 2014 01:24:31 -0400 Received: from mail-la0-f44.google.com ([209.85.215.44]:50801 "EHLO mail-la0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753195AbaIWFYa (ORCPT ); Tue, 23 Sep 2014 01:24:30 -0400 Message-ID: <54210407.1000602@gmail.com> Date: Tue, 23 Sep 2014 07:24:23 +0200 From: "Michael Kerrisk (man-pages)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Davidlohr Bueso CC: mtk.manpages@gmail.com, Manfred Spraul , Davidlohr Bueso , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1401823560.4911.2.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1401823560.4911.2.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/03/2014 09:26 PM, Davidlohr Bueso wrote: > On Fri, 2014-05-02 at 15:16 +0200, Michael Kerrisk (man-pages) wrote: >> Hi Manfred, >> >> On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul >> wrote: >>> Hi all, >>> >>> the increase of SHMMAX/SHMALL is now a 4 patch series. >>> I don't have ideas how to improve it further. >> >> On the assumption that your patches are heading to mainline, could you >> send me a man-pages patch for the changes? > > It seems we're still behind here and the 3.16 merge window is already > opened. Please consider this, and again feel free to add/modify as > necessary. I think adding a note as below is enough and was hesitant to > add a lot of details... Thanks. > > 8<-------------------------------------------------- > From: Davidlohr Bueso > Subject: [PATCH] shmget.2: document new limits for shmmax/shmall > > These limits have been recently enlarged and > modifying them is no longer really necessary. > Update the manpage. > > Signed-off-by: Davidlohr Bueso > --- > man2/shmget.2 | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/man2/shmget.2 b/man2/shmget.2 > index f781048..77764ea 100644 > --- a/man2/shmget.2 > +++ b/man2/shmget.2 > @@ -299,6 +299,11 @@ with 8kB page size, it yields 2^20 (1048576). > > On Linux, this limit can be read and modified via > .IR /proc/sys/kernel/shmall . > +As of Linux 3.16, the default value for this limit is increased to > +.B ULONG_MAX - 2^24 > +pages, which is as large as it can be without helping userspace overflow > +the values. Modifying this limit is therefore discouraged. This is suitable > +for both 32 and 64-bit systems. > .TP > .B SHMMAX > Maximum size in bytes for a shared memory segment. > @@ -306,6 +311,12 @@ Since Linux 2.2, the default value of this limit is 0x2000000 (32MB). > > On Linux, this limit can be read and modified via > .IR /proc/sys/kernel/shmmax . > +As of Linux 3.16, the default value for this limit is increased from 32Mb > +to > +.B ULONG_MAX - 2^24 > +bytes, which is as large as it can be without helping userspace overflow > +the values. Modifying this limit is therefore discouraged. This is suitable > +for both 32 and 64-bit systems. > .TP > .B SHMMIN > Minimum size in bytes for a shared memory segment: implementation David, I applied various pieces from your patch on top of material that I already had, so that now we have the text below describing these limits. Comments/suggestions/improvements from all welcome. Cheers, Michael SHMALL System-wide limit on the number of pages of shared memory. On Linux, this limit can be read and modified via /proc/sys/kernel/shmall. Since Linux 3.16, the default value for this limit is: ULONG_MAX - 2^24 The effect of this value (which is suitable for both 32-bit and 64-bit systems) is to impose no limitation on allocations. This value, rather than ULONG_MAX, was cho‐ sen as the default to prevent some cases where historical applications simply raised the existing limit without first checking its current value. Such applications would cause the value to overflow if the limit was set at ULONG_MAX. From Linux 2.4 up to Linux 3.15, the default value for this limit was: SHMMAX / PAGE_SIZE * (SHMMNI / 16) If SHMMAX and SHMMNI were not modified, then multiplying the result of this formula by the page size (to get a value in bytes) yielded a value of 8 GB as the limit on the total memory used by all shared memory segments. SHMMAX Maximum size in bytes for a shared memory segment. On Linux, this limit can be read and modified via /proc/sys/kernel/shmmax. Since Linux 3.16, the default value for this limit is: ULONG_MAX - 2^24 The effect of this value (which is suitable for both 32-bit and 64-bit systems) is to impose no limitation on allocations. See the description of SHMALL for a discus‐ sion of why this default value (rather than ULONG_MAX) is used. From Linux 2.2 up to Linux 3.15, the default value of this limit was 0x2000000 (32MB). Because it is not possible to map just part of a shared memory segment, the amount of virtual memory places another limit on the maximum size of a usable segment: for example, on i386 the largest segments that can be mapped have a size of around 2.8 GB, and on x86_64 the limit is around 127 TB. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754065AbaIXID7 (ORCPT ); Wed, 24 Sep 2014 04:03:59 -0400 Received: from homie.mail.dreamhost.com ([208.97.132.208]:56199 "EHLO homiemail-a60.g.dreamhost.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753485AbaIXICR (ORCPT ); Wed, 24 Sep 2014 04:02:17 -0400 Message-ID: <1411545734.30630.4.camel@linux-t7sj.site> Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL From: Davidlohr Bueso To: "Michael Kerrisk (man-pages)" Cc: Manfred Spraul , Martin Schwidefsky , LKML , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Greg Thelen , aswin@hp.com, "linux-mm@kvack.org" Date: Wed, 24 Sep 2014 10:02:14 +0200 In-Reply-To: <54210407.1000602@gmail.com> References: <1398090397-2397-1-git-send-email-manfred@colorfullife.com> <1401823560.4911.2.camel@buesod1.americas.hpqcorp.net> <54210407.1000602@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2014-09-23 at 07:24 +0200, Michael Kerrisk (man-pages) wrote: > David, > > I applied various pieces from your patch on top of material > that I already had, so that now we have the text below describing > these limits. Comments/suggestions/improvements from all welcome. Looks good, thanks!