lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ