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]

Message-ID: <YGznYJ/eW+IySlgw@sashalap>
Date:   Tue, 6 Apr 2021 18:57:36 -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 10:43:52PM +0200, Paolo Bonzini wrote:
>On 06/04/21 21:44, Sasha Levin wrote:
>>On Tue, Apr 06, 2021 at 08:28:27PM +0200, Paolo Bonzini wrote:
>>>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.
>>
>>This quickly went from a "world class" to "fuck it".
>
>Known bugs are better than unknown bugs.  If something is reported on 
>4.19 and the stable@ backports were only done up to 5.4 because the 
>backport was a bit more messy, it's okay.  If a user comes up with a 
>weird bug that I've never seen and that it's caused by a botched 
>backport, it's much worse.
>
>In this specific case we're talking of 5.10; but in many cases users 
>of really old kernels, let's say 4.4-4.9 at this point, won't care 
>about having *all* bugfixes.  Some newer (and thus more buggy) 
>features may be so distant from the mainline in those kernels, or so 
>immature, that no one will consider them while staying on such an old 
>kernel.
>
>Again, kernel necrophilia pays my bills, so I have some experience there. :)

I'm with you on older kernels: if it's too complex users should just be
upgrading.

>>It's understandable that maintainers don't have all the time in the
>>world for this, but are you really asking not to backport fixes to
>>stable trees because you don't have the time for it and don't want
>>anyone else to do it instead?
>
>If a bug is serious I *will* do the backport; I literally did this 
>specific backport on the first working day after the failure report. 
>But not all bugs are created equal and neither are all stable@...rthy 
>bugs.  I try to use the "Fixes" tag correctly, but sometimes a bug 
>that *technically* is 10-years-old may not be worthwhile or even 
>possible to fix even in 5.4.

Agree here too: I'm not advocating to go overboard on backporting stuff
to really old kernels, but I do think it would be great to have most
fixes (even ones not necessarily tagged for stable) on recent kernels
that users should actually be using, and this is where my suggesting to
let more folks deal with the less important stuff comes from.

>That said... one thing that would be really, really awesome would be a 
>website where you navigate a Linux checkout and for each directory you 
>can choose to get a list of stable patches that were Cc-ed to stable@ 
>and failed to apply.  A pipedream maybe, but also a great internship 
>project. :)

I have scripts that do this audit, but sadly my web design skills are
not good enough to make it look pretty :)

I've attached a list for virt/kvm/ and arch/x86/kvm/ on all supported
LTS kernel as an example.

-- 
Thanks,
Sasha

View attachment "kvm_missing.txt" of type "text/plain" (25699 bytes)