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 20:28:27 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Sasha Levin <sashal@...nel.org>
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 06/04/21 20:01, Sasha Levin wrote:
> 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.

The code didn't run unless those CI systems set the module parameter 
that gates the experimental code (they don't).  A compile test is better 
than nothing I guess, but code that didn't run cannot be considered 
tested.  Again, I don't expect that anyone would notice a botched 
backport to 5.10 or 5.11 of this code, but that isn't an excuse for a 
poor process.

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

I guess that's a typo since the code was added in 5.10, but anyway...

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

... you should jump through _less_ hoops.  You are not expected to know 
the status of the code in each and every subsystem, not even Linus does.

If a patch doesn't (more or less trivially) apply, the maintainer should 
take action.  Distro maintainers can also jump in and post the backport 
to subsystem mailing lists.  If the stable kernel loses a patch because 
a maintainer doesn't have the time to do a backport, it's not the end of 
the world.

Paolo