On 05/28/15 20:29, Vasu Dev wrote:
We would have needed schedule() in a HBA design if the current LUN RESET call flow had some thing to finish during schedule() preemption time but then that would have required wait on any such thing with a condition after schedule() is over but currently schedule is just a pause as I described below since all it does is releasing the CPU and then just resumes back without waiting for anything to finish after schedule().
The above is not correct. The schedule() call in fc_seq_set_resp() waits until fc_invoke_resp() invokes wake_up().
Regarding LUN RESET behavior, I think the following quotes from SAM 5 are interesting. From paragraph "5.6 Aborting commands": "After a command is aborted and TASK ABORTED status, if any, is returned, the SCSI target device shall send no further requests or responses for that command." From the paragraph "6.3.3 Logical unit reset": "When responding to a logical unit reset condition, the logical unit shall abort all commands as described in 5.6."
The only way to guarantee that no further responses are sent after a LUN RESET has completed is to wait until all ongoing ep->resp() calls have finished. I think that is what patch 4/4 posted on May 26 realizes. Or did I perhaps overlook something ?
Bart. -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
