Agreed, I think trying to handle these sorts of errors isn't going to be helpful, while the WARN_ON at least gives us a chance to diagnose the issue if it ever happened. > + WARN_ON(!shost->ehandler); > > spin_lock_irqsave(shost->host_lock, flags); > + WARN_ON(shost->shost_state != SHOST_RUNNING && > + shost->shost_state != SHOST_CANCEL && > + shost->shost_state != SHOST_RECOVERY && > + shost->shost_state != SHOST_CANCEL_RECOVERY); Use WARN_ON_ONCE to avoid repeated backtraces for the same condition. > if (scsi_host_set_state(shost, SHOST_RECOVERY)) > - if (scsi_host_set_state(shost, SHOST_CANCEL_RECOVERY)) > - goto out_unlock; > + scsi_host_set_state(shost, SHOST_CANCEL_RECOVERY); No warn_on or early return here? -- 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
