From: Ingo Oeser <ioe-lists@rameria.de>
To: "David S. Miller" <davem@redhat.com>
Cc: joe.korty@ccur.com, linux-kernel@vger.kernel.org,
riel@redhat.com, andrea@suse.de, Andrew Morton <akpm@osdl.org>
Subject: Re: mlockall and mmap of IO devices don't mix
Date: Sat, 4 Oct 2003 11:29:25 +0200 [thread overview]
Message-ID: <200310041129.25813.ioe-lists@rameria.de> (raw)
In-Reply-To: <20031003224727.2f6956b5.davem@redhat.com>
On Saturday 04 October 2003 07:47, David S. Miller wrote:
> On Fri, 3 Oct 2003 17:27:27 -0700
>
> Andrew Morton <akpm@osdl.org> wrote:
> > 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.
It should be already, but the check in get_user_pages() looks wrong and
will only disallow VM_IO if you provide space for an page array.
It should be unconditional and we are done, because follow_pages will
never be called with such vmas.
Putting this check for "forbidden VMAs" into follow_pages is also a good
decision, if follow_pages() is called by strange callers not knowing the
limitations. kernel/futex.c is such an user, which don't check these in
the fast path (does it like wait on hardware triggered futexes there?).
It might be good to add VM_RESERVED check to get_user_pages(), too.
These pages are available anyway, so never need to be considered from
its users.
Regards
Ingo Oeser
next prev parent reply other threads:[~2003-10-04 9:32 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-03 21:44 mlockall and mmap of IO devices don't mix Joe Korty
2003-10-03 22:23 ` Andrew Morton
2003-10-03 22:55 ` Joe Korty
2003-10-03 23:06 ` Andrew Morton
2003-10-03 23:28 ` Joe Korty
2003-10-03 23:15 ` Andrew Morton
2003-10-03 23:54 ` Joe Korty
2003-10-04 0:27 ` Andrew Morton
2003-10-04 5:47 ` David S. Miller
2003-10-04 9:29 ` Ingo Oeser [this message]
2004-05-21 11:34 ` Mark Hounschell
2004-05-22 2:13 ` Andrew Morton
2004-05-22 10:47 ` Mark Hounschell
2004-05-23 12:58 ` Mark Hounschell
2004-05-25 14:27 ` Joe Korty
2004-05-25 19:47 ` Andrew Morton
2004-05-25 21:31 ` Joe Korty
2004-07-16 21:01 ` Mark Hounschell
[not found] <CFYv.787.23@gated-at.bofh.it>
2003-10-04 7:02 ` Andi Kleen
2003-10-04 7:42 ` Andrew Morton
2003-10-04 8:29 ` Andi Kleen
2003-10-04 8:47 ` Ingo Oeser
2003-10-04 9:17 ` Andi Kleen
2003-10-04 9:22 ` Russell King
2003-10-04 10:02 ` Ingo Oeser
2003-10-04 10:13 ` Russell King
2003-10-04 14:19 ` Ingo Oeser
2003-10-04 14:19 ` Ingo Oeser
2003-10-04 14:32 ` Martin J. Bligh
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=200310041129.25813.ioe-lists@rameria.de \
--to=ioe-lists@rameria.de \
--cc=akpm@osdl.org \
--cc=andrea@suse.de \
--cc=davem@redhat.com \
--cc=joe.korty@ccur.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.