From: Kim Phillips <kim.phillips@freescale.com>
To: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Cc: Scott Wood <scottwood@freescale.com>,
linuxppc-dev@ozlabs.org, mr.scada@gmail.com,
linux-crypto@vger.kernel.org, herbert@gondor.apana.org.au
Subject: Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver
Date: Mon, 2 Jun 2008 11:50:21 -0500 [thread overview]
Message-ID: <20080602115021.cdda8647.kim.phillips@freescale.com> (raw)
In-Reply-To: <20080602160012.GB32511@2ka.mipt.ru>
On Mon, 2 Jun 2008 20:00:12 +0400
Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> On Mon, Jun 02, 2008 at 09:27:01AM -0500, Kim Phillips (kim.phillips@freescale.com) wrote:
> > > 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.
>
> But can it be changed? You write to it without lock, but read under the
> one (different for each channel though), so it attracted attention.
can you point where in the code your concern is?
desc is assigned under head lock and cleared under tail lock, both after
an smp_wmb. hdr data is assigned before desc is written, and read
after desc is found to be !NULL (i.e, hdr access is governed by if
(desc)). head and tail indices get advanced each within their
corresponding locks. So afaict there shouldn't be a case where data
pointed to by desc can be accessed by both the consumer and the
producer at any one point in time. Does that help?
Kim
next prev parent reply other threads:[~2008-06-02 16:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-29 19:12 [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver Kim Phillips
2008-05-30 18:09 ` Evgeniy Polyakov
2008-05-30 19:36 ` Kim Phillips
2008-05-30 19:41 ` Scott Wood
2008-05-30 20:13 ` Evgeniy Polyakov
2008-05-30 20:16 ` Kim Phillips
2008-05-30 20:19 ` Scott Wood
2008-05-30 20:35 ` Kim Phillips
2008-05-30 20:36 ` Scott Wood
2008-05-30 20:48 ` Kim Phillips
2008-05-30 21:12 ` Evgeniy Polyakov
2008-05-30 22:19 ` Kim Phillips
2008-05-31 9:59 ` Evgeniy Polyakov
2008-06-02 14:27 ` Kim Phillips
2008-06-02 16:00 ` Evgeniy Polyakov
2008-06-02 16:50 ` Kim Phillips [this message]
2008-06-02 17:57 ` Evgeniy Polyakov
2008-06-02 19:06 ` Kim Phillips
2008-06-03 1:24 ` Evgeniy Polyakov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080602115021.cdda8647.kim.phillips@freescale.com \
--to=kim.phillips@freescale.com \
--cc=herbert@gondor.apana.org.au \
--cc=johnpol@2ka.mipt.ru \
--cc=linux-crypto@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mr.scada@gmail.com \
--cc=scottwood@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).