linux-kernel - Re: [PATCH] ipc,shm: increase default size for shmmax

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20140331143217.c6ff958e1fd9944d78507418@linux-foundation.org>
Date:	Mon, 31 Mar 2014 14:32:17 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Davidlohr Bueso <davidlohr@...com>
Cc:	Manfred Spraul <manfred@...orfullife.com>, aswin@...com,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] ipc,shm: increase default size for shmmax

On Sun, 30 Mar 2014 20:06:39 -0700 Davidlohr Bueso <davidlohr@...com> wrote:

> From: Davidlohr Bueso <davidlohr@...com>
> 
> The default size is, and always has been, 32Mb. Today, in the
> XXI century, it seems that this value is rather small, making
> users have to increase it via sysctl, which can cause unnecessary
> work and userspace application workarounds[1]. I have arbitrarily
> chosen a 4x increase, leaving it at 128Mb, and naturally, the
> same goes for shmall. While it may make more sense to set the value
> based on the system memory, this limit must be the same across all
> systems, and left to users to change if needed.
> 
> ...
>
> --- a/include/uapi/linux/shm.h
> +++ b/include/uapi/linux/shm.h
> @@ -12,7 +12,7 @@
>   * be increased by sysctl
>   */
>  
> -#define SHMMAX 0x2000000		 /* max shared seg size (bytes) */
> +#define SHMMAX 0x8000000		 /* max shared seg size (bytes) */
>  #define SHMMIN 1			 /* min shared seg size (bytes) */
>  #define SHMMNI 4096			 /* max num of segs system wide */
>  #ifndef __KERNEL__

urgh.  Perhaps we should have made the default "zero bytes" to force
everyone to think about what they really need and to configure their
systems.  Of course that just means that distros will poke some random
number in there at init time.

- With this change, the limit is no longer "the same across all
  systems" because the patch increases it for more recent kernels.

  Why do you say it "must be the same" and why is this not a problem
  in the develop-on-new-kernel, run-on-old-kernel scenario?

- The sysctl became somewhat pointless when we added ipc namespaces. 
  shm_init_ns() ignores the sysctl and goes straight to SHMMAX, and
  altering the sysctl will have no effect upon existing namespaces
  anyway.

- Shouldn't there be a way to alter this namespace's shm_ctlmax?

- What happens if we just nuke the limit altogether and fall back to
  the next check, which presumably is the rlimit bounds?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/