On Sat, 31 May 2008 13:59:02 +0400 Evgeniy Polyakov <johnpol@xxxxxxxxxxx> wrote: > Hi. > > On Fri, May 30, 2008 at 05:19:30PM -0500, Kim Phillips (kim.phillips@xxxxxxxxxxxxx) wrote: > > ok, I see what you are saying now; if a channel gets done during > > talitos_done processing, it'll trigger an interrupt and reset > > priv->status, leaving the tasklet in the dark as to which channel has > > done status, depending on how many channel dones it has already > > processed. I think the only solution here is to call flush_channel on > > each channel, regardless of the bits in the interrupt status - I'll > > send out a patch shortly. > > Out of curiosity, what is number of channels? I had simialar issue with typically four but some parts only have one. > HIFN crypto driver and limited number of descriptor to 80 iirc, since > with that number HIFN traversal did not show perfromance degradataion on > Ghz x86. ok, I've been focusing on correctness for the time being. > > > callback, during that time cached status and priv itself (and tail like > > > in two simultaneous flushes) could change (or not?) > > > > I think you're talking about a different 'status' here; flush_channel's > > local 'status' doesn't resemble priv->status bits in any way, it looks > > at the descriptor header writeback bits for done status, on a per > > descriptor basis. It forwards this descriptor done vs. error status to > > the callback. > > > > priv itself won't change; it's uniquely associated to the device. > > I meant descriptor hdr value accessed via it - can it be checked in > tasklet under the lock and in submit path without? Can they correlate > somehow? I believe the check for a non-null request->desc (under lock) before the hdr value is accessed ensures this doesn't happen. Kim -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
