RE: [RFC V2] mm:change smaps/pagemap_read calculation behavior

[Wang, Yalin]

> -----Original Message-----
> From: Naoya Horiguchi [mailto:n-horiguchi@xxxxxxxxxxxxx]
> Sent: Friday, January 30, 2015 4:24 PM
> To: Wang, Yalin
> Cc: 'akpm@xxxxxxxxxxxxxxxxxxxx'; 'kirill.shutemov@xxxxxxxxxxxxxxx';
> 'oleg@xxxxxxxxxx'; 'gorcunov@xxxxxxxxxx'; 'pfeiner@xxxxxxxxxx';
> 'aquini@xxxxxxxxxx'; 'linux-kernel@xxxxxxxxxxxxxxx'
> Subject: Re: [RFC V2] mm:change smaps/pagemap_read calculation behavior
> 
> On Fri, Jan 30, 2015 at 03:47:54PM +0800, Wang, Yalin wrote:
> > This patch change smaps/pagemap_read pagetable walk behavior, to make
> > sure not skip VM_PFNMAP pagetables,
> > so that we can calculate COW pages of VM_PFNMAP as normal pages.
> >
> > Signed-off-by: Yalin Wang <yalin.wang@xxxxxxxxxxxxxx>
> 
> Hi Yalin,
> 
> The original motivation of the VM_PFNMAP code in pagewalk.c comes from the
> following patch:
> 
>   commit a9ff785e4437c83d2179161e012f5bdfbd6381f0
>   Author: Cliff Wickman <cpw@xxxxxxx>
>   Date:   Fri May 24 15:55:36 2013 -0700
> 
>       mm/pagewalk.c: walk_page_range should avoid VM_PFNMAP areas
> 
> , where Cliff stated that some kind of vma(VM_PFNMAP) caused kernel panic
> when walk_page_range() was called over it. So I don't think that re-
> enabling
> to walk over every vma(VM_PFNMAP) unexceptionally is a good idea.
> 
> If you really want to get some information from a vma(VM_PFNMAP) via these
> interfaces, I recommend you to implement proper judging code which returns
> 0 for your vma(VM_PFNMAP) and returns 1 for Cliff's vma(VM_PFNMAP).
> 
I see, but I am curious that why kernel panic when I just
access process pagetables in page_table_walk()?
Is it caused by hardware problem?

The reason that I want to enable it is to see some drivers map some COW pages 
With VM_PFNMAP, so that user space can get correct page allocation info for 
These COW special pages with VM_PFNMAP flag.

Thanks 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/