Gleb Natapov [off-list ref] writes:

On Thu, Oct 08, 2009 at 05:10:35PM +0800, WANG Cong wrote:

quoted

Gleb Natapov [off-list ref] writes:

quoted

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 <redacted>

<snip>

quoted

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>