On Sun, 2016-05-29 at 11:06 -0700, Christoph Hellwig wrote: > On Sun, May 29, 2016 at 08:41:13AM -0700, James Bottomley wrote: > > Actually, it doesn't look fine at all. The same mechanism that's > > supposed to protect the host_failed decrement is also supposed to > > protect the list_move_tail(). If there's a problem with the former > > then we're also in danger of corrupting the list. > > No, that's not the case. eh_entry is used for two things: > > a) shost->eh_cmd_q, which is used to queue up command for the EH > thread, and is locked using the host lock. > b) various on-stack lists in the EH thread Actually, no, in the ata error handler case we have per port queues which are part of the struct ata_port, so it's neither a) nor b). However, because the ata_port is per sas domain device, and the sas_ata_strategy_handler fires off one async thread per domain device, we're concurrency safe on the per-ata_port queues. Just checking some of the other scsi eh assumptions this may be violating. James > scsi_eh_finish_cmd is only called for case b) as all EH thread > implementations move the commands from eh_cmd_q to a local list > as the very first thing. > > host_fail on the other hand is incremented under the host_lock > in scsi_eh_scmd_add, but decremented without any lock from the > EH thread. > -- > 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 > -- 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
