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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 29 Aug 2017 13:59:35 -0700
From:   Linus Torvalds <>
To:     Andrea Arcangeli <>
Cc:     Jerome Glisse <>,
        Adam Borowski <>,
        Takashi Iwai <>, Bernhard Held <>,
        Nadav Amit <>,
        Paolo Bonzini <>,
        Wanpeng Li <>,
        Radim Krčmář <>,
        Joerg Roedel <>,
        "Kirill A. Shutemov" <>,
        Andrew Morton <>,
        kvm <>,
        "" <>,
        Michal Hocko <>
Subject: Re: kvm splat in mmu_spte_clear_track_bits

On Tue, Aug 29, 2017 at 1:49 PM, Andrea Arcangeli <> wrote:
> mmu_notifier_invalidate_page has the advantage that it takes the
> secondary MMU KVM srcu and spinlock a single time.

Note that that isn't actually all that much of an advantage - it turns
out that a lot of users have "range_start", but not "range_end".

So in a lot of cases, the "range_start/end()" seems to be exactly as
expensive as just the single "page()" call, simply because the code
didn't really need the whole range, it only wanted to make sure it was
invalidating its data before the range got modified.

KVM ends up doing a partial case of that optimization too: it doesn't
do the srcu lock in the end case, for example.  It does want to keep
the sequence numbers for the end case, but that's fairly cheap.

So I'd much rather have the simpler rules than have duplicated
interfaces for some very dubious performance advantage.


Powered by blists - more mailing lists