From: Benjamin Herrenschmidt <benh@kernel.crashing.org> To: Ingo Molnar <mingo@kernel.org> Cc: Laurent Dufour <ldufour@linux.vnet.ibm.com>, Paul Mackerras <paulus@samba.org>, Michael Ellerman <mpe@ellerman.id.au>, Jeff Dike <jdike@addtoit.com>, Richard Weinberger <richard@nod.at>, Guan Xuetao <gxt@mprc.pku.edu.cn>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, x86@kernel.org, Arnd Bergmann <arnd@arndb.de>, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net, user-mode-linux-user@lists.sourceforge.net, linux-arch@vger.kernel.org, linux-mm@kvack.org, cov@codeaurora.org, criu@openvz.org Subject: Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap Date: Thu, 26 Mar 2015 08:09:57 +1100 [thread overview] Message-ID: <1427317797.6468.86.camel@kernel.crashing.org> (raw) In-Reply-To: <20150325183316.GA9090@gmail.com> On Wed, 2015-03-25 at 19:33 +0100, Ingo Molnar wrote: > * Laurent Dufour <ldufour@linux.vnet.ibm.com> wrote: > > > +static inline void arch_unmap(struct mm_struct *mm, > > + struct vm_area_struct *vma, > > + unsigned long start, unsigned long end) > > +{ > > + if (start <= mm->context.vdso_base && mm->context.vdso_base < end) > > + mm->context.vdso_base = 0; > > +} > > So AFAICS PowerPC can have multi-page vDSOs, right? > > So what happens if I munmap() the middle or end of the vDSO? The above > condition only seems to cover unmaps that affect the first page. I > think 'affects any page' ought to be the right condition? (But I know > nothing about PowerPC so I might be wrong.) You are right, we have at least two pages. > > > +#define __HAVE_ARCH_REMAP > > +static inline void arch_remap(struct mm_struct *mm, > > + unsigned long old_start, unsigned long old_end, > > + unsigned long new_start, unsigned long new_end) > > +{ > > + /* > > + * mremap() doesn't allow moving multiple vmas so we can limit the > > + * check to old_start == vdso_base. > > + */ > > + if (old_start == mm->context.vdso_base) > > + mm->context.vdso_base = new_start; > > +} > > mremap() doesn't allow moving multiple vmas, but it allows the > movement of multi-page vmas and it also allows partial mremap()s, > where it will split up a vma. > > In particular, what happens if an mremap() is done with > old_start == vdso_base, but a shorter end than the end of the vDSO? > (i.e. a partial mremap() with fewer pages than the vDSO size) Is there a way to forbid splitting ? Does x86 deal with that case at all or it doesn't have to for some other reason ? Cheers, Ben. > Thanks, > > Ingo > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> To: Ingo Molnar <mingo@kernel.org> Cc: Laurent Dufour <ldufour@linux.vnet.ibm.com>, Paul Mackerras <paulus@samba.org>, Michael Ellerman <mpe@ellerman.id.au>, Jeff Dike <jdike@addtoit.com>, Richard Weinberger <richard@nod.at>, Guan Xuetao <gxt@mprc.pku.edu.cn>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, x86@kernel.org, Arnd Bergmann <arnd@arndb.de>, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net, user-mode-linux-user@lists.sourceforge.net, linux-arch@vger.kernel.org, linux-mm@kvack.org, cov@codeaurora.org, criu@openvz.org Subject: Re: [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap Date: Thu, 26 Mar 2015 08:09:57 +1100 [thread overview] Message-ID: <1427317797.6468.86.camel@kernel.crashing.org> (raw) Message-ID: <20150325210957.4HylhcDAd1sadJL3oeWYD4s6yxjRtuJuUlFlrK4YsfI@z> (raw) In-Reply-To: <20150325183316.GA9090@gmail.com> On Wed, 2015-03-25 at 19:33 +0100, Ingo Molnar wrote: > * Laurent Dufour <ldufour@linux.vnet.ibm.com> wrote: > > > +static inline void arch_unmap(struct mm_struct *mm, > > + struct vm_area_struct *vma, > > + unsigned long start, unsigned long end) > > +{ > > + if (start <= mm->context.vdso_base && mm->context.vdso_base < end) > > + mm->context.vdso_base = 0; > > +} > > So AFAICS PowerPC can have multi-page vDSOs, right? > > So what happens if I munmap() the middle or end of the vDSO? The above > condition only seems to cover unmaps that affect the first page. I > think 'affects any page' ought to be the right condition? (But I know > nothing about PowerPC so I might be wrong.) You are right, we have at least two pages. > > > +#define __HAVE_ARCH_REMAP > > +static inline void arch_remap(struct mm_struct *mm, > > + unsigned long old_start, unsigned long old_end, > > + unsigned long new_start, unsigned long new_end) > > +{ > > + /* > > + * mremap() doesn't allow moving multiple vmas so we can limit the > > + * check to old_start == vdso_base. > > + */ > > + if (old_start == mm->context.vdso_base) > > + mm->context.vdso_base = new_start; > > +} > > mremap() doesn't allow moving multiple vmas, but it allows the > movement of multi-page vmas and it also allows partial mremap()s, > where it will split up a vma. > > In particular, what happens if an mremap() is done with > old_start == vdso_base, but a shorter end than the end of the vDSO? > (i.e. a partial mremap() with fewer pages than the vDSO size) Is there a way to forbid splitting ? Does x86 deal with that case at all or it doesn't have to for some other reason ? Cheers, Ben. > Thanks, > > Ingo > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2015-03-25 21:09 UTC|newest] Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-03-20 15:53 [PATCH 0/2] Tracking user space vDSO remaping Laurent Dufour 2015-03-20 15:53 ` Laurent Dufour 2015-03-20 15:53 ` [PATCH 1/2] mm: Introducing arch_remap hook Laurent Dufour 2015-03-20 15:53 ` Laurent Dufour 2015-03-20 23:19 ` Richard Weinberger 2015-03-20 23:19 ` Richard Weinberger 2015-03-23 8:52 ` Ingo Molnar 2015-03-23 9:11 ` Laurent Dufour 2015-03-23 9:11 ` Laurent Dufour 2015-03-25 11:06 ` [PATCH v2 0/2] Tracking user space vDSO remaping Laurent Dufour 2015-03-25 11:06 ` Laurent Dufour 2015-03-25 11:06 ` [PATCH v2 1/2] mm: Introducing arch_remap hook Laurent Dufour 2015-03-25 11:06 ` Laurent Dufour 2015-03-25 11:06 ` [PATCH v2 2/2] powerpc/mm: Tracking vDSO remap Laurent Dufour 2015-03-25 11:06 ` Laurent Dufour 2015-03-25 12:11 ` Ingo Molnar 2015-03-25 12:11 ` Ingo Molnar 2015-03-25 13:25 ` Laurent Dufour 2015-03-25 13:25 ` Laurent Dufour 2015-03-25 13:53 ` [PATCH v3 0/2] Tracking user space vDSO remaping Laurent Dufour 2015-03-25 13:53 ` Laurent Dufour 2015-03-25 13:53 ` [PATCH v3 1/2] mm: Introducing arch_remap hook Laurent Dufour 2015-03-25 13:53 ` [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap Laurent Dufour 2015-03-25 13:53 ` Laurent Dufour 2015-03-25 18:33 ` Ingo Molnar 2015-03-25 18:36 ` Ingo Molnar 2015-03-25 21:11 ` Benjamin Herrenschmidt 2015-03-25 21:11 ` Benjamin Herrenschmidt 2015-03-26 9:43 ` Ingo Molnar 2015-03-26 9:43 ` Ingo Molnar 2015-03-26 10:37 ` Laurent Dufour 2015-03-26 10:37 ` Laurent Dufour 2015-03-26 14:17 ` Ingo Molnar 2015-03-26 14:32 ` Laurent Dufour 2015-03-26 14:32 ` Laurent Dufour 2015-03-26 17:37 ` [PATCH v4 0/2] Tracking user space vDSO remaping Laurent Dufour 2015-03-26 17:37 ` Laurent Dufour 2015-03-26 17:37 ` [PATCH v4 1/2] mm: Introducing arch_remap hook Laurent Dufour 2015-03-26 17:37 ` Laurent Dufour 2015-03-26 17:37 ` [PATCH v4 2/2] powerpc/mm: Tracking vDSO remap Laurent Dufour 2015-03-26 17:37 ` Laurent Dufour 2015-03-26 18:55 ` Ingo Molnar 2015-03-26 18:55 ` Ingo Molnar 2015-03-27 11:02 ` Laurent Dufour 2015-03-26 23:23 ` [PATCH v3 " Benjamin Herrenschmidt 2015-03-26 23:23 ` Benjamin Herrenschmidt 2015-03-25 21:09 ` Benjamin Herrenschmidt [this message] 2015-03-25 21:09 ` Benjamin Herrenschmidt 2015-03-26 9:48 ` Ingo Molnar 2015-03-26 9:48 ` Ingo Molnar 2015-03-26 10:13 ` Laurent Dufour 2015-03-20 15:53 ` [PATCH " Laurent Dufour 2015-03-20 15:53 ` Laurent Dufour 2016-03-02 12:13 ` [PATCH 0/2] Tracking user space vDSO remaping Christopher Covington 2016-03-02 12:13 ` 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=1427317797.6468.86.camel@kernel.crashing.org \ --to=benh@kernel.crashing.org \ --cc=arnd@arndb.de \ --cc=cov@codeaurora.org \ --cc=criu@openvz.org \ --cc=gxt@mprc.pku.edu.cn \ --cc=hpa@zytor.com \ --cc=jdike@addtoit.com \ --cc=ldufour@linux.vnet.ibm.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-s390@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=mingo@kernel.org \ --cc=mingo@redhat.com \ --cc=mpe@ellerman.id.au \ --cc=paulus@samba.org \ --cc=richard@nod.at \ --cc=tglx@linutronix.de \ --cc=user-mode-linux-devel@lists.sourceforge.net \ --cc=user-mode-linux-user@lists.sourceforge.net \ --cc=x86@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: linkBe 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).