mlockall and mmap of IO devices don't mix

2.6.0-test6: the use of mlockall(2) in a process that has mmap(2)ed the registers of an IO device will hang that process uninterruptibly. The task runs in an infinite loop in get_user_pages(), invoking follow_page() forever.

Quoted 5 lines · Joe Korty

2.6.0-test6: the use of mlockall(2) in a process that has mmap(2)ed the registers of an IO device will hang that process uninterruptibly. The task runs in an infinite loop in get_user_pages(), invoking follow_page() forever.

whoops.

I think the right fix is in get_user_pages(): if the region is VM_IO then don't call follow_page() at all.

Something like this?

Quoted 2 lines

Something like this?

Sigh. No go; it *looks* good but my app still locks up....

Oh crap, you're mapping /dev/mem rather than going through a device driver. /dev/mem isn't setting VM_IO.

Sigh. No go; it *looks* good but my app still locks up....

Quoted 1 line

Sigh. No go; it *looks* good but my app still locks up....

Or we could use that VM_RESERVED thing?

Your third patch worked perfectly for all the tested cases:
o /dev/mem at offset fd000000 (my video card mem addr)
o /dev/mem at offset 0
o with an mmapable device driver.

I did have to make two changes to get it to compile:

memory.c renamed from memory.c.am3 +2 -2

@@ -738,7 +738,7 @@
 #endif
 
 		special = vma->vm_flags & (VM_IO | VM_RESERVED);
-		if (!vma || (pages && vm_io) || !(flags & vma->vm_flags))
+		if (!vma || (pages && special) || !(flags & vma->vm_flags))
 			return i ? : -EFAULT;
 
 		if (is_vm_hugetlb_page(vma)) {

@@ -755,7 +755,7 @@
 			 * mappings of /dev/mem - they may have no pageframes.
 			 * And the caller passed NULL for `pages' anyway.
 			 */
-			while (!special && !(map=follow_page(mm,start,write)) {
+			while (!special && !(map=follow_page(mm,start,write))) {
 				spin_unlock(&mm->page_table_lock);
 				switch (handle_mm_fault(mm,vma,start,write)) {
 				case VM_FAULT_MINOR:

In the first change, 'special' != '(vma->vma_flags & VM_IO)' which was what was originally being tested. Could that cause a problem?

Also, could the use of VM_RESERVED cause in some cases memory with pageframes to skip adjustment/use of those pageframes?

Maybe it's best to not overload VM_RESERVED in this manner, but to always mark /dev/mem as VM_IO.

On Fri, 3 Oct 2003 17:27:27 -0700

Quoted 2 lines · Andrew Morton

Maybe it's best to not overload VM_RESERVED in this manner, but to always mark /dev/mem as VM_IO.

Just in cast is isn't clear, it should be defined that anything that sets VM_IO on an mmap() area should prefill the page tables as a side effect of such a mmap() request.

Then things like mlockall() have simple semantics on VM_IO area, they end up being a nop.

2.6.0-test6: the use of mlockall(2) in a process that has mmap(2)ed the registers of an IO device will hang that process uninterruptibly. The task runs in an infinite loop in get_user_pages(), invoking follow_page() forever.

Using binary search I discovered that the problem was introduced in 2.5.14, specifically in ChangeSetKey

    [email protected]|ChangeSet|20020503210330|37095

Quoted 6 lines · Joe Korty

2.6.0-test6: the use of mlockall(2) in a process that has mmap(2)ed the registers of an IO device will hang that process uninterruptibly. The task runs in an infinite loop in get_user_pages(), invoking follow_page() forever.

Quoted 5 lines

Using binary search I discovered that the problem was introduced in 2.5.14, specifically in ChangeSetKey

    [email protected]|ChangeSet|20020503210330|37095

I know this is an old thread but can anyone tell me if this problem is resolved in the current 2.6.6 kernel?

Quoted 14 lines · Mark Hounschell

Quoted 11 lines · Joe Korty

2.6.0-test6: the use of mlockall(2) in a process that has mmap(2)ed the registers of an IO device will hang that process uninterruptibly. The task runs in an infinite loop in get_user_pages(), invoking follow_page() forever.

Using binary search I discovered that the problem was introduced in 2.5.14, specifically in ChangeSetKey

    [email protected]|ChangeSet|20020503210330|37095

Quoted 3 lines

I know this is an old thread but can anyone tell me if this problem is resolved in the current 2.6.6 kernel?

There's an utterly ancient patch in -mm which might fix this.

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm4/broken-out/get_user_pages-handle-VM_IO.patch

Quoted 20 lines · Andrew Morton

Quoted 17 lines · Mark Hounschell

Quoted 11 lines · Joe Korty

2.6.0-test6: the use of mlockall(2) in a process that has mmap(2)ed the registers of an IO device will hang that process uninterruptibly. The task runs in an infinite loop in get_user_pages(), invoking follow_page() forever.

Using binary search I discovered that the problem was introduced in 2.5.14, specifically in ChangeSetKey

    [email protected]|ChangeSet|20020503210330|37095

I know this is an old thread but can anyone tell me if this problem is resolved in the current 2.6.6 kernel?

Quoted 3 lines

There's an utterly ancient patch in -mm which might fix this.

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm4/broken-out/get_user_pages-handle-VM_IO.patch

Thanks for that. I'll try it.

Mark

Quoted 14 lines · Mark Hounschell

Quoted 11 lines · Joe Korty

2.6.0-test6: the use of mlockall(2) in a process that has mmap(2)ed the registers of an IO device will hang that process uninterruptibly. The task runs in an infinite loop in get_user_pages(), invoking follow_page() forever.

Using binary search I discovered that the problem was introduced in 2.5.14, specifically in ChangeSetKey

    [email protected]|ChangeSet|20020503210330|37095

Quoted 3 lines

I know this is an old thread but can anyone tell me if this problem is resolved in the current 2.6.6 kernel?

There's an utterly ancient patch in -mm which might fix this.

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm4/broken-out/get_user_pages-handle-VM_IO.patch

Quoted 21 lines · Andrew Morton

Quoted 8 lines · Mark Hounschell

Quoted 6 lines · Joe Korty

2.6.0-test6: the use of mlockall(2) in a process that has mmap(2)ed the registers of an IO device will hang that process uninterruptibly. The task runs in an infinite loop in get_user_pages(), invoking follow_page() forever.

Quoted 9 lines

Quoted 5 lines

Using binary search I discovered that the problem was introduced in 2.5.14, specifically in ChangeSetKey

    [email protected]|ChangeSet|20020503210330|37095

I know this is an old thread but can anyone tell me if this problem is resolved in the current 2.6.6 kernel?

There's an utterly ancient patch in -mm which might fix this.

Quoted 1 line

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm4/broken-out/get_user_pages-handle-VM_IO.patch

[ 2nd send -- corporate email system in the throes of being scrambled / updated ]

Andrew,
I have been using this patch for ages. Any chance of it being forwared to the official tree?

Quoted 9 lines

Quoted 9 lines

Quoted 7 lines

Quoted 4 lines

2.6.0-test6: the use of mlockall(2) in a process that has mmap(2)ed the registers of an IO device will hang that process uninterruptibly. The task runs in an infinite loop in get_user_pages(), invoking follow_page() forever.

I know this is an old thread but can anyone tell me if this problem is resolved in the current 2.6.6 kernel?

There's an utterly ancient patch in -mm which might fix this.

That patch had its first birthday last week. I wrote it in response to some long-forgotten problem, failed to changelog it at the time then forgot why I wrote it. I kept it in the hope that I'd remember why I wrote it. I subsequently wrote a best-effort changelog but am unconvinced by it. Ho hum.

Let me genuflect a bit. I guess we can be reasonably confident it won't break anything.

Quoted 23 lines · Joe Korty

Quoted 21 lines · Andrew Morton

Quoted 8 lines · Mark Hounschell

Quoted 6 lines · Joe Korty

2.6.0-test6: the use of mlockall(2) in a process that has mmap(2)ed the registers of an IO device will hang that process uninterruptibly. The task runs in an infinite loop in get_user_pages(), invoking follow_page() forever.

Quoted 9 lines

Quoted 5 lines

Using binary search I discovered that the problem was introduced in 2.5.14, specifically in ChangeSetKey

    [email protected]|ChangeSet|20020503210330|37095

I know this is an old thread but can anyone tell me if this problem is resolved in the current 2.6.6 kernel?

There's an utterly ancient patch in -mm which might fix this.

Quoted 7 lines

Quoted 1 line

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6/2.6.6-mm4/broken-out/get_user_pages-handle-VM_IO.patch

[ 2nd send -- corporate email system in the throes of being scrambled / updated ]

Andrew,
I have been using this patch for ages. Any chance of it being forwared to the official tree?

That patch had its first birthday last week. I wrote it in response to some long-forgotten problem, failed to changelog it at the time then forgot why I wrote it. I kept it in the hope that I'd remember why I wrote it. I subsequently wrote a best-effort changelog but am unconvinced by it. Ho hum.

Let me genuflect a bit. I guess we can be reasonably confident it won't break anything.