linux-kernel - Re: [PATCH v2 1/2] mm: Move page struct poisoning to CONFIG_DEBUG_VM_PAGE_INIT

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]

Message-ID: <20180906151336.GD14951@dhcp22.suse.cz>
Date:   Thu, 6 Sep 2018 17:13:36 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     Alexander Duyck <alexander.duyck@...il.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, alexander.h.duyck@...el.com,
        pavel.tatashin@...rosoft.com, akpm@...ux-foundation.org,
        mingo@...nel.org, kirill.shutemov@...ux.intel.com
Subject: Re: [PATCH v2 1/2] mm: Move page struct poisoning to
 CONFIG_DEBUG_VM_PAGE_INIT_POISON

On Thu 06-09-18 07:59:03, Dave Hansen wrote:
> On 09/05/2018 10:47 PM, Michal Hocko wrote:
> > why do you have to keep DEBUG_VM enabled for workloads where the boot
> > time matters so much that few seconds matter?
> 
> There are a number of distributions that run with it enabled in the
> default build.  Fedora, for one.  We've basically assumed for a while
> that we have to live with it in production environments.
> 
> So, where does leave us?  I think we either need a _generic_ debug
> option like:
> 
> 	CONFIG_DEBUG_VM_SLOW_AS_HECK
> 
> under which we can put this an other really slow VM debugging.  Or, we
> need some kind of boot-time parameter to trigger the extra checking
> instead of a new CONFIG option.

I strongly suspect nobody will ever enable such a scary looking config
TBH. Besides I am not sure what should go under that config option.
Something that takes few cycles but it is called often or one time stuff
that takes quite a long but less than aggregated overhead of the former?

Just consider this particular case. It basically re-adds an overhead
that has always been there before the struct page init optimization
went it. The poisoning just returns it in a different form to catch
potential left overs. And we would like to have as many people willing
to running in debug mode to test for those paths because they are
basically impossible to review by the code inspection. More importantnly
the major overhead is boot time so my question still stands. Is this
worth a separate config option almost nobody is going to enable?

Enabling DEBUG_VM by Fedora and others serves us a very good testing
coverage and I appreciate that because it has generated some useful bug
reports. Those people are paying quite a lot of overhead in runtime
which can aggregate over time is it so much to ask about one time boot
overhead?

-- 
Michal Hocko
SUSE Labs