On Tue, Nov 10, 2015 at 09:13:57AM +0100, Christoph Hellwig wrote: > Set Features for set_queue_count times out we'll call the reset handler, > which because we are inside the probe handler will remove the device. > How do we care about the return value in that case? > > Can you write down a few sentences on why/how we care? I'll volunteer > to put them into the driver in comment form once we have all this sorted > out so that anyone touching the driver in the future won't be as confused. Perhaps I am thinking how probing serially worked before, and don't understand how this works anymore. :) You're right, we don't really care anymore if the reset handler unwinds it. This path is then safe to see a fake error code. But the reset handler is the same "work" as probe now, so it won't get scheduled. Now I completely understand why we changed nvme_timeout() to end the request with -EIO instead of waiting for the reset work to cancel it. That's still unsafe since it frees the command for reuse while the ID is still technically owned by the controller. -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
