Messages in this thread Patch in this message | | | Date | Tue, 16 Nov 2004 18:33:52 +0100 | From | Andrea Arcangeli <> | Subject | mlock hanging on non-ram with VM_IO set |
| |
I've got a report of mlock deadlocking on non-ram mappings (precisely on a mmap of /dev/mem outside the mem_map array range)
I believe this should fix it (I verified the mlock is the only one passing down pages == NULL, and infact mlock is the only one hanging on VM_IO vmas since the pfn isn't valid and handle_mm_fault sure can't istantiate a valid pfn there since the ptes are filled synchronously at mmap time), comments? (I don't see any reason why mlock should be allowed to trigger page faults on VM_IO regions)
This is not a bad bug, mlock is privilegied, and /dev/mem is privilegied too, and mlock makes no sense on a non-ram mappings (noop), but I guess it's ok to add it mostly for things like mlockall that would otherwise deadlock the box and I guess it's nicer if they work transparently, no matter what mappings are in the task.
btw, mlock traps the error and ignores it as it should.
this is untested but I guess it should fix it (and it applied cleanly to kernel CVS).
Signed-off-by: Andrea Arcangeli <andrea@novell.com>
--- sles/mm/memory.c.~1~ 2004-11-12 12:30:25.000000000 +0100 +++ sles/mm/memory.c 2004-11-16 17:58:02.752131952 +0100 @@ -753,7 +753,7 @@ int get_user_pages(struct task_struct *t continue; } - if (!vma || (pages && (vma->vm_flags & VM_IO)) + if (!vma || (vma->vm_flags & VM_IO) || !(flags & vma->vm_flags)) return i ? : -EFAULT; - 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/
| |