From: Phil Sutter <phil@nwl.cc>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org,
Herbert Xu <herbert@gondor.apana.org.au>,
Catalin Marinas <catalin.marinas@arm.com>,
'Sebastian Andrzej Siewior' <sebastian@breakpoint.cc>,
linux-crypto@vger.kernel.org, uri@jdland.co.il,
Frank <frank@debian-nas.org>, Simon Baatz <gmbnomis@gmail.com>
Subject: Re: mv_cesa dcache problem since 2.6.37 was: Re: mv_cesa hash functions
Date: Mon, 7 May 2012 18:50:14 +0200 [thread overview]
Message-ID: <20120507165014.GA30092@orbit.nwl.cc> (raw)
In-Reply-To: <20120506122506.GJ26481@n2100.arm.linux.org.uk>
Hi,
On Sun, May 06, 2012 at 01:25:06PM +0100, Russell King - ARM Linux wrote:
> On Sun, May 06, 2012 at 12:49:30AM +0200, Simon Baatz wrote:
> > since there has been no reaction on this, I would like to bring this
> > issue up again (I sadly don't have the expertise to investigate this
> > further...). The issue is not limited to cryptodev, but seems to be
> > either a problem with commit f8b63c1 or a problem in mv_cesa that was
> > uncovered by this commit.
>
> Can you reproduce it with anything else?
>
> It could be a problem with the way crypto stuff works - I've never had
> any dealings with that subsystem, so I really can't comment. If crypto
> uses scatterlists, and walks them with the standard API, and uses
> scatterlists with pages which are already mapped into userspace, then
> I can see how the above commit would make things go wrong.
This is quite exactly what happens. Cryptodev uses get_user_pages to get
the pages belonging to the passed userspace addresses, fills
scatterlists with that information and passes them on to the crypto API.
Mv_cesa.c (at least) then uses the scatterlist mapping iterator to feed
the data chunk by chunk to the crypto engine. Upon completion, cryptodev
simply releases the user pages again by using SetPageDirty() and
page_cache_release(). This has proven unreliable, and the solution I
found was to additionally call flush_dcache_page() before returning the
pages to userspace.
> So, without knowledge of the crypto subsystem, I'm not sure I can help
> sort this out.
What would you recommend for iterating over scatterlists with mapped
pages instead? Since the above commit, neither the mapping iterator API
nor the simple sg_next() seem to be suitable anymore.
Greetings, Phil
next prev parent reply other threads:[~2012-05-07 16:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-22 13:03 mv_cesa hash functions Frank
2012-02-22 20:10 ` Nikos Mavrogiannopoulos
2012-02-23 14:17 ` Sebastian Andrzej Siewior
2012-02-23 18:34 ` Phil Sutter
2012-02-25 7:38 ` Herbert Xu
2012-02-27 11:17 ` [PATCH] crypto: mv_cesa - fix final callback not ignoring input data Phil Sutter
2012-02-28 8:30 ` Herbert Xu
2012-05-05 22:49 ` mv_cesa dcache problem since 2.6.37 was: Re: mv_cesa hash functions Simon Baatz
2012-05-06 12:25 ` Russell King - ARM Linux
2012-05-07 16:50 ` Phil Sutter [this message]
2012-05-08 20:50 ` Simon Baatz
2012-05-07 13:01 ` Frank
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=20120507165014.GA30092@orbit.nwl.cc \
--to=phil@nwl.cc \
--cc=catalin.marinas@arm.com \
--cc=frank@debian-nas.org \
--cc=gmbnomis@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=sebastian@breakpoint.cc \
--cc=uri@jdland.co.il \
/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).