Messages in this thread | | | From | Joerg Schilling <> | Date | Tue, 24 Jan 2006 10:08:50 +0100 | Subject | Re: Rationale for RLIMIT_MEMLOCK? |
| |
Arjan van de Ven <arjan@infradead.org> wrote:
> > 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
I concur:
Locking pages into core is a property/duty of the VM subsystem. If you have an orthogonal VM subsystem, you cannot later tell how a page was mapped into the user's address space. Even more: you may map a file to a alocation in the data segment of the proces (that has been retrieved via malloc()/brk()) and replace the related mapping with a mapped file.
On Solaris, there is no difference.
> > > 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 :(
As all other rlimits are honored even if you are root, it looks not orthogonal to disregard an existing RLIMIT_MEMLOCK rlimit if you are root.
Jörg
-- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - 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/
| |