Re: [PATCH libata-dev-2.6:upstream 00/02] atapi: packet task vs. intr race fix

[Jeff Garzik <jgarzik@pobox.com>]

Tejun Heo wrote:
>  Now I see what you're saying.  We should be able to know/clear 
> interrupt by reading ATA_STATUS.  So, not having explicit interrupt 
> pending bit can be compensated by following changes in ATA_STATUS (so 
> the state machine), right?  Thanks a lot for putting up with my ignorance.

Correct.  Just never forget there is a side effect to reading the Status 
register -- it clears any interrupt event it also signals.


>  So, how about a port status bit to tell interrupt handler whether or 
> not we are expecting an interrupt currently?  That would solve the race 
> from I tried to fix in the first patchset.  If that's okay with you, 
> I'll redo all four patches accordingly.

I'm a bit skeptical, TBH.  I would prefer some sort of approach whereby 
the code knows where the port is, inside the host state machine, and may 
deduce from that "location" whether or not an interrupt is expected. 
That's precisely how the code functions now with ATA DMA and non-data, 
at least (or should...).

If we find out where the bug in the "I know when I expect an interrupt" 
logic is, then your race should be easy to fix.  Currently, I can see 
that (a) ATAPI interrupt can race with called-immediately EH, and (b) 
ATAPI may throw an interrupt to indicate CDB is ready to be sent [see 
ATA-4], and libata doesn't yet support such a state in its host state 
machine (HSM) implementation.

That said, if you still wish to send such a patch, I will give it an 
open and honest review.

Maybe your bit flag approach plugs the hole in the existing HSM -- I 
would just like to know _where_ this hole is.  So far I don't see it, 
except for (a) and (b) ATAPI examples above.

	Jeff