linux-kernel - Re: [PATCH 1/5] hugetlb: prep_compound_gigantic_page(): drop _

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:	Tue, 8 Apr 2014 16:25:39 -0400
From:	Luiz Capitulino <lcapitulino@...hat.com>
To:	Naoya Horiguchi <n-horiguchi@...jp.nec.com>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	mtosatti@...hat.com, aarcange@...hat.com, mgorman@...e.de,
	akpm@...ux-foundation.org, andi@...stfloor.org, davidlohr@...com,
	rientjes@...gle.com, isimatu.yasuaki@...fujitsu.com,
	yinghai@...nel.org, riel@...hat.com
Subject: Re: [PATCH 1/5] hugetlb: prep_compound_gigantic_page(): drop __init
 marker

On Tue, 08 Apr 2014 15:51:51 -0400
Naoya Horiguchi <n-horiguchi@...jp.nec.com> wrote:

> Hi Luiz,
> 
> On Tue, Apr 08, 2014 at 03:02:16PM -0400, Luiz Capitulino wrote:
> > This function is going to be used by non-init code in a future
> > commit.
> > 
> > Signed-off-by: Luiz Capitulino <lcapitulino@...hat.com>
> > ---
> >  mm/hugetlb.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > index 7c02b9d..319db28 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -689,8 +689,7 @@ static void prep_new_huge_page(struct hstate *h, struct page *page, int nid)
> >  	put_page(page); /* free it into the hugepage allocator */
> >  }
> >  
> > -static void __init prep_compound_gigantic_page(struct page *page,
> > -					       unsigned long order)
> > +static void prep_compound_gigantic_page(struct page *page, unsigned long order)
> >  {
> >  	int i;
> >  	int nr_pages = 1 << order;
> 
> Is __ClearPageReserved() in this function relevant only in boot time
> allocation? 

Yes.

> If yes, it might be good to avoid calling it in runtime
> allocation.

The problem is that prep_compound_gigantic_page() is good and used by
both boottime and runtime allocations. Having two functions to do the
same thing seems like overkill, especially because the runtime allocation
code skips reserved pages. So the reserved bit should always be cleared
for runtime allocated gigantic pages.
--
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/