Re: [PATCH] mm: hugetlb: flush dcache before returning zeroed hugepage to userspace

[Michal Hocko]

On Thu 12-07-12 12:26:45, Will Deacon wrote:
> On Thu, Jul 12, 2012 at 12:16:59PM +0100, Michal Hocko wrote:
> > On Wed 11-07-12 18:48:02, Will Deacon wrote:
> > > Just to confirm, the following quick hack at least results in the correct
> > > flushing for me (on ARM):
> > > 
> > > 
> > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > > index e198831..7a7c9d3 100644
> > > --- a/mm/hugetlb.c
> > > +++ b/mm/hugetlb.c
> > > @@ -1141,6 +1141,7 @@ static struct page *alloc_huge_page(struct vm_area_struct *vma,
> > >         }
> > >  
> > >         set_page_private(page, (unsigned long)spool);
> > > +       clear_bit(PG_arch_1, &page->flags);
> > >  
> > >         vma_commit_reservation(h, vma, addr);
> > >  
> > > 
> > > 
> > > The question is whether we should tidy that up for the core code or get
> > > architectures to clear the bit in arch_make_huge_pte (which also seems to
> > > work).
> > 
> > This should go into arch specific code IMO. Even the page flag name
> > suggests this shouldn't be in the base code.
> 
> Well, the comment in linux/page-flags.h does state that:
> 
>  * PG_arch_1 is an architecture specific page state bit.  The generic code
>  * guarantees that this bit is cleared for a page when it first is entered into
>  * the page cache.
> 
> so it's not completely clear cut that the architecture should be responsible
> for clearing this bit when allocating pages from the hugepage pool.

I think the wording is quite clear. It guarantees it gets cleared not
clears it. So it is up to an arch specific functions called from the
generic code to do that.

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic
--
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/