From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Paul Burton <paul.burton@mips.com>
Cc: Rene Nielsen <rene.nielsen@microsemi.com>,
Hauke Mehrtens <hauke@hauke-m.de>,
linux-mips@linux-mips.org, James Hogan <jhogan@kernel.org>,
stable@vger.kernel.org
Subject: Re: [PATCH] MIPS: VDSO: Match data page cache colouring when D$ aliases
Date: Fri, 31 Aug 2018 15:17:28 +0200 [thread overview]
Message-ID: <20180831131728.GO16561@piout.net> (raw)
In-Reply-To: <20180830180121.25363-1-paul.burton@mips.com>
On 30/08/2018 11:01:21-0700, Paul Burton wrote:
> When a system suffers from dcache aliasing a user program may observe
> stale VDSO data from an aliased cache line. Notably this can break the
> expectation that clock_gettime(CLOCK_MONOTONIC, ...) is, as its name
> suggests, monotonic.
>
> In order to ensure that users observe updates to the VDSO data page as
> intended, align the user mappings of the VDSO data page such that their
> cache colouring matches that of the virtual address range which the
> kernel will use to update the data page - typically its unmapped address
> within kseg0.
>
> This ensures that we don't introduce aliasing cache lines for the VDSO
> data page, and therefore that userland will observe updates without
> requiring cache invalidation.
>
> Signed-off-by: Paul Burton <paul.burton@mips.com>
> Reported-by: Hauke Mehrtens <hauke@hauke-m.de>
> Reported-by: Rene Nielsen <rene.nielsen@microsemi.com>
> Reported-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
> Cc: James Hogan <jhogan@kernel.org>
> Cc: linux-mips@linux-mips.org
> Cc: stable@vger.kernel.org # v4.4+
> ---
> Hi Alexandre,
>
> Could you try this out on your Ocelot system? Hopefully it'll solve the
> problem just as well as James' patch but doesn't need the questionable
> change to arch_get_unmapped_area_common().
>
> Thanks,
> Paul
> ---
> arch/mips/kernel/vdso.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/mips/kernel/vdso.c b/arch/mips/kernel/vdso.c
> index 019035d7225c..5fb617a42335 100644
> --- a/arch/mips/kernel/vdso.c
> +++ b/arch/mips/kernel/vdso.c
> @@ -13,6 +13,7 @@
> #include <linux/err.h>
> #include <linux/init.h>
> #include <linux/ioport.h>
> +#include <linux/kernel.h>
> #include <linux/mm.h>
> #include <linux/sched.h>
> #include <linux/slab.h>
> @@ -20,6 +21,7 @@
>
> #include <asm/abi.h>
> #include <asm/mips-cps.h>
> +#include <asm/page.h>
> #include <asm/vdso.h>
>
> /* Kernel-provided data used by the VDSO. */
> @@ -128,12 +130,30 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
> vvar_size = gic_size + PAGE_SIZE;
> size = vvar_size + image->size;
>
> + /*
> + * Find a region that's large enough for us to perform the
> + * colour-matching alignment below.
> + */
> + if (cpu_has_dc_aliases)
> + size += shm_align_mask + 1;
> +
> base = get_unmapped_area(NULL, 0, size, 0, 0);
> if (IS_ERR_VALUE(base)) {
> ret = base;
> goto out;
> }
>
> + /*
> + * If we suffer from dcache aliasing, ensure that the VDSO data page is
> + * coloured the same as the kernel's mapping of that memory. This
> + * ensures that when the kernel updates the VDSO data userland will see
> + * it without requiring cache invalidations.
> + */
> + if (cpu_has_dc_aliases) {
> + base = __ALIGN_MASK(base, shm_align_mask);
> + base += ((unsigned long)&vdso_data - gic_size) & shm_align_mask;
> + }
> +
> data_addr = base + gic_size;
> vdso_addr = data_addr + PAGE_SIZE;
>
> --
> 2.18.0
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2018-08-31 13:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-28 16:02 VDSO and dcache aliasing Alexandre Belloni
2018-08-30 18:01 ` [PATCH] MIPS: VDSO: Match data page cache colouring when D$ aliases Paul Burton
2018-08-31 8:58 ` Rene.Nielsen
2018-08-31 8:58 ` Rene.Nielsen
2018-08-31 16:47 ` Paul Burton
2018-08-31 13:17 ` Alexandre Belloni [this message]
2018-08-31 15:12 ` Hauke Mehrtens
2018-09-03 7:29 ` Rene.Nielsen
2018-09-03 7:29 ` Rene.Nielsen
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=20180831131728.GO16561@piout.net \
--to=alexandre.belloni@bootlin.com \
--cc=hauke@hauke-m.de \
--cc=jhogan@kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=paul.burton@mips.com \
--cc=rene.nielsen@microsemi.com \
--cc=stable@vger.kernel.org \
/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.