RE: [PATCH 01/21] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

["Sharma, Sanjeev" <Sanjeev_Sharma@mentor.com>]

-----Original Message-----
From: Greg Kroah-Hartman [mailto:gregkh@linuxfoundation.org] 
Sent: Wednesday, September 10, 2014 7:21 PM
To: Hans de Goede
Cc: Oliver Neukum; linux-usb@vger.kernel.org; linux-scsi@vger.kernel.org; stable@vger.kernel.org; Sharma, Sanjeev
Subject: Re: [PATCH 01/21] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

On Wed, Sep 10, 2014 at 03:15:41PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 09/10/2014 02:54 PM, Oliver Neukum wrote:
> > On Wed, 2014-09-10 at 14:00 +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 09/10/2014 01:56 PM, Oliver Neukum wrote:
> >>> On Wed, 2014-09-10 at 13:48 +0200, Hans de Goede wrote:
> >>>> Hi,
> >>>>
> >>>> Note this series is NOT intended for stable, but I accidentally 
> >>>> had "cc = stable@vger.kernel.org" in my .git/config when sending 
> >>>> this series, please ignore for stable.
> >>>>
> >>>> NACK for stable.
> >>>
> >>> If this is not for stable, what do you intend to do about the 
> >>> problems in stable? For example patch#01 of this series looks like 
> >>> clear stable material to me.
> >>
> >> The plan for stable is mostly, as lame as that is, to make sure we 
> >> get all the right quirks in place so that error handling does not 
> >> get triggered, for now.
> > 
> > How? A medium can be defect. Short of entirely disabling it, error 
> > handling will be triggered.
> 
> I agree that this is a concern, but defective disks are not the norm. 
> All the bugs I've received sofar seem to be about incompatibilities 
> between the Linux uas/scsi stack and the device, not defective mediums.
> 
> >> I agree that once this set has seen wider testing, we should 
> >> reconsider, and probably add it, to stable. But at this point in 
> >> time I'm worried that it may cause regressions, and as such it is 
> >> not stable material atm IHMO.
> > 
> > Well, we would exchange something known to work imperfectly for 
> > something feared to work imperfectly.
> 
> True. Note as said I'm not against this going into stable, I just 
> don't want to rush it into stable. So first lets get it reviewed and 
> into
> 3.18 (and see how it works for the users who have been having troubles 
> sofar, see my request for testing), and then see from there.
> 
> I assume that you agree that this is (way) too late for 3.17?

Yes it is.

And I agree, let's test this out first, and if it solves problems, _then_ we can backport it to stable as needed.

thanks for the patches, I'll queue them up for 3.18.

Thanks all 

There are some more areas in Kernel which need replacement and I will look into those area too.

Regards
Sanjeev Sharma