On Tue, Nov 10, 2015 at 08:28:11PM +0000, Keith Busch wrote: > > 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. I don't think this is going to help as we'll never enter the reset loop now that we have a single reset_work item, oops. I guess we'll just need to set the aborted status from nvme_timeout if we are in the reset handler already so that it can handle the errors directly instead of waiting for another reset_work do be queued up. I'll try to come up with a version of that. -- 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
