[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120712115708.GG21013@tiehlicka.suse.cz>
Date: Thu, 12 Jul 2012 13:57:08 +0200
From: Michal Hocko <mhocko@...e.cz>
To: Will Deacon <will.deacon@....com>
Cc: Hugh Dickins <hughd@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Hillf Danton <dhillf@...il.com>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH] mm: hugetlb: flush dcache before returning zeroed huge
page to userspace
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists