On Sat, 2014-04-12 at 08:39 -0700, Davidlohr Bueso wrote: > 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. Also, if the user overflows the variable (indicating that he/she wants to increase it to reflect something 'unlimited') and it ends up being 0, then it becomes a valid value, not something totally wrong as it is today. -- 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>