On Tue, 2014-05-27 at 13:13 +0200, Paolo Bonzini wrote: > Il 27/05/2014 12:59, James Bottomley ha scritto: > > On Tue, 2014-05-27 at 12:47 +0200, Paolo Bonzini wrote: > >> Il 27/05/2014 12:21, James Bottomley ha scritto: > >>> I could also see us one day extending the TMF capability to abort any > >>> running command, which would make even an assertion of block timed out > >>> or completed invalid. > >> > >> Actually the assertion would remain valid, and that's exactly what Bart > >> wants to document with this assertion. > > > > No, it wouldn't: if we abort a running command by definition the command > > hadn't timed out and might not be completed. This is required by TMF > > handling because now you have an abort racing with a completion. Either > > the command completes normally because it misses the abort or the abort > > gets to it and its returned status is set to TASK_ABORTED. That's the > > only way you can tell if the abort was successful or not. > > > > If you're thinking we would tell block to ignore returning commands > > before issuing the abort, we'd never be able to tell if the abort were > > successful, so we have to allow the race to collect the status. > > You could use a different mechanism than a softirq to tell the abort > were successful, for example by overriding scsi_done. But with respect > to the block layer, the mechanics of avoiding the race and double-free > would probably be the same. I think there's some confusion about what the race and double free is: It only occurs with timeouts. In a timeout situation, the host had decided it's not waiting any longer for the target to respond and proceeds to error recovery. At any time between the host making this decision up to the point it kicks the target hard enough to clear all in-flight commands, the target may return the command. If we didn't have some ignore function on command completions while we're handling errors, this would lead to double completion. If we decided to allow arbitrary aborts of running commands, we would send a TMF in during the normal (i.e. un timed out) command period. Because there's no timeout involved, there's no double free problem. The race in this case is whether the abort catches the command or not and to mediate that race we need the normal status return. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
