linux-kernel - Re: [PATCH 0/3] RDMA/hns: Bug fixes in hns RoCE driver

Open Source and information security mailing list archives

Date:   Wed, 29 Nov 2017 10:00:54 +0000
From:   Jonathan Cameron <Jonathan.Cameron@...wei.com>
To:     Dennis Dalessandro <dennis.dalessandro@...el.com>
CC:     Jason Gunthorpe <jgg@...pe.ca>,
        Bart Van Assche <Bart.VanAssche@....com>,
        "xavier.huwei@....com" <xavier.huwei@....com>,
        "leon@...nel.org" <leon@...nel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "xavier_huwei@....com" <xavier_huwei@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linuxarm@...wei.com" <linuxarm@...wei.com>,
        "dledford@...hat.com" <dledford@...hat.com>
Subject: Re: [PATCH 0/3] RDMA/hns: Bug fixes in hns RoCE driver

On Tue, 28 Nov 2017 15:27:23 -0500
Dennis Dalessandro <dennis.dalessandro@...el.com> wrote:

> On 11/28/2017 2:33 PM, Jason Gunthorpe wrote:
> > On Tue, Nov 28, 2017 at 06:50:44PM +0000, Bart Van Assche wrote:  
> >> On Tue, 2017-11-28 at 11:39 -0700, Jason Gunthorpe wrote:  
> >>> On Tue, Nov 28, 2017 at 08:20:09AM -0500, Dennis Dalessandro wrote:  
> >>>> I could resubmit just the series, or you could just pick the 4 driver
> >>>> patches from patchworks whatever is easiest.  
> >>>
> >>> I marked them in patchworks, but can you review the commit messages
> >>> and make sure you think Linus will see them as rc material too?  
> >>
> >> My understanding is that the rc stage is intended primarily for fixes for
> >> bugs introduced during the merge window. For all patches that do not fix
> >> bugs introduced during the merge window it should be evaluated carefully
> >> whether or not these are important enough to be included in a rc pull request.  
> > 
> > Oh? I thought it was more up to the maintainer discretion within some
> > limits. Eg I thought we were running rdma more with the 'if it is OK
> > for -stable, then it is OK -rc' kind of mentality?  
> 
> That's always been my understanding.

Where I maintain, I've always taken a risk judgment. If it a simple fix
for something that is obviously wrong and comes reasonably early in the
RCs I'll take it for the RCs even if the issue wasn't introduced this cycle.
There is some bias in favor of taking regression fixes even if the issue
was introduced a cycle or two back..

Something that has always been broken or broken for a long time probably
isn't effecting lots of people and can wait a few months.

Later in the RCs where there is less time to revert / follow up fix
I get fussier and will queue for the merge window even when marking
for stable.

Another obvious factor is fixes for new drivers are easier to take,
however invasive and dangerous the changes, as there can't be any
existing users to cause regressions for!

So definitely a maintainer judgment call.  I've struck this balance based
on Greg KH pushing back on my pull requests from time to time ;)

Just put on your 'grumpy maintainer' hat and base it on likelihood of
shouting and how much you care about who is doing that shouting!

> 
> > eg -rc is for stablization and bugfixing only, and not restricted only
> > to bugs introduced in the latest merge window??  
> 
> Makes no sense to me to have a hard restriction here. Security fixes, 
> panics, and other serious bugs should certainly qualify. Of course that 
> is subject to how complex the fix is.

Agreed entirely. Answer isn't always obvious though.

Jonathan

> 
> -Denny
> _______________________________________________
> linuxarm mailing list
> linuxarm@...wei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm

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