Messages in this thread | | | Subject | Re: Rationale for RLIMIT_MEMLOCK? | From | Arjan van de Ven <> | Date | Tue, 24 Jan 2006 09:52:41 +0100 |
| |
> c() was the function in question. > > Jörg, if we're talking about valloc(), this hasn't much to do with the > kernel, but is a library issue. > > There is _no_ documentation that says valloc() or memalign() or > posix_memalign() is required to use mmap(). It works on some systems and > for some allocation sizes as a side effect of the valloc() > implementation.
it doesn't matter. Regardless of the method, the memory has to be locked due to the FUTURE requirement.
> And because this requirement is not specified in the relevant standards, > it is wrong to assume valloc() returns locked pages.
is it? I sort of doubt that (but I'm not a standards expert, but I'd expect that "lock all in the future" applies to all memory, not just mmap'd memory
> You cannot rely on > mmap() returning locked pages after mlockall() either, because you might > be exceeding resource limits.
this is true and fully correct
the situation is messy; I can see some value in the hack Ted proposed to just bump the rlimit automatically at an mlockall-done-by-root.. but to be fair it's a hack :(
- 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/
| |