From: "David S. Miller" <davem@davemloft.net>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, andrea@novell.com
Subject: Re: loops in get_user_pages() for VM_IO
Date: Tue, 16 Nov 2004 22:26:11 -0800 [thread overview]
Message-ID: <20041116222611.1f59854a.davem@davemloft.net> (raw)
In-Reply-To: <20041116223338.08bb6701.akpm@osdl.org>
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) :-)
next prev parent reply other threads:[~2004-11-17 6:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-17 1:53 loops in get_user_pages() for VM_IO David S. Miller
2004-11-17 2:07 ` David S. Miller
2004-11-17 6:33 ` Andrew Morton
2004-11-17 6:26 ` David S. Miller [this message]
2004-11-17 13:44 ` Andrea Arcangeli
2004-11-17 16:40 ` Andrea Arcangeli
2004-11-17 19:37 ` Hugh Dickins
2004-11-18 19:52 ` [PATCH] " Hugh Dickins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041116222611.1f59854a.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=akpm@osdl.org \
--cc=andrea@novell.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox