<div dir="ltr">Hello Bart<div><br></div><div>Firstly let me start with : You have always been kind, patient and helpful to me and myself the same to you so I am not keen to get in the middle of this.</div><div><br></div><div>But its not true about Red Hat because I work very hard on this and I very often find bugs you are not seeing so Red Hat is adding value here.</div><div>I emailed you a number of times asking if you can provide me the exact steps, but not via your srp-test suite.</div><div><br></div><div>I have a setup that is not conducive to running your loop disconnects etc. and if you are seeing a stall on multiple loops of 02-mq I should be able to reproduce it with out having to run your test suite. </div><div><br></div><div>Please let me know how I can help </div><div><br></div><div>Laurence</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 18, 2018 at 4:39 PM, Bart Van Assche <span dir="ltr"><<a href="mailto:Bart.VanAssche@wdc.com" target="_blank">Bart.VanAssche@wdc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, 2018-01-18 at 16:23 -0500, Mike Snitzer wrote:<br>
</span><span class="">> On Thu, Jan 18 2018 at  3:58P -0500,<br>
> Bart Van Assche <<a href="mailto:Bart.VanAssche@wdc.com">Bart.VanAssche@wdc.com</a>> wrote:<br>
><br>
> > On Thu, 2018-01-18 at 15:48 -0500, Mike Snitzer wrote:<br>
> > > For Bart's test the underlying scsi-mq driver is what is regularly<br>
> > > hitting this case in __blk_mq_try_issue_directly():<br>
> > ><br>
> > >         if (blk_mq_hctx_stopped(hctx) || blk_queue_quiesced(q))<br>
> ><br>
</span><span class="">> > These lockups were all triggered by incorrect handling of<br>
> > .queue_rq() returning BLK_STS_RESOURCE.<br>
><br>
> Please be precise, dm_mq_queue_rq()'s return of BLK_STS_RESOURCE?<br>
> "Incorrect" because it no longer runs blk_mq_delay_run_hw_queue()?<br>
<br>
</span>In what I wrote I was referring to both dm_mq_queue_rq() and scsi_queue_rq().<br>
With "incorrect" I meant that queue lockups are introduced that make user<br>
space processes unkillable. That's a severe bug.<br>
<span class=""><br>
> Please try to do more work analyzing the test case that only you can<br>
> easily run (due to srp_test being a PITA).<br>
<br>
</span>It is not correct that I'm the only one who is able to run that software.<br>
Anyone who is willing to merge the latest SRP initiator and target driver<br>
patches in his or her tree can run that software in<br>
any VM. I'm working hard<br>
on getting the patches upstream that make it possible to run the srp-test<br>
software on a setup that is not equipped with InfiniBand hardware.<br>
<span class=""><br>
> We have time to get this right, please stop hyperventilating about<br>
> "regressions".<br>
<br>
</span>Sorry Mike but that's something I consider as an unfair comment. If Ming and<br>
you work on patches together, it's your job to make sure that no regressions<br>
are introduced. Instead of blaming me because I report these regressions you<br>
should be grateful that I take the time and effort to report these regressions<br>
early. And since you are employed by a large organization that sells Linux<br>
support services, your employer should invest in developing test cases that<br>
reach a higher coverage of the dm, SCSI and block layer code. I don't think<br>
that it's normal that my tests discovered several issues that were not<br>
discovered by Red Hat's internal test suite. That's something Red Hat has to<br>
address.<br>
<span class="HOEnZb"><font color="#888888"><br>
Bart.</font></span></blockquote></div><br></div>