All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: "SZ Lin (林上智)" <sz.lin@moxa.com>
Cc: stable@vger.kernel.org
Subject: Re: FAILED: patch "[PATCH] MIPS: VDSO: Match data page cache colouring when D$ aliases" failed to apply to 4.4-stable tree
Date: Mon, 17 Sep 2018 11:39:01 +0200	[thread overview]
Message-ID: <20180917093901.GE26181@kroah.com> (raw)
In-Reply-To: <20180916134848.GA6645@localhost>

On Sun, Sep 16, 2018 at 09:48:48PM +0800, SZ Lin (林上智) wrote:
> Hi,
> 
> On Sun, Sep 16, 2018 at 02:11:33PM +0200, gregkh@linuxfoundation.org wrote:
> > 
> > The patch below does not apply to the 4.4-stable tree.
> > If someone wants it applied there, or to any other stable or longterm
> > tree, then please email the backport, including the original git commit
> > id to <stable@vger.kernel.org>.
> 
> Please find attached patch 00578cd864d45 ("MIPS: VDSO: Drop gic_get_usm_range() usage")
>  and apply to {4.4,4.9}-stable tree for solving this conflict.
> 
> Thanks!
> 
> SZ Lin (林上智)
> 
> > 
> > thanks,
> > 
> > greg k-h
> > 
> > ------------------ original commit in Linus's tree ------------------
> > 
> > From 0f02cfbc3d9e413d450d8d0fd660077c23f67eff Mon Sep 17 00:00:00 2001
> > From: Paul Burton <paul.burton@mips.com>
> > Date: Thu, 30 Aug 2018 11:01:21 -0700
> > Subject: [PATCH] MIPS: VDSO: Match data page cache colouring when D$ aliases
> > 
> > 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>
> > Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
> > Patchwork: https://patchwork.linux-mips.org/patch/20344/
> > Tested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > Tested-by: Hauke Mehrtens <hauke@hauke-m.de>
> > Cc: James Hogan <jhogan@kernel.org>
> > Cc: linux-mips@linux-mips.org
> > Cc: stable@vger.kernel.org # v4.4+
> > 
> > diff --git a/arch/mips/kernel/vdso.c b/arch/mips/kernel/vdso.c
> > index 019035d7225c..8f845f6e5f42 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
> > +	 * mapping is coloured the same as the kernel's mapping of that memory.
> > +	 * This ensures that when the kernel updates the VDSO data userland
> > +	 * will observe 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;
> >  
> > 
> 
> -- 
> SZ Lin (林上智) <szlin@debian.org>, http://people.debian.org/~szlin
> 
> Debian Developer, debian.org.tw Administrator
> 
> 4096R/ 178F 8338 B314 01E3 04FC 44BA A959 B38A 9561 F3F9

> >From 890151c23e16a48ad0ba05ff60633234c1934c8b Mon Sep 17 00:00:00 2001
> From: Paul Burton <paul.burton@imgtec.com>
> Date: Sat, 12 Aug 2017 21:36:30 -0700
> Subject: [PATCH] MIPS: VDSO: Drop gic_get_usm_range() usage
> 
> commit 00578cd864d45ae4b8fa3f684f8d6f783dd8d15d upstream
> 
> We don't really need gic_get_usm_range() to abstract discovery of the
> address of the GIC user-visible section now that we have access to its
> base address globally.
> 
> Switch to calculating it ourselves, which will allow us to stop
> requiring the irqchip driver to care about a counter exposed to userland
> for use via the VDSO.
> 
> Signed-off-by: Paul Burton <paul.burton@imgtec.com>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: linux-mips@linux-mips.org
> Patchwork: https://patchwork.linux-mips.org/patch/17040/
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
> Signed-off-by: SZ Lin (林上智) <sz.lin@moxa.com>

I do not understand.  What "bug" is this fixing that this needs to be
backported for?

thanks,

greg k-h

  reply	other threads:[~2018-09-17 15:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-16 12:11 FAILED: patch "[PATCH] MIPS: VDSO: Match data page cache colouring when D$ aliases" failed to apply to 4.4-stable tree gregkh
2018-09-16 13:48 ` SZ Lin (林上智)
2018-09-17  9:39   ` Greg KH [this message]
2018-09-24 11:10   ` Greg KH

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=20180917093901.GE26181@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=stable@vger.kernel.org \
    --cc=sz.lin@moxa.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 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.