Re: /proc/$pid/pagemap troubles

[Dave Hansen <haveblue@us.ibm.com>]

On Tue, 2007-07-31 at 19:14 -0500, Matt Mackall wrote:
> On Tue, Jul 31, 2007 at 03:43:10PM -0700, Dave Hansen wrote:
> > +       evpfn = min((src + count) / sizeof(unsigned long),
> > +                   ((~0UL) >> PAGE_SHIFT) + 1);
> > 
> > Should that hunk of code be any different for 32-bit processes on a
> > 64-bit kernel?  Do we want to use TASK_SIZE_OF() or restrict these to
> > actual virtual address space (which is only 48 bits on x86_64).
> 
> No. A page for a 32-bit task can line anywhere in the >32-bit physical
> address space.

An evpfn is an ending _virtual_ pfn right?  A virtual pfn is a vaddr >>
PAGE_SHIFT, right?  We're not calculating anything having to do with
physical addresses.  Having 64-bit physical addresses would be a reason
to use 64-bits as the entry size, but not to round down this "evpfn".

"src" in this case is "*ppos", which is the offset into the file.
Divide that by the entry size (sizeof(unsigned long)) and you get the
number of pages offset into the vaddr space that the user is attempting
to read.  There might be a bug here with it forgetting to offset the
header size, but oh well.

In any case, what _is_ the ((~0UL) >> PAGE_SHIFT)  operation there for?
Is it to make sure that a user reading at the end of the virtual address
space doesn't ask to read 10 pages starting at 0xfffffff0?

> Most of those go away with the get_user_pages approach.

Are you working on this actively?  If not, I'd be happy to take whatever
you have and fix it up.  Care to post it, even in a slightly unpolished
state?

-- Dave

-
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/