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  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:   Tue, 10 Aug 2021 11:29:11 +0200
From:   Oscar Salvador <>
To:     Mike Kravetz <>
        Muchun Song <>,
        Michal Hocko <>,
        David Hildenbrand <>,
        Matthew Wilcox <>,
        Naoya Horiguchi <>,
        Mina Almasry <>,
        Andrew Morton <>
Subject: Re: [PATCH v2 1/3] hugetlb: simplify prep_compound_gigantic_page ref
 count racing code

On 2021-08-09 20:48, Mike Kravetz wrote:
> Code in prep_compound_gigantic_page waits for a rcu grace period if it
> notices a temporarily inflated ref count on a tail page.  This was due
> to the identified potential race with speculative page cache references
> which could only last for a rcu grace period.  This is overly 
> complicated
> as this situation is VERY unlikely to ever happen.  Instead, just 
> quickly
> return an error.
> Also, only print a warning in prep_compound_gigantic_page instead of
> multiple callers.

The above makes sense to me.
My only question would be: gather_bootmem_prealloc() is an __init 
Can we have speculative refcounts due to e.g: pagecache at that early 
I think we cannot, but I am not really sure.

We might be able to remove that else() in case we cannot have such 

Oscar Salvador

Powered by blists - more mailing lists