Re: [for 4.1 PATCH resend] libsas: fix "sysfs group not found" warnings at port teardown time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 27, 2015 at 11:07 AM, James Bottomley
<James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, 2015-07-27 at 08:48 -0700, Dan Williams wrote:
>> On Mon, Jul 27, 2015 at 8:17 AM, James Bottomley
>> <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
>> > On Wed, 2015-07-22 at 14:08 -0700, Dan Williams wrote:
>> >>   I don't have a libsas environment handy, I worked with Praveen to
>> >> validate the version as submitted if you want to re-work it.
>> >
>> > A couple of days ago, this was so urgent as to have to go outside the
>> > usual patch process ... now it's not important enough for you to bother
>> > working on it; which is it?
>>
>> Neither, it was a reviewed patch that was idling in the process.  I'm
>> still of the opinion that pinging Andrew in a case like this *is* the
>> expected process, unless there's a place I can check that a patch is
>> still in the application queue?
>
> I didn't ask you to justify your process, I asked you how important you
> thought the patch was mainly because of the conflicting signals you've
> sent.  I get that you think I should treat all your patches as important
> whether you do or not, but the world doesn't quite work like that: patch
> application is a process of triage.  Patches, like this, which have
> timing related issues potentially leading to races get looked at by me
> as the last reviewer.  The speed of review depends on several factors,
> but one of which is what type of user visible issue is this causing.
> The user visible effects of this are a nasty warning message and nothing
> more, I believe?  A useful indicator in this triage is how important the
> submitter thinks the patch is, which was originally why I asked.
>

That would be a question to Praveen.  It wasn't clear to me whether
this sysfs backtrace was a simply a warning or eventually fatal to the
box.
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]