On Tue, Jul 5, 2011 at 1:24 PM, Matthew Wilcox <willy@xxxxxxxxxxxxxxx> wrote: > On Tue, Jul 05, 2011 at 10:48:00PM +0530, Desai, Kashyap wrote: >> I did below experiment. >> Since now host_lock is removed from dispatch() callback. >> I added sleep() inside scsih_qcmd().. Just to mimic preemption. And called Host reset using >> "Sg_reset -h" at the sametime when driver is sleeping inside qcmd(). I see the kernel crash due to invalid scsi command pointer access after driver comes out from sleep(). > > OK, but I don't think we've introduced a new race here, just expanded > the window. > > If you follow the path down from userspace, we get to > scsi_nonblockable_ioctl() (doesn't take the host_lock), then > scsi_reset_provider (which takes and releases the host_lock to > set tmf_in_progress), then scsi_try_host_reset() which calls > eh_host_reset_handler() without holding the host_lock. > > So it's entirely possible to hit the same race on an SMP machine already > as there's nothing to synchronise the eh_host_reset_handler call with > queuecommand. > > I think someone who uses sg_reset ought to be aware of the possibility > that they can trash their system. Doug, what do you think? > Shouldn't the reset ioctl wait for all outstanding commands to return to the midlayer before forcing the reset? If all tmf routines are written under scsi_eh (all outstanding commands quiesced) assumptions it seems the ioctl path must make the same guarantees before triggering a tmf action in a driver? -- 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
