From: Kim Phillips Subject: Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver Date: Fri, 30 May 2008 17:19:30 -0500 Message-ID: <20080530171930.61965d59.kim.phillips@freescale.com> References: <20080529141250.0946b02c.kim.phillips@freescale.com> <20080530180904.GA18945@2ka.mipt.ru> <20080530143614.1e675228.kim.phillips@freescale.com> <4840585D.8050805@freescale.com> <20080530151638.087970ab.kim.phillips@freescale.com> <4840615F.4070103@freescale.com> <20080530153505.21eb1ec4.kim.phillips@freescale.com> <48406562.4010306@freescale.com> <20080530154820.6e56b625.kim.phillips@freescale.com> <20080530211204.GA15768@2ka.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Scott Wood , linuxppc-dev@ozlabs.org, mr.scada@gmail.com, linux-crypto@vger.kernel.org, herbert@gondor.apana.org.au To: Evgeniy Polyakov Return-path: Received: from de01egw02.freescale.net ([192.88.165.103]:42274 "EHLO de01egw02.freescale.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751521AbYE3WVT (ORCPT ); Fri, 30 May 2008 18:21:19 -0400 In-Reply-To: <20080530211204.GA15768@2ka.mipt.ru> Sender: linux-crypto-owner@vger.kernel.org List-ID: On Sat, 31 May 2008 01:12:08 +0400 Evgeniy Polyakov wrote: > On Fri, May 30, 2008 at 03:48:20PM -0500, Kim Phillips (kim.phillips@freescale.com) wrote: > > sorry, by ISR I meant interrupt status registers. but I can't tell > > where the suspected simultaneous accesses are. Evgeniy, can you point > > out the register accesses you're talking about? > > priv->status is accessed from tasklets, although readonly, but that rises > a red flag... Also callback invocation tasklet drops the lock around 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. > 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. Kim