On Tue, 01 Apr 2014 10:01:39 -0700 Davidlohr Bueso <davidlohr@xxxxxx> wrote: > > > EINVAL A new segment was to be created and size < SHMMIN or size > > > > SHMMAX, or no new segment was to be created, a segment with given key > > > existed, but size is greater than the size of that segment. > > > > So their system will act as if they had set SHMMAX=enormous. What > > problems could that cause? > > So, just like any sysctl configurable, only privileged users can change > this value. If we remove this option, users can theoretically create > huge segments, thus ignoring any custom limit previously set. This is > what I fear. What's wrong with that? Waht are we actually ptoecting the system from? tmpfs exhaustion? > Think of it kind of like mlock's rlimit. And for that > matter, why does sysctl exist at all, the same would go for the rest of > the limits. These things exist to protect the system from intentional or accidental service denials. What are the service denials in this case? > > Look. The 32M thing is causing problems. Arbitrarily increasing the > > arbitrary 32M to an arbitrary 128M won't fix anything - we still have > > the problem. Think bigger, please: how can we make this problem go > > away for ever? > > That's the thing, I don't think we can make it go away without breaking > userspace. Still waiting for details! > I'm not saying that my 4x increase is the correct value, I > don't think any default value is really correct, as with any other > hardcoded limits there are pros and cons. That's really why we give > users the option to change it to the "correct" one via sysctl. All I'm > saying is that 32mb is just too small for default in today's systems, > and increasing it is just making a bad situation a tiny bit better. Let's understand what's preventing us from making it a great deal better. -- 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>