linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Christopher Covington <cov@codeaurora.org>,
	criu@openvz.org, linux-mm@kvack.org,
	Laurent Dufour <ldufour@linux.vnet.ibm.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC v2 5/7] powerpc: Rename context.vdso_base to context.vdso
Date: Fri, 4 Nov 2016 20:13:32 +0000	[thread overview]
Message-ID: <20161104201332.GB22791@arm.com> (raw)
In-Reply-To: <87r36rn8nl.fsf@concordia.ellerman.id.au>

[fixing akpm's email address]

On Fri, Nov 04, 2016 at 03:58:22PM +1100, Michael Ellerman wrote:
> Christopher Covington <cov@codeaurora.org> writes:
> 
> > Checkpoint/Restore In Userspace (CRIU) needs to be able to unmap and remap
> > the VDSO to successfully checkpoint and restore applications in the face of
> > changing VDSO addresses due to Address Space Layout Randomization (ASLR,
> > randmaps). x86 and PowerPC have had architecture-specific code to support
> > this. In order to expand the architectures that support this without
> > unnecessary duplication of code, a generic version based on the PowerPC code
> > was created. It differs slightly, based on the results of an informal
> > survey of all architectures that indicated
> >
> > 	unsigned long vdso;
> >
> > is popular (and it's also concise). Therefore, change the variable name in
> > powerpc from mm->context.vdso_base to mm->context.vdso.
> >
> > Signed-off-by: Christopher Covington <cov@codeaurora.org>
> > ---
> >  arch/powerpc/include/asm/book3s/32/mmu-hash.h |  2 +-
> >  arch/powerpc/include/asm/book3s/64/mmu.h      |  2 +-
> >  arch/powerpc/include/asm/mm-arch-hooks.h      |  6 +++---
> >  arch/powerpc/include/asm/mmu-40x.h            |  2 +-
> >  arch/powerpc/include/asm/mmu-44x.h            |  2 +-
> >  arch/powerpc/include/asm/mmu-8xx.h            |  2 +-
> >  arch/powerpc/include/asm/mmu-book3e.h         |  2 +-
> >  arch/powerpc/include/asm/mmu_context.h        |  4 ++--
> >  arch/powerpc/include/asm/vdso.h               |  2 +-
> >  arch/powerpc/include/uapi/asm/elf.h           |  2 +-
> >  arch/powerpc/kernel/signal_32.c               |  8 ++++----
> >  arch/powerpc/kernel/signal_64.c               |  4 ++--
> >  arch/powerpc/kernel/vdso.c                    |  8 ++++----
> >  arch/powerpc/perf/callchain.c                 | 12 ++++++------
> >  14 files changed, 29 insertions(+), 29 deletions(-)
> 
> This is kind of annoying, but I guess it's worth doing.
> 
> It's going to conflict like hell though. Who were you thinking would
> merge this series? I think it should go via Andrew Morton's tree, as
> that way if we get bad conflicts we can pull it out and redo it.

The other thing you can do is generate the patch towards the end of the
merge window and send it as a separate pull request. The disadvantage of
that is that it can't spend any time in -next, but that might be ok for a
mechanical rename.

Will

  parent reply	other threads:[~2016-11-04 20:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-01 17:10 [RFC v2 1/7] mm: Provide generic VDSO unmap and remap functions Christopher Covington
2016-11-01 17:10 ` [RFC v2 2/7] arm: Use generic VDSO unmap and remap Christopher Covington
2016-11-01 17:18   ` Russell King - ARM Linux
2016-11-01 17:10 ` [RFC v2 3/7] arm64: Use unsigned long for VDSO Christopher Covington
2016-11-01 17:10 ` [RFC v2 4/7] arm64: Use generic VDSO unmap and remap functions Christopher Covington
2016-11-01 17:10 ` [RFC v2 5/7] powerpc: Rename context.vdso_base to context.vdso Christopher Covington
     [not found]   ` <87r36rn8nl.fsf@concordia.ellerman.id.au>
2016-11-04 20:13     ` Will Deacon [this message]
2016-11-07  8:01       ` Michael Ellerman
2016-11-01 17:11 ` [RFC v2 6/7] mm/powerpc: Use generic VDSO remap and unmap functions Christopher Covington
2016-11-04  4:59   ` Michael Ellerman
2016-11-07 20:20     ` Laurent Dufour
2016-11-07 23:51       ` Michael Ellerman
2016-11-01 17:23 ` [RFC v2 1/7] mm: Provide generic VDSO unmap and remap functions Dmitry Safonov
2016-11-02  0:23   ` Christopher Covington

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=20161104201332.GB22791@arm.com \
    --to=will.deacon@arm.com \
    --cc=benh@kernel.crashing.org \
    --cc=cov@codeaurora.org \
    --cc=criu@openvz.org \
    --cc=ldufour@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).