From: Dmitry Safonov <dsafonov@virtuozzo.com>
To: <linux-kernel@vger.kernel.org>
Cc: <0x7f454c46@gmail.com>, Dmitry Safonov <dsafonov@virtuozzo.com>,
Russell King <rmk+kernel@armlinux.org.uk>,
<linux-arm-kernel@lists.infradead.org>,
Will Deacon <will.deacon@arm.com>,
Christopher Covington <cov@codeaurora.org>,
Cyrill Gorcunov <gorcunov@openvz.org>,
Pavel Emelyanov <xemul@virtuozzo.com>
Subject: [PATCH] ARM/shmem: Drop page coloring align for non-VIPT CPUs
Date: Fri, 14 Apr 2017 13:09:53 +0300 [thread overview]
Message-ID: <20170414100953.4703-1-dsafonov@virtuozzo.com> (raw)
On ARMv6 CPUs with VIPT caches there are aliasing issues: if two
different cache line indexes correspond to the same physical
address, then changes made to one of the alias might be lost
or they can overwrite each other. To overcome aliasing issues,
the align for shared mappings was introduced with:
commit 4197692eef113eeb8e3e413cc70993a5e667e5b8
Author: Russell King <rmk@flint.arm.linux.org.uk>
Date: Wed Apr 28 22:22:33 2004 +0100
[ARM] Fix shared mmap()ings for ARM VIPT caches.
This allows us to appropriately align shared mappings on VIPT caches
with aliasing issues.
Which introduced 4 pages align with SHMLBA, which resulted in
unique physical address after any tag in cache (because two upper bits
corresponding to page address get unused in tags).
As this workaround is not needed by non-VIPT caches (like most armv7
CPUs which have PIPT caches), ARM mmap() code checks if cache is VIPT
aliasing for MAP_SHARED.
The problem here is in shmat() syscall:
1. if shmaddr is NULL then do_shmat() uses arch_get_unmapped_area()
to allocate shared mapping.
2. if shmaddr is specified then do_shmat() checks that address has
SHMLBA alignment regardless to CPU cache aliasing.
Which results on ARMv7 CPUs that shmat() with NULL shmaddr may return
non-SHMLBA aligned address (page-aligned), but shmat() with the same
address will fail.
That is not critical issue for CRIU as after shmat() with NULL address,
we can mremap() resulted shmem to restore shared memory mappings on the
same address where they were on checkpointing.
But it's still worth fixing because we can't reliably tell from
userspace if the platform has VIPT cache, and so this mremap()
workaround is done with HUGE warning that restoring application, that
uses SHMBLA-unaligned shmem on ARMv6 CPU with VIPT cache may result
in data corruptions.
I also changed SHMLBA build-time check to init-time WARN_ON(), as
it's not constant afterward.
This is resend of the patch from discussion:
http://www.spinics.net/lists/arm-kernel/msg258870.html
Cc: linux-arm-kernel@lists.infradead.org
Cc: Will Deacon <will.deacon@arm.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Christopher Covington <cov@codeaurora.org>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Pavel Emelyanov <xemul@virtuozzo.com>
Suggested-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
---
arch/arm/include/asm/shmparam.h | 8 ++++----
arch/arm/mm/copypage-v6.c | 5 +----
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arm/include/asm/shmparam.h b/arch/arm/include/asm/shmparam.h
index a5223b3a9bf9..6e1a72cbdf78 100644
--- a/arch/arm/include/asm/shmparam.h
+++ b/arch/arm/include/asm/shmparam.h
@@ -1,16 +1,16 @@
#ifndef _ASMARM_SHMPARAM_H
#define _ASMARM_SHMPARAM_H
+#include <asm/cachetype.h>
+
/*
* This should be the size of the virtually indexed cache/ways,
* or page size, whichever is greater since the cache aliases
* every size/ways bytes.
*/
-#define SHMLBA (4 * PAGE_SIZE) /* attach addr a multiple of this */
+#define SHMLBA (cache_is_vipt_aliasing() ? 4 * PAGE_SIZE : PAGE_SIZE)
-/*
- * Enforce SHMLBA in shmat
- */
+/* Enforce SHMLBA in shmat */
#define __ARCH_FORCE_SHMLBA
#endif /* _ASMARM_SHMPARAM_H */
diff --git a/arch/arm/mm/copypage-v6.c b/arch/arm/mm/copypage-v6.c
index 70423345da26..9b22c530e8b6 100644
--- a/arch/arm/mm/copypage-v6.c
+++ b/arch/arm/mm/copypage-v6.c
@@ -20,10 +20,6 @@
#include "mm.h"
-#if SHMLBA > 16384
-#error FIX ME
-#endif
-
static DEFINE_RAW_SPINLOCK(v6_lock);
/*
@@ -129,6 +125,7 @@ struct cpu_user_fns v6_user_fns __initdata = {
static int __init v6_userpage_init(void)
{
+ WARN_ON(SHMLBA > 16384);
if (cache_is_vipt_aliasing()) {
cpu_user.cpu_clear_user_highpage = v6_clear_user_highpage_aliasing;
cpu_user.cpu_copy_user_highpage = v6_copy_user_highpage_aliasing;
--
2.12.2
next reply other threads:[~2017-04-14 10:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-14 10:09 Dmitry Safonov [this message]
2017-04-25 17:19 ` Dmitry Safonov
2017-04-25 17:35 ` Russell King - ARM Linux
2017-04-25 17:51 ` Dmitry Safonov
2017-05-18 11:22 ` Dmitry Safonov
2017-05-23 20:10 ` Russell King - ARM Linux
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=20170414100953.4703-1-dsafonov@virtuozzo.com \
--to=dsafonov@virtuozzo.com \
--cc=0x7f454c46@gmail.com \
--cc=cov@codeaurora.org \
--cc=gorcunov@openvz.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk+kernel@armlinux.org.uk \
--cc=will.deacon@arm.com \
--cc=xemul@virtuozzo.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
Powered by JetHome