From: Russell King - ARM Linux <linux@arm.linux.org.uk> To: Simon Baatz <gmbnomis@gmail.com> Cc: 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.infradead.org Subject: Re: mv_cesa dcache problem since 2.6.37 was: Re: mv_cesa hash functions Date: Sun, 6 May 2012 13:25:06 +0100 [thread overview] Message-ID: <20120506122506.GJ26481@n2100.arm.linux.org.uk> (raw) In-Reply-To: <4FA5AE7A.3000201@gmail.com> On Sun, May 06, 2012 at 12:49:30AM +0200, Simon Baatz wrote: > 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 Well, the reason it has been removed is as follows: When pages are allocated, they have a special flag bit called PG_arch_1 cleared by the page allocator. We used to use PG_arch_1 to indicate that the page contained dirty cache lines - so by default, the page was marked clean. Normal kernel behaviour upon allocating a page into the page cache is to read data off the disk into the new page cache page, calling flush_kernel_dcache_page() in the process. This would ensure that data would be pushed out of the cache lines associated with the kernel mapping of the page into RAM. This means when we map the page into userspace, we can be sure that the new mapping will see the data written there. Moreover, when we place a page into a user process, we check this PG_arch_1 bit, and if it's set, we flush the kernel mapping cache lines at this point as well. Patch 6379/1 changed this behaviour: PG_arch_1 being _clear_ now indicates that the page contains dirty data. What this means is that when a page is placed into userspace, we check the PG_arch_1 bit. If it is clear, we flush the kernel mapping for the page to push dirty data out to RAM. This makes the flush in flush_kernel_dcache_page() entirely redundant. > 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. So, without knowledge of the crypto subsystem, I'm not sure I can help sort this out. If it's possible to reproduce with NFS, and it seems sorted in the latest kernel, that's probably because something changed with NFS - NFS did for a time have issues on ARM for various reasons (because of remapping kernel memory into vmalloc space and expecting it to be DMA coherent...) and that got fixed. Whether that's why you're not seeing problems with v3.4-rc5, I couldn't be sure unless you did a bisection between the bad and good kernel versions. That would at least allow us to confirm that that issue has been properly resolved. Thanks.
WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux) To: linux-arm-kernel@lists.infradead.org Subject: mv_cesa dcache problem since 2.6.37 was: Re: mv_cesa hash functions Date: Sun, 6 May 2012 13:25:06 +0100 [thread overview] Message-ID: <20120506122506.GJ26481@n2100.arm.linux.org.uk> (raw) In-Reply-To: <4FA5AE7A.3000201@gmail.com> On Sun, May 06, 2012 at 12:49:30AM +0200, Simon Baatz wrote: > 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 Well, the reason it has been removed is as follows: When pages are allocated, they have a special flag bit called PG_arch_1 cleared by the page allocator. We used to use PG_arch_1 to indicate that the page contained dirty cache lines - so by default, the page was marked clean. Normal kernel behaviour upon allocating a page into the page cache is to read data off the disk into the new page cache page, calling flush_kernel_dcache_page() in the process. This would ensure that data would be pushed out of the cache lines associated with the kernel mapping of the page into RAM. This means when we map the page into userspace, we can be sure that the new mapping will see the data written there. Moreover, when we place a page into a user process, we check this PG_arch_1 bit, and if it's set, we flush the kernel mapping cache lines at this point as well. Patch 6379/1 changed this behaviour: PG_arch_1 being _clear_ now indicates that the page contains dirty data. What this means is that when a page is placed into userspace, we check the PG_arch_1 bit. If it is clear, we flush the kernel mapping for the page to push dirty data out to RAM. This makes the flush in flush_kernel_dcache_page() entirely redundant. > 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. So, without knowledge of the crypto subsystem, I'm not sure I can help sort this out. If it's possible to reproduce with NFS, and it seems sorted in the latest kernel, that's probably because something changed with NFS - NFS did for a time have issues on ARM for various reasons (because of remapping kernel memory into vmalloc space and expecting it to be DMA coherent...) and that got fixed. Whether that's why you're not seeing problems with v3.4-rc5, I couldn't be sure unless you did a bisection between the bad and good kernel versions. That would at least allow us to confirm that that issue has been properly resolved. Thanks.
next prev parent reply other threads:[~2012-05-06 12:25 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 ` mv_cesa dcache problem since 2.6.37 was: Re: mv_cesa hash functions Simon Baatz 2012-05-05 22:49 ` Simon Baatz 2012-05-06 12:25 ` Russell King - ARM Linux [this message] 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=20120506122506.GJ26481@n2100.arm.linux.org.uk \ --to=linux@arm.linux.org.uk \ --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=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: linkBe 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.