Gleb Natapov <[email protected]> writes: > On Thu, Oct 08, 2009 at 05:10:35PM +0800, WANG Cong wrote: >> Gleb Natapov <[email protected]> writes: >> >> > If application does mlockall(MCL_FUTURE) it is no longer possible to >> > mmap file bigger than main memory or allocate big area of anonymous >> > memory. Sometimes it is desirable to lock everything related to program >> > execution into memory, but still be able to mmap big file or allocate >> > huge amount of memory and allow OS to swap them on demand. MAP_UNLOCKED >> > allows to do that. >> > >> > Signed-off-by: Gleb Natapov <[email protected]> >> >> <snip> >> >> > diff --git a/mm/mmap.c b/mm/mmap.c >> > index 73f5e4b..ecc4471 100644 >> > --- a/mm/mmap.c >> > +++ b/mm/mmap.c >> > @@ -985,6 +985,9 @@ unsigned long do_mmap_pgoff(struct file *file, >> > unsigned long addr, >> > if (!can_do_mlock()) >> > return -EPERM; >> > >> > + if (flags & MAP_UNLOCKED) >> > + vm_flags &= ~VM_LOCKED; >> > + >> > /* mlock MCL_FUTURE? */ >> > if (vm_flags & VM_LOCKED) { >> > unsigned long locked, lock_limit; >> >> So, if I read it correctly, it is perfectly legal to set >> both MAP_LOCKED and MAP_UNLOCKED at the same time? While >> the behavior is still same as only setting MAP_UNLOCKED. >> >> Is this what we expect? >> > This is what code does currently. Should we return EINVAL in this case? >
I suppose to get an EINVAL. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
