From: Simon Baatz <gmbnomis@gmail.com>
To: Frank <frank@debian-nas.org>,
'Sebastian Andrzej Siewior' <sebastian@breakpoint.cc>,
uri@jdland.co.il, linux-crypto@vger.kernel.org,
Herbert Xu <herbert@gondor.apana.org.au>,
Catalin Marinas <catalin.marinas@arm.com>,
linux-arm-kernel@lists.arm.linux.org.uk
Subject: mv_cesa dcache problem since 2.6.37 was: Re: mv_cesa hash functions
Date: Sun, 06 May 2012 00:49:30 +0200 [thread overview]
Message-ID: <4FA5AE7A.3000201@gmail.com> (raw)
In-Reply-To: <20120223183439.GA18545@orbit.nwl.cc>
Hi,
Am 23.02.2012 19:34, schrieb Phil Sutter:
> But you might suffer from another problem, which is only present on
> ARM machines with VIVT cache and linux >= 2.6.37: due to commit
> f8b63c1, "ARM: 6382/1: Remove superfluous flush_kernel_dcache_page()"
> which prevents pages being flushed from inside the scatterlist
> iterator API. This patch seems to introduce problems in other places
> (namely NFS), too but I sadly did not have time to investigate this
> further. I will post a possible (cryptodev-internal) solution to
> cryptodev-linux-devel@gna.org, maybe this fixes the problem with
> openssl. Greetings, Phil
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. In the past, I also had massive problems
compiling on an NFS mounted file system when not reverting f8b63c1. I
currently can't reproduce this anymore under 3.4-rc5.
However, the following still happens on a 3.4-rc5 preempt kernel on arm
kirkwood (VIVT cache):
root@ww1:~# cryptsetup luksOpen /dev/sda2 c_sda2
Enter passphrase for /dev/sda2:
root@ww1:~# vgchange -a y ww1_1
Volume group "ww1_1" not found
root@ww1:~# vgchange -a y ww1_1
Segmentation fault
Thus, the behavior of vgchange is unpredictable on a dm-crypt device
when using mv_cesa (btw. the machine needs to have no load to show this
behavior. I assume that the cache flushes caused by task switches make
it work under load).
Using the generic crypto modules, it works as expected:
root@ww1:~# cryptsetup luksClose c_sda2
root@ww1:~# rmmod mv_cesa
root@ww1:~# cryptsetup luksOpen /dev/sda2 c_sda2
Enter passphrase for /dev/sda2:
root@ww1:~# vgchange -a y ww1_1
1 logical volume(s) in volume group "ww1_1" now active
After reverting f8b63c1, it works as expected using mv_cesa as well.
- Simon
WARNING: multiple messages have this Message-ID (diff)
From: gmbnomis@gmail.com (Simon Baatz)
To: linux-arm-kernel@lists.infradead.org
Subject: mv_cesa dcache problem since 2.6.37 was: Re: mv_cesa hash functions
Date: Sun, 06 May 2012 00:49:30 +0200 [thread overview]
Message-ID: <4FA5AE7A.3000201@gmail.com> (raw)
In-Reply-To: <20120223183439.GA18545@orbit.nwl.cc>
Hi,
Am 23.02.2012 19:34, schrieb Phil Sutter:
> But you might suffer from another problem, which is only present on
> ARM machines with VIVT cache and linux >= 2.6.37: due to commit
> f8b63c1, "ARM: 6382/1: Remove superfluous flush_kernel_dcache_page()"
> which prevents pages being flushed from inside the scatterlist
> iterator API. This patch seems to introduce problems in other places
> (namely NFS), too but I sadly did not have time to investigate this
> further. I will post a possible (cryptodev-internal) solution to
> cryptodev-linux-devel at gna.org, maybe this fixes the problem with
> openssl. Greetings, Phil
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. In the past, I also had massive problems
compiling on an NFS mounted file system when not reverting f8b63c1. I
currently can't reproduce this anymore under 3.4-rc5.
However, the following still happens on a 3.4-rc5 preempt kernel on arm
kirkwood (VIVT cache):
root at ww1:~# cryptsetup luksOpen /dev/sda2 c_sda2
Enter passphrase for /dev/sda2:
root at ww1:~# vgchange -a y ww1_1
Volume group "ww1_1" not found
root at ww1:~# vgchange -a y ww1_1
Segmentation fault
Thus, the behavior of vgchange is unpredictable on a dm-crypt device
when using mv_cesa (btw. the machine needs to have no load to show this
behavior. I assume that the cache flushes caused by task switches make
it work under load).
Using the generic crypto modules, it works as expected:
root at ww1:~# cryptsetup luksClose c_sda2
root at ww1:~# rmmod mv_cesa
root at ww1:~# cryptsetup luksOpen /dev/sda2 c_sda2
Enter passphrase for /dev/sda2:
root at ww1:~# vgchange -a y ww1_1
1 logical volume(s) in volume group "ww1_1" now active
After reverting f8b63c1, it works as expected using mv_cesa as well.
- Simon
next prev parent reply other threads:[~2012-05-05 22:49 UTC|newest]
Thread overview: 17+ 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-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 ` Simon Baatz [this message]
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-06 12:25 ` Russell King - ARM Linux
2012-05-07 16:50 ` Phil Sutter
2012-05-07 16:50 ` Phil Sutter
2012-05-08 20:50 ` Simon Baatz
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=4FA5AE7A.3000201@gmail.com \
--to=gmbnomis@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=frank@debian-nas.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-crypto@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.