linux-kernel - Re: [PATCH 5.10 096/126] KVM: x86/mmu: Use atomic ops to set SPTEs in TDP MMU map

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:   Tue, 6 Apr 2021 14:01:48 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Peter Feiner <pfeiner@...gle.com>,
        Ben Gardon <bgardon@...gle.com>
Subject: Re: [PATCH 5.10 096/126] KVM: x86/mmu: Use atomic ops to set SPTEs
 in TDP MMU map

On Tue, Apr 06, 2021 at 05:48:50PM +0200, Paolo Bonzini wrote:
>On 06/04/21 15:49, Sasha Levin wrote:
>>Yup. Is there anything wrong with those patches?
>
>The big issue, and the one that you ignoredz every time we discuss 
>this topic, is that this particular subset of 17 has AFAIK never been 
>tested by anyone.

Few of the CI systems that run on stable(-rc) releases run
kvm-unit-tests, which passed. So yes, this was tested.

>There's plenty of locking changes in here, one patch that you didn't 
>backport has this in its commit message:
>
>   This isn't technically a bug fix in the current code [...] but that
>   is all very, very subtle, and will break at the slightest sneeze,
>
>meaning that the locking in 5.10 and 5.11 was also less robust to 
>changes elsewhere in the code.
>
>Let's also talk about the process and the timing.  I got the "failed 
>to apply" automated message last Friday and I was going to work on the 
>backport today since yesterday was a holiday here.  I was *never* CCed 

There are a few more "FAILED:" mails that need attention that are older
than this one, I hope they're also in the queue.

>on a post of this backport for maintainers to review; you guys 

You're looking at it, this is the -rc cycle for stable kernels.

>*literally* took random subsets of patches from a feature that is new 
>and in active development, and hoped that they worked on a past 
>release.

Right, I looked at what needed to be backported, took it back to 5.4,
and ran kvm-unit-tests on it.

What other hoops should we jump through so we won't need to "hope"
anymore?

>I could be happy because you just provided me with a perfect example 
>of why to use my employer's franken-kernel instead of upstream stable 
>kernels... ;) but this is not how a world-class operating system is 
>developed.  Who cares if a VM breaks or even if my laptop panics; but 
>I'd seriously fear for my data if you applied the same attitude to XFS 
>or ext4fs.
>
>For now, please drop all 17 patches from 5.10 and 5.11.  I'll send a 
>tested backport as soon as possible.

Sure, I'll drop them. Please let us know when a backport is available.

-- 
Thanks,
Sasha