Re: sata_mv port lockup on hotplug (kernel 2.6.38.2)

[Tejun Heo <htejun@gmail.com>]

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