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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 30 Nov 2020 14:57:25 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Sasha Levin <sashal@...nel.org>, 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 Mon, Nov 30, 2020 at 02:52:11PM +0100, Paolo Bonzini wrote:
> On 30/11/20 14:28, Greg KH wrote:
> > > > 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.
> > > Starting with the first two steps in stable-kernel-rules.rst:
> > > 
> > > Rules on what kind of patches are accepted, and which ones are not, into the
> > > "-stable" tree:
> > > 
> > >   - It must be obviously correct and tested.
> > >   - It cannot be bigger than 100 lines, with context.
> > We do obviously take patches that are bigger than 100 lines, as there
> > are always exceptions to the rules here.  Look at all of the
> > spectre/meltdown patches as one such example.  Should we refuse a patch
> > just because it fixes a real issue yet is 101 lines long?
> 
> Every patch should be "fixing a real issue"---even a new feature.  But the
> larger the patch, the more the submitters and maintainers should be trusted
> rather than a bot.  The line between feature and bugfix _sometimes_ is
> blurry, I would say that in this case it's not, and it makes me question how
> the bot decided that this patch would be acceptable for stable (which AFAIK
> is not something that can be answered).

I thought that earlier Sasha said that this patch was needed as a
prerequisite patch for a later fix, right?  If not, sorry, I've lost the
train of thought in this thread...

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ