All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Oeser <ioe-lkml@rameria.de>
To: Russell King <rmk@arm.linux.org.uk>
Cc: Andi Kleen <ak@muc.de>, Andrew Morton <akpm@osdl.org>,
	Joe Korty <joe.korty@ccur.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: mlockall and mmap of IO devices don't mix
Date: Sat, 4 Oct 2003 16:19:49 +0200	[thread overview]
Message-ID: <200310041619.49392.ioe-lkml@rameria.de> (raw)
In-Reply-To: <20031004111336.C18928@flint.arm.linux.org.uk>

Hi there,

CC'ed linux-mm and Andrew Morton for expertise.

On Saturday 04 October 2003 12:13, Russell King wrote:
> It has to be correct.  We do the following in a hell of a lot of places:
>
> 	pfn = pte_pfn(pte);
> 	if (pfn_valid(pfn)) {
> 		struct page *page = pfn_to_page(pfn);
> 		/* do something with page */
> 	}
>
> basically this type of thing happens in any of the PTE manipulation
> functions (eg, copy_page_range, zap_pte_range, etc.)

These functions are called always with pages, where we know, that this
is RAM, AFICS. Since sometimes other things are encoded in the PTE, whe
check this via pfn_valid().

If I'm wrong about this the gurus from LINUX-MM should complain loudly.

> If pfn_valid is returning false positives, and you happen to mmap() an
> area which gives false positives from a user space application, your
> kernel will either oops or will corrupt RAM when that application exits.
>
> I believe the comment in mmzone.h therefore is an opinion, and indicates
> a concern for performance rather than correctness and stability.

I hope you are wrong about this, but I'm not totally sure. So I included
the linux-mm mailing list and Andrew Morton for expert advice.

Regards

Ingo Oeser



WARNING: multiple messages have this Message-ID (diff)
From: Ingo Oeser <ioe-lkml@rameria.de>
To: Russell King <rmk@arm.linux.org.uk>
Cc: Andi Kleen <ak@muc.de>, Andrew Morton <akpm@osdl.org>,
	Joe Korty <joe.korty@ccur.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: mlockall and mmap of IO devices don't mix
Date: Sat, 4 Oct 2003 16:19:49 +0200	[thread overview]
Message-ID: <200310041619.49392.ioe-lkml@rameria.de> (raw)
In-Reply-To: <20031004111336.C18928@flint.arm.linux.org.uk>

Hi there,

CC'ed linux-mm and Andrew Morton for expertise.

On Saturday 04 October 2003 12:13, Russell King wrote:
> It has to be correct.  We do the following in a hell of a lot of places:
>
> 	pfn = pte_pfn(pte);
> 	if (pfn_valid(pfn)) {
> 		struct page *page = pfn_to_page(pfn);
> 		/* do something with page */
> 	}
>
> basically this type of thing happens in any of the PTE manipulation
> functions (eg, copy_page_range, zap_pte_range, etc.)

These functions are called always with pages, where we know, that this
is RAM, AFICS. Since sometimes other things are encoded in the PTE, whe
check this via pfn_valid().

If I'm wrong about this the gurus from LINUX-MM should complain loudly.

> If pfn_valid is returning false positives, and you happen to mmap() an
> area which gives false positives from a user space application, your
> kernel will either oops or will corrupt RAM when that application exits.
>
> I believe the comment in mmzone.h therefore is an opinion, and indicates
> a concern for performance rather than correctness and stability.

I hope you are wrong about this, but I'm not totally sure. So I included
the linux-mm mailing list and Andrew Morton for expert advice.

Regards

Ingo Oeser


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

  reply	other threads:[~2003-10-04 14:22 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CFYv.787.23@gated-at.bofh.it>
2003-10-04  7:02 ` mlockall and mmap of IO devices don't mix 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 [this message]
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=200310041619.49392.ioe-lkml@rameria.de \
    --to=ioe-lkml@rameria.de \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=joe.korty@ccur.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rmk@arm.linux.org.uk \
    /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.