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 <manfred@xxxxxxxxxxxxxxxx> > Reported-by: Davidlohr Bueso <davidlohr@xxxxxx> > Cc: mtk.manpages@xxxxxxxxx Signed-off-by: Davidlohr Bueso <davidlohr@xxxxxx> 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 <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) */ 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>