linux-kernel - Re: [PATCH AUTOSEL 5.9 22/33] vhost scsi: add lun parser helper

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:   Sun, 29 Nov 2020 16:06:50 -0500
From:   Sasha Levin <sashal@...nel.org>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Mike Christie <michael.christie@...cle.com>,
        Jason Wang <jasowang@...hat.com>,
        "Michael S . Tsirkin" <mst@...hat.com>,
        Stefan Hajnoczi <stefanha@...hat.com>,
        virtualization@...ts.linux-foundation.org, kvm@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 5.9 22/33] vhost scsi: add lun parser helper

On Sun, Nov 29, 2020 at 06:34:01PM +0100, Paolo Bonzini wrote:
>On 29/11/20 05:13, Sasha Levin wrote:
>>>Which doesn't seem to be suitable for stable either...  Patch 3/5 
>>>in
>>
>>Why not? It was sent as a fix to Linus.
>
>Dunno, 120 lines of new code?  Even if it's okay for an rc, I don't 
>see why it is would be backported to stable releases and release it 
>without any kind of testing.  Maybe for 5.9 the chances of breaking 

Lines of code is not everything. If you think that this needs additional
testing then that's fine and we can drop it, but not picking up a fix
just because it's 120 lines is not something we'd do.

>things are low, but stuff like locking rules might have changed since 
>older releases like 5.4 or 4.19.  The autoselection bot does not know 
>that, it basically crosses fingers that these larger-scale changes 
>cause the patches not to apply or compile anymore.

Plus all the testing we have for the stable trees, yes. It goes beyond
just compiling at this point.

Your very own co-workers (https://cki-project.org/) are pushing hard on
this effort around stable kernel testing, and statements like these
aren't helping anyone.

If on the other hand, you'd like to see specific KVM/virtio/etc tests as
part of the stable release process, we should all work together to make
sure they're included in the current test suite.

>Maybe it's just me, but the whole "autoselect stable patches" and 
>release them is very suspicious.  You are basically crossing fingers 

Historically autoselected patches were later fixed/reverted at a lower
ratio than patches tagged with a stable tag. I *think* that it's because
they get a longer review cycle than some of the stable tagged patches.

>and are ready to release any kind of untested crap, because you do not 
>trust maintainers of marking stable patches right.  Only then, when a 

It's not that I don't trust - some folks forget, or not realize that
something should go in stable. We're all humans. This is to complement
the work done by maintainers, not replace it.

>backport is broken, it's maintainers who get the blame and have to fix 
>it.

What blame? Who's blaming who?

>Personally I don't care because I have asked you to opt KVM out of 
>autoselection, but this is the opposite of what Greg brags about when 
>he touts the virtues of the upstream stable process over vendor 
>kernels.

What, that we try and include all fixes rather than the ones I'm paid to
pick up?

If you have a vendor you pay $$$ to, then yes - you're probably better
off with a vendor kernel. This is actually in line (I think) with Greg's
views on this
(http://kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/).

-- 
Thanks,
Sasha