linux-kernel - Re: [PATCH v2 14/20] mm: Make hibernate handle unmapped pages

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: <07ea2a4a9f1771f7bad82ad8fe5ee9483b79d115.camel@intel.com>
Date:   Tue, 19 Feb 2019 21:28:55 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "bp@...en8.de" <bp@...en8.de>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "nadav.amit@...il.com" <nadav.amit@...il.com>,
        "Dock, Deneen T" <deneen.t.dock@...el.com>,
        "pavel@....cz" <pavel@....cz>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "hpa@...or.com" <hpa@...or.com>,
        "kristen@...ux.intel.com" <kristen@...ux.intel.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "linux_dti@...oud.com" <linux_dti@...oud.com>,
        "luto@...nel.org" <luto@...nel.org>,
        "will.deacon@....com" <will.deacon@....com>,
        "kernel-hardening@...ts.openwall.com" 
        <kernel-hardening@...ts.openwall.com>,
        "rjw@...ysocki.net" <rjw@...ysocki.net>
Subject: Re: [PATCH v2 14/20] mm: Make hibernate handle unmapped pages

On Tue, 2019-02-19 at 12:04 +0100, Borislav Petkov wrote:
> On Mon, Jan 28, 2019 at 04:34:16PM -0800, Rick Edgecombe wrote:
> > For architectures with CONFIG_ARCH_HAS_SET_ALIAS, pages can be unmapped
> > briefly on the directmap, even when CONFIG_DEBUG_PAGEALLOC is not
> > configured. So this changes kernel_map_pages and kernel_page_present to be
> 
> s/this changes/change/
> 
> From Documentation/process/submitting-patches.rst:
> 
>  "Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
>   instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
>   to do frotz", as if you are giving orders to the codebase to change
>   its behaviour."
> 
> Also, please end function names with parentheses.
Yes, gotcha.

> > defined when CONFIG_ARCH_HAS_SET_ALIAS is defined as well. It also changes
> > places (page_alloc.c) where those functions are assumed to only be
> > implemented when CONFIG_DEBUG_PAGEALLOC is defined.
> 
> The commit message doesn't need to say "what" you're doing - that should
> be obvious from the diff below. It should rather say "why" you're doing
> it.
Ok, sorry. I'll change this to be more concise.

> > So now when CONFIG_ARCH_HAS_SET_ALIAS=y, hibernate will handle not present
> > page when saving. Previously this was already done when
> 
> pages
> 
> > CONFIG_DEBUG_PAGEALLOC was configured. It does not appear to have a big
> > hibernating performance impact.
> 
> Comment over safe_copy_page
Oh, yes you are right.

> > Before:
> > [    4.670938] PM: Wrote 171996 kbytes in 0.21 seconds (819.02 MB/s)
> > 
> > After:
> > [    4.504714] PM: Wrote 178932 kbytes in 0.22 seconds (813.32 MB/s)
> 
> IINM, that's like 1734 pages more. How am I to understand this number?
> 
> Code has called set_alias_nv_noflush() on them and safe_copy_page() now
> maps them one by one to copy them to the hibernation image?
> 
> Thx.
> 
These are from logs hibernate generates. The concern was that hibernate could be
slightly slower because of the checking of whether the pages are mapped. The
bandwidth number can be used to compare, 819.02->813.32 MB/s. Some randomness
must have resulted in different amounts of memory used between tests. I can just
remove the log lines and include the bandwidth numbers.

Thanks,

Rick