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]
Date:	Fri, 9 May 2014 10:44:11 +0200
From:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:	Davidlohr Bueso <davidlohr@...com>
Cc:	Manfred Spraul <manfred@...orfullife.com>,
	Davidlohr Bueso <davidlohr.bueso@...com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Greg Thelen <gthelen@...gle.com>, aswin@...com,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH v2] ipc,shm: document new limits in the uapi header

On Wed, May 7, 2014 at 9:17 PM, Davidlohr Bueso <davidlohr@...com> wrote:
> This is useful in the future and allows users to
> better understand the reasoning behind the changes.
>
> Signed-off-by: Davidlohr Bueso <davidlohr@...com>
> ---
>  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/
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ