Sorry about delay. -EWASTRAVELING On Tue, Apr 12, 2011 at 10:55:55AM -0400, Mark Lord wrote: > >> One thing I noticed was that there is no spinlock around the > >> mv_save_cached_regs/mv_edma_cfg in mv_hardreset (unlike mv_port_start and > >> mv_port_stop); why is this? > > > > The mv_hardreset path is run from a libata-eh thread, > > and it assumes it has exclusive access to the hardware. > > Mmm.. another suspect is sata_mv's ".sff_irq_clear" function. > I don't see any locking in libata-sff.c before calling that one. > > Tejun -- should libata-sff grab ap->lock before calling .sff_irq_clear, > or is that up to the LLD to do? It depends. The basic assumption is that inside a single port, most of exclusions are achieved implicit either by command protocol or freeze/thaw mechanism - ie. either the port is in known state and accesses are interlocked or the port is frozen and irq handler won't do anything interfering with EH until EH brings the port back to sane state. If something goes wrong in the process, the port will get frozen and reset, so we should be able to survive most conditions. Ports on the same host are a bit more complicated. Only a single EH can proceed on a host. ie. EHs for two separate ports won't proceed at the same time (ap->eh_owner); however, this doesn't prevent from normal issue path of another path racing with EH of another port. In this case, the EH routine should grab the host lock explicitly. The latter case wasn't common so the compromise for simplicity. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
