linux-kernel - Re: [PATCH 2/3] mm, page_poison: use static key more efficiently

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] [day] [month] [year] [list]

Date:   Wed, 11 Nov 2020 13:29:11 +0000
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Vlastimil Babka <vbabka@...e.cz>
Cc:     Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org,
        Alexander Potapenko <glider@...gle.com>,
        Kees Cook <keescook@...omium.org>,
        Michal Hocko <mhocko@...nel.org>,
        David Hildenbrand <david@...hat.com>,
        Mateusz Nosek <mateusznosek0@...il.com>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH 2/3] mm, page_poison: use static key more efficiently

On Fri, Oct 30, 2020 at 11:56:48PM +0100, Vlastimil Babka wrote:
> On 10/30/20 5:27 PM, Luis Chamberlain wrote:
> > On Mon, Oct 26, 2020 at 06:33:57PM +0100, Vlastimil Babka wrote:
> > > Commit 11c9c7edae06 ("mm/page_poison.c: replace bool variable with static key")
> > > changed page_poisoning_enabled() to a static key check. However, the function
> > > is not inlined, so each check still involves a function call with overhead not
> > > eliminated when page poisoning is disabled.
> > > 
> > > Analogically to how debug_pagealloc is handled, this patch converts
> > > page_poisoning_enabled() back to boolean check, and introduces
> > > page_poisoning_enabled_static() for fast paths. Both functions are inlined.
> > > 
> > > Also optimize the check that enables page poisoning instead of debug_pagealloc
> > > for architectures without proper debug_pagealloc support. Move the check to
> > > init_mem_debugging() to enable a single static key instead of having two
> > > static branches in page_poisoning_enabled_static().
> > > 
> > > Signed-off-by: Vlastimil Babka <vbabka@...e.cz>
> > 
> > <sad trombone>
> > 
> > This patchset causes a regression x86_64 as a guest. I was able
> > to bisect this on the following linux-next tags:
> > 
> > next-20201015 OK
> > next-20201023 OK
> > next-20201026 OK
> > next-20201027 BAD
> > next-20201028 BAD
> > 
> > Bisection inside next-20201027 lands me on:
> > 
> > "mm, page_alloc: do not rely on the order of page_poison and init_on_alloc/free parameters"
> 
> CC peterz.
> 
> I wonder if it's because I converted some static keys to _RO
> DEFINE_STATIC_KEY_FALSE_RO(init_on_alloc);.
> ...
> DEFINE_STATIC_KEY_FALSE_RO(init_on_free);

This was along the lines of what I suspected but I didn't have time
to provide an alternative.

> I thought it was ok since we only enable them during init. But maybe it's
> incompatible with use by modules? Not that I immediately see how
> drm_kms_helper(E+) uses them.

I can reproduce easily so happy to test alterantive patchsets!

> Andrew, I'm fine if you drop the patchset for now. I fear the next version
> would be tedious to integrate in form of -fix-fix patches anyway...

Thanks for this, I confirm next-20201111 boots fine now on kdevops.

  Luis