On Mon, Jul 27, 2015 at 11:07 AM, James Bottomley <james.bottom...@hansenpartnership.com> 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.bottom...@hansenpartnership.com> 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 linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
