Re: Linux 5.15.103

[Mathias Krause <minipli@grsecurity.net>]

On 01.04.23 15:23, Sasha Levin wrote:
> On Tue, Mar 28, 2023 at 02:29:11PM +0200, Mathias Krause wrote:
>> On 28.03.23 14:14, Greg Kroah-Hartman wrote:
>>> On Tue, Mar 28, 2023 at 02:02:03PM +0200, Mathias Krause wrote:
>>>> On 17.03.23 09:04, Greg Kroah-Hartman wrote:
>>>>> I'm announcing the release of the 5.15.103 kernel.
>>>>>
>>>>> [...]
>>>>>
>>>>> Vitaly Kuznetsov (4):
>>>>>       KVM: Optimize kvm_make_vcpus_request_mask() a bit
>>>>>       KVM: Pre-allocate cpumasks for
>>>>> kvm_make_all_cpus_request_except()
>>>>>       KVM: nVMX: Don't use Enlightened MSR Bitmap for L3
>>>>>       KVM: VMX: Introduce vmx_msr_bitmap_l01_changed() helper
>>>>>
>>>>
>>>> That list is missing commit 6470accc7ba9 ("KVM: x86: hyper-v: Avoid
>>>> calling kvm_make_vcpus_request_mask() with vcpu_mask==NULL") to fulfill
>>>> the prerequisite of "KVM: Optimize kvm_make_vcpus_request_mask() a
>>>> bit".
>>>>
>>>> Right now the kvm selftests trigger a kernel NULL deref for the hyperv
>>>> test, making the system hang.
>>>>
>>>> Please consider applying commit 6470accc7ba9 for the next v5.15.x
>>>> release.
>>>
>>> It wasn't tagged for the stable kernels, so we didn't pick it up :(
>>
>> Neither were any of the above commits. o.O
>>
>> Commit 3e48a6349d29 ("KVM: Optimize kvm_make_vcpus_request_mask() a
>> bit") has this tag, though:
>>
>> Stable-dep-of: 2b0128127373 ("KVM: Register /dev/kvm as the _very_ last
>> thing during initialization")
>>
>> I don't know why, though. These two commits have little in common.
>> Maybe Sasha knows why?
> 
> Because you've skipped the commit in the middle of the two you've
> pointed out :)
> 
> 3e48a6349d29 is needed by 0a0ecaf0988b ("KVM: Pre-allocate cpumasks for
> kvm_make_all_cpus_request_except()"), which in turn is needed by
> 2b0128127373.

I see, 0a0ecaf0988b is "needed" by 2b0128127373 to make it apply clean.
However, there is no functional dependency for 2b0128127373, as it
simply moves device registration around. By picking all the "required"
commits to make it apply clean, still functional required commits were
missed. :(

A simple backport would probably had been the better solution to the
failed cherry-pick, but I see the original author didn't provide one, so
some kind off fall-back process kicked in to pick up dependent commits.
If these would have been announced more visible than by simply adding
them to the queue, it might had been noticed earlier that a commit is
missing still.

This is probably just another example of maintainer's time being such a
scarce resource problem, but the fallback process isn't working flawless
either :/

Thanks,
Mathias