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]
Date:   Thu, 27 Sep 2018 20:07:33 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Dave Hansen <dave.hansen@...el.com>
cc:     LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Bin Yang <bin.yang@...el.com>,
        Mark Gross <mark.gross@...el.com>
Subject: Re: [patch V3 09/11] x86/mm/cpa: Optimize same protection check

On Fri, 21 Sep 2018, Dave Hansen wrote:
> On 09/17/2018 07:29 AM, Thomas Gleixner wrote:
> > When the existing mapping is correct and the new requested page protections
> > are the same as the existing ones, then further checks can be omitted and the
> > large page can be preserved. The slow path 4k wise check will not come up with
> > a different result.
> > 
> > Before:
> > 
> >  1G pages checked:                    2
> >  1G pages sameprot:                   0
> >  1G pages preserved:                  0
> >  2M pages checked:                  540
> >  2M pages sameprot:                 466
> >  2M pages preserved:                 47
> >  4K pages checked:               800709
> >  4K pages set-checked:             7668
> > 
> > After:
> > 
> >  1G pages checked:                    2
> >  1G pages sameprot:                   0
> >  1G pages preserved:                  0
> >  2M pages checked:                  538
> >  2M pages sameprot:                 466
> >  2M pages preserved:                 47
> >  4K pages checked:               560642
> >  4K pages set-checked:             7668
> 
> With this new path added, I would have expected "2M pages sameprot" or
> "1G pages sameprot" to go up.  The "checked" pages go down, which makes
> sense, but I don't see either of the "sameprot"s going up.
> 
> I did a quick look back at the stats patch and didn't see any obvious
> buglets that can account for it.  Both that and this code look sane, but
> the stats just don't seem to square for some reason.

sameprot does not go up, because the change merily leaves early when it
detected the same prot and full mapping size. So it really just avoids the
extra scanning of the large pages in 4k steps which obviously does not come
to a different conclusion. So quite the contrary if the same prot count
would go up then the early dropout would be wrong because the 4k loop finds
a violation.

Thanks,

	tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ