lkml.org 
[lkml]   [2004]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: loops in get_user_pages() for VM_IO
On Tue, 16 Nov 2004 22:33:38 -0800
Andrew Morton <akpm@osdl.org> wrote:

> --- 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;
>
> which should fix up the sbuslib.c problem.

It would only becuase do_mmap_pgoff() doesn't check
the return value of make_pages_present().

> Or, better, simply advance over the VM_IO vma and onto the next one?

That would work too.

Although currently in my sparc64 tree I'm setting VM_RESERVED instead
of VM_LOCKED for I/O mappings and that solves the issue as well. It
would not, of course, solve the mlock() case you mentioned.

I think we need to set these bits consistently across the tree.
And remap_pfn_range() is a good model, so that's what I've used.
Parts of the x86 tree trigger this case too btw, for example
the pci mmap support code. In fact, all the pci mmap support
routines set VM_LOCKED, probably because they were copied over
from the first two implementations (sparc64 and i386) :-)
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.078 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site