All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Manfred Spraul <manfred@colorfullife.com>,
	Davidlohr Bueso <davidlohr.bueso@hp.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: mtk.manpages@gmail.com, LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	gthelen@google.com, aswin@hp.com, linux-mm@kvack.org
Subject: Re: [PATCH 4/4] ipc/shm.c: Increase the defaults for SHMALL, SHMMAX.
Date: Wed, 23 Apr 2014 07:01:02 +0200	[thread overview]
Message-ID: <5357490E.1010505@gmail.com> (raw)
In-Reply-To: <1398090397-2397-5-git-send-email-manfred@colorfullife.com>

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 <manfred@colorfullife.com>
> Reported-by: Davidlohr Bueso <davidlohr@hp.com>
> 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 <asm/page.h>
>  #include <uapi/linux/shm.h>
> -
> -#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) */
>  #include <asm/shmparam.h>
> +
>  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 <mtk.manpages@gmail.com>


-- 
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Manfred Spraul <manfred@colorfullife.com>,
	Davidlohr Bueso <davidlohr.bueso@hp.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: mtk.manpages@gmail.com, LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	gthelen@google.com, aswin@hp.com, linux-mm@kvack.org
Subject: Re: [PATCH 4/4] ipc/shm.c: Increase the defaults for SHMALL, SHMMAX.
Date: Wed, 23 Apr 2014 07:01:02 +0200	[thread overview]
Message-ID: <5357490E.1010505@gmail.com> (raw)
In-Reply-To: <1398090397-2397-5-git-send-email-manfred@colorfullife.com>

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 <manfred@colorfullife.com>
> Reported-by: Davidlohr Bueso <davidlohr@hp.com>
> 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 <asm/page.h>
>  #include <uapi/linux/shm.h>
> -
> -#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) */
>  #include <asm/shmparam.h>
> +
>  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 <mtk.manpages@gmail.com>


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

  parent reply	other threads:[~2014-04-23  5:05 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-21 14:26 [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL Manfred Spraul
2014-04-21 14:26 ` Manfred Spraul
2014-04-21 14:26 ` [PATCH 1/4] ipc/shm.c: check for ulong overflows in shmat Manfred Spraul
2014-04-21 14:26   ` Manfred Spraul
2014-04-21 14:26   ` [PATCH 2/4] ipc/shm.c: check for overflows of shm_tot Manfred Spraul
2014-04-21 14:26     ` Manfred Spraul
2014-04-21 14:26     ` [PATCH 3/4] ipc/shm.c: check for integer overflow during shmget Manfred Spraul
2014-04-21 14:26       ` Manfred Spraul
2014-04-21 14:26       ` [PATCH 4/4] ipc/shm.c: Increase the defaults for SHMALL, SHMMAX Manfred Spraul
2014-04-21 14:26         ` Manfred Spraul
2014-04-22 18:21         ` Davidlohr Bueso
2014-04-22 18:21           ` Davidlohr Bueso
2014-04-22 18:28         ` Davidlohr Bueso
2014-04-22 18:28           ` Davidlohr Bueso
2014-04-22 20:17         ` Motohiro Kosaki
2014-04-22 20:17           ` Motohiro Kosaki
2014-04-23  5:01         ` Michael Kerrisk (man-pages) [this message]
2014-04-23  5:01           ` Michael Kerrisk (man-pages)
2014-04-22 18:19       ` [PATCH 3/4] ipc/shm.c: check for integer overflow during shmget Davidlohr Bueso
2014-04-22 18:19         ` Davidlohr Bueso
2014-04-22 20:16         ` Motohiro Kosaki
2014-04-22 20:16           ` Motohiro Kosaki
2014-04-23  4:59       ` Michael Kerrisk (man-pages)
2014-04-23  4:59         ` Michael Kerrisk (man-pages)
2014-04-22 18:18     ` [PATCH 2/4] ipc/shm.c: check for overflows of shm_tot Davidlohr Bueso
2014-04-22 18:18       ` Davidlohr Bueso
2014-04-22 20:16       ` Motohiro Kosaki
2014-04-22 20:16         ` Motohiro Kosaki
2014-04-23  4:58     ` Michael Kerrisk (man-pages)
2014-04-23  4:58       ` Michael Kerrisk (man-pages)
2014-04-22 18:18   ` [PATCH 1/4] ipc/shm.c: check for ulong overflows in shmat Davidlohr Bueso
2014-04-22 18:18     ` Davidlohr Bueso
2014-04-22 20:15     ` Motohiro Kosaki
2014-04-22 20:15       ` Motohiro Kosaki
2014-04-23  4:58   ` Michael Kerrisk (man-pages)
2014-04-23  4:58     ` Michael Kerrisk (man-pages)
2014-04-21 17:25 ` [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL Davidlohr Bueso
2014-04-21 17:25   ` Davidlohr Bueso
2014-04-22  4:23   ` Manfred Spraul
2014-04-22  4:23     ` Manfred Spraul
2014-04-22 18:18     ` Davidlohr Bueso
2014-04-22 18:18       ` Davidlohr Bueso
2014-04-23  2:53 ` [PATCH 5/4] ipc,shm: minor cleanups Davidlohr Bueso
2014-04-23  2:53   ` Davidlohr Bueso
2014-04-23  5:07   ` Michael Kerrisk (man-pages)
2014-04-23  5:07     ` Michael Kerrisk (man-pages)
2014-04-23  5:25     ` Davidlohr Bueso
2014-04-23  5:25       ` Davidlohr Bueso
2014-04-23  5:28       ` Michael Kerrisk (man-pages)
2014-04-23  5:28         ` Michael Kerrisk (man-pages)
2014-04-23 22:27       ` Andrew Morton
2014-04-23 22:27         ` Andrew Morton
2014-04-23 22:35         ` Stephen Rothwell
2014-04-24  5:18       ` Michael Kerrisk (man-pages)
2014-04-24  5:18         ` Michael Kerrisk (man-pages)
2014-04-24 17:21         ` Davidlohr Bueso
2014-04-24 17:21           ` Davidlohr Bueso
2014-04-23 18:18   ` Manfred Spraul
2014-04-23 18:18     ` Manfred Spraul
2014-05-02 13:16 ` [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL Michael Kerrisk (man-pages)
2014-05-02 13:16   ` Michael Kerrisk (man-pages)
2014-05-06 20:06   ` Davidlohr Bueso
2014-05-06 20:06     ` Davidlohr Bueso
2014-05-06 20:40     ` Michael Kerrisk (man-pages)
2014-05-06 20:40       ` Michael Kerrisk (man-pages)
2014-05-06 22:08       ` Davidlohr Bueso
2014-05-06 22:08         ` Davidlohr Bueso
2014-05-07  5:27         ` Michael Kerrisk (man-pages)
2014-05-07  5:27           ` Michael Kerrisk (man-pages)
2014-05-07 18:22           ` Davidlohr Bueso
2014-05-07 18:22             ` Davidlohr Bueso
2014-05-07 19:17             ` [PATCH v2] ipc,shm: document new limits in the uapi header Davidlohr Bueso
2014-05-07 19:17               ` Davidlohr Bueso
2014-05-09  8:44               ` Michael Kerrisk (man-pages)
2014-05-11 20:46                 ` Davidlohr Bueso
2014-05-11 20:46                   ` Davidlohr Bueso
2014-05-12  7:44                   ` Michael Kerrisk (man-pages)
2014-05-13  1:35                     ` Davidlohr Bueso
2014-05-13  1:35                       ` Davidlohr Bueso
2014-05-13  6:06                       ` Michael Kerrisk (man-pages)
2014-05-06 20:43     ` [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL Davidlohr Bueso
2014-05-06 20:43       ` Davidlohr Bueso
2014-06-03 19:26   ` Davidlohr Bueso
2014-06-03 19:26     ` Davidlohr Bueso
2014-09-23  5:24     ` Michael Kerrisk (man-pages)
2014-09-23  5:24       ` Michael Kerrisk (man-pages)
2014-09-24  8:02       ` Davidlohr Bueso
2014-09-24  8:02         ` Davidlohr Bueso
  -- strict thread matches above, loose matches on Subject: below --
2014-04-19 11:43 Manfred Spraul
2014-04-19 11:43 ` [PATCH 1/4] ipc/shm.c: check for ulong overflows in shmat Manfred Spraul
2014-04-19 11:43   ` [PATCH 2/4] ipc/shm.c: check for overflows of shm_tot Manfred Spraul
2014-04-19 11:43     ` [PATCH 3/4] ipc/shm.c: check for integer overflow during shmget Manfred Spraul
2014-04-19 11:43       ` [PATCH 4/4] ipc/shm.c: Increase the defaults for SHMALL, SHMMAX Manfred Spraul
2014-04-19 11:43         ` Manfred Spraul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5357490E.1010505@gmail.com \
    --to=mtk.manpages@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=aswin@hp.com \
    --cc=davidlohr.bueso@hp.com \
    --cc=gthelen@google.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=manfred@colorfullife.com \
    --cc=schwidefsky@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.