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] [day] [month] [year] [list]

Message-ID: <20201205205900.GD643756@sasha-vm>
Date:   Sat, 5 Dec 2020 15:59:00 -0500
From:   Sasha Levin <sashal@...nel.org>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Mike Christie <michael.christie@...cle.com>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        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 Fri, Dec 04, 2020 at 06:08:13PM +0100, Paolo Bonzini wrote:
>On 04/12/20 16:49, Sasha Levin wrote:
>>On Fri, Dec 04, 2020 at 09:27:28AM +0100, Paolo Bonzini wrote:
>>>On 01/12/20 00:59, Sasha Levin wrote:
>>>>
>>>>It's quite easy to NAK a patch too, just reply saying "no" and it'll be
>>>>dropped (just like this patch was dropped right after your first reply)
>>>>so the burden on maintainers is minimal.
>>>
>>>The maintainers are _already_ marking patches with "Cc: stable".  
>>>That
>>
>>They're not, though. Some forget, some subsystems don't mark anything,
>>some don't mark it as it's not stable material when it lands in their
>>tree but then it turns out to be one if it sits there for too long.
>
>That means some subsystems will be worse as far as stable release 
>support goes.  That's not a problem:
>
>- some subsystems have people paid to do backports to LTS releases 
>when patches don't apply; others don't, if the patch doesn't apply the 
>bug is simply not fixed in LTS releases

Why not? A warning mail is originated and folks fix those up. I fixed a
whole bunch of these myself for subsystems I'm not "paid" to do so.

>- some subsystems are worse than others even in "normal" releases :)

Agree with that.

>>>(plus backports) is where the burden on maintainers should start 
>>>and end.  I don't see the need to second guess them.
>>
>>This is similar to describing our CI infrastructure as "second
>>guessing": why are we second guessing authors and maintainers who are
>>obviously doing the right thing by testing their patches and reporting
>>issues to them?
>
>No, it's not the same.  CI helps finding bugs before you have to waste 
>time spending bisecting regressions across thousands of commits.  The 
>lack of stable tags _can_ certainly be a problem, but it solves itself 
>sooner or later when people upgrade their kernel.

If just waiting with fixing issues is ok until a user might "eventually"
upgrade is acceptable then why bother with a stable tree to begin with?

-- 
Thanks,
Sasha