linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Davidlohr Bueso <davidlohr@hp.com>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Davidlohr Bueso <davidlohr.bueso@hp.com>,
	LKML <linux-kernel@vger.kernel.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] ipc/shm: disable SHMALL, SHMMAX
Date: Sat, 12 Apr 2014 08:39:59 -0700	[thread overview]
Message-ID: <1397317199.2686.12.camel@buesod1.americas.hpqcorp.net> (raw)
In-Reply-To: <1397303284-2216-1-git-send-email-manfred@colorfullife.com>

On Sat, 2014-04-12 at 13:48 +0200, Manfred Spraul wrote:
> Shared memory segment 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.
> 
> Therefore Linux always limited the size of segments by default to 32 MB.
> As most systems do not need a protection against malicious user space apps,
> a default that forces most admins and distros to change it doesn't make
> sense.
> 
> The patch disables both limits by setting the limits to ULONG_MAX.
> 
> Admins who need a protection against out-of-memory conditions should
> reduce the limits again and/or enable shm_rmid_forced.
> 
> Davidlohr: What do you think?
> 
> I prefer this approach: No need to update the man pages, smaller change
> of the code, smaller risk of user space incompatibilities.

As I've mentioned before, both approaches are correct.

I still much prefer using 0 instead of ULONG_MAX, it's far easier to
understand. And considering the v2 which fixes the shmget(key, 0, flg)
usage, I _still_ don't see why it would cause legitimate user
incompatibilities.

Regarding the manpage, regardless the approach we end up taking, it
should still be updated. This is an important change for users, making
their life easier. We should inform them explicitly about them not
really needing to deal with the hassle of shm limits anymore.

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

  reply	other threads:[~2014-04-12 15:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-12 11:48 Manfred Spraul
2014-04-12 15:39 ` Davidlohr Bueso [this message]
2014-04-12 16:22   ` Davidlohr Bueso

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=1397317199.2686.12.camel@buesod1.americas.hpqcorp.net \
    --to=davidlohr@hp.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 \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox