Messages in this thread | | | Subject | Re: Rationale for RLIMIT_MEMLOCK? | From | Arjan van de Ven <> | Date | Mon, 23 Jan 2006 18:00:02 +0100 |
| |
> > > 4. Is the default hard limit of 32 kB initialized by the kernel or > > > > the kernel has a relatively low default. The reason is simple: allow too > > much mlock and the user can DoS the machine too easy. The kernel default > > should be safe, the admin / distro can very easily override anyway. > > This doesn't appear to happen for SUSE 10.0, which causes trouble with > some of the "multimedia apps" BTW... apparently the limit was lowered at > the same time as the root restrictions were relaxed.
yes the behavior is like this
root non-root before about half of ram nothing after all of ram by default small, increasable
> Such changes in behavior aren't adequate for 2.6.X, there are way too > many applications that can't be bothered to check the patchlevel of the > kernel, and it's totally unintuitive to users, too.
there is NO fundamental change here other than a *general* relaxing. This is important to note: Apps that could mlock before STILL can mlock. Only apps that would depend on mlock failing with a security check, and only those who do small portions, break now because suddenly the mlock succeeds. Big deal... those would have broken when run as root already
> No, I'm not doing that. I rather wonder why it's so low, or whom a certain > percentage such as RAM >> 5 (that's 3.125 %) would hurt. A
because it's generally a PER PROCESS limit, so fork 60 times and kaboom things explode. (You can argue you can forkbomb anyway, but that's where the process count rlimit comes in)
> Allowing > unlimited memory allocation while at the same time allowing only 32 kB > of mlock()ed memory seems disproportionate to me.
it's not. Normal memory is swapable. And thus a far less rare commodity than precious pinned down memory.
What application do you have in mind that broke by this relaxing of rules?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |