On 11/07/2017 09:17 AM, Bart Van Assche wrote: > On Tue, 2017-11-07 at 18:15 +0800, Ming Lei wrote: >> Last time, you didn't mention the target patch for setting its >> can_queue as 1, so I think you can't reproduce the issue on upstream >> kernel without out-of-tree patch. Then looks it is another issue, >> and we are making progress actually. > > If I don't trust a patch I introduce additional tests. The fact that I > modified the SRP initiator before this hang occurred does not mean that the > approach of your patch is fine. What this means is that all your patch does > is to reduce the race window and that there is still a race window. I agree, reducing the depth to test that specific case is perfectly valid, it doesn't make the test invalid. It's perfectly possible that other use cases out there have exactly that configuration. My null_blk test case is basically the same. But it would be nice if all of this was out in the open, so everybody is clear on exactly what is being run/tested. However, where my trace is hung off getting a scheduler tag, yours seems to be waiting on IO completion. So not the same fingerprint, which is worrisome. -- Jens Axboe
