On Tue, Nov 10, 2015 at 04:03:45PM +0000, Keith Busch wrote: > 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. Actually this still needs to be a negative error so nvme_reset_work doesn't clear "NVME_CTRL_RESETTING" bit. Without that, the driver gets in an infinite reset loop. > 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
