lkml.org 
[lkml]   [2003]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: mlockall and mmap of IO devices don't mix
On Sat, Oct 04, 2003 at 12:02:08PM +0200, Ingo Oeser wrote:
> On Saturday 04 October 2003 11:22, you wrote:
> > On Sat, Oct 04, 2003 at 11:17:03AM +0200, Andi Kleen wrote:
> > > > This check is only done, if it is a valid pfn (pfn_valid()) of a
> > > > present pte.
> > >
> > > pfn_valid is useless, it doesn't handle all IO holes on x86 for examples.
> >
> > Sounds like pfn_valid() is buggy on x86. It's supposed to definitively
> > indicate whether the PFN is a valid page of ram (and has a valid struct
> > page entry.) If it doesn't do that, the architecture implementation is
> > wrong.
>
> Looks like it. But it also has to be fast (see include/asm-i386/mmzone.h)
> and doesn't even hide the holes in NUMA machines.

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.)

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.

--
Russell King (rmk@arm.linux.org.uk) http://www.arm.linux.org.uk/personal/
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
-
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 13:49    [W:0.056 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site