LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Ingo Oeser <ioe-lkml@rameria.de>
To: Andi Kleen <ak@muc.de>, Joe Korty <joe.korty@ccur.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: mlockall and mmap of IO devices don't mix
Date: Sat, 4 Oct 2003 10:47:56 +0200	[thread overview]
Message-ID: <200310041047.56705.ioe-lkml@rameria.de> (raw)
In-Reply-To: <m34qyp7ae4.fsf@averell.firstfloor.org>

Hi,

On Saturday 04 October 2003 09:02, Andi Kleen wrote:
> Joe Korty <joe.korty@ccur.com> writes:
> > I do not believe that the above constitutes a correct fix.  The
> > problem is that follow_pages() is fundamentally not able to handle a
> > mapping which does not have a 'struct page' backing it up, and a
> > mapping to IO memory by definition has no 'struct page' structure to
> > back it up.
>
> The 2.4 vm scanner handles this by always checking VALID_PAGE().
>
> Maybe follow_pages() should do that too?

It does already. 

Just see the most indented check there. It tries to find a struct page from the
page frame number (pfn_to_page) after obtaining the  pfn from the pte.

This check is only done, if it is a valid pfn (pfn_valid()) of a present
pte.

Since make_pages_present uses get_user_pages(), which in turn calls
follow_pages() with the above checks, this is properly checked.

The only path where is is NOT checked, is hugetlb stuff. So the error must be
there.

If somebody does the changes, please remove the useless get_page_map(), since
it just does the above checks done already again after a reverse lookup and I
could not find ANY case, where the check in get_page_map() would fail. 

So maybe a BUG_ON() the checks in get_page_map() and a LTP run combinded with
bttv usage afterwards would be good.

Regards

Ingo Oeser



  parent reply	other threads:[~2003-10-04  8:50 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
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:32           ` Martin J. Bligh
2003-10-03 21:44 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
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

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=200310041047.56705.ioe-lkml@rameria.de \
    --to=ioe-lkml@rameria.de \
    --cc=ak@muc.de \
    --cc=joe.korty@ccur.com \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: mlockall and mmap of IO devices don'\''t mix' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).