All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: Dmitry Safonov <dima@arista.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Borislav Petkov <bp@alien8.de>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	Guo Ren <guoren@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Ingo Molnar <mingo@redhat.com>, Oleg Nesterov <oleg@redhat.com>,
	Russell King <linux@armlinux.org.uk>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Will Deacon <will@kernel.org>, X86 ML <x86@kernel.org>,
	"open list:MIPS" <linux-mips@vger.kernel.org>
Subject: Re: [PATCH 14/19] mm: Add user_landing in mm_struct
Date: Sun, 8 Nov 2020 11:04:03 -0800	[thread overview]
Message-ID: <CALCETrUYJB3SMFEfD0CiVk9FMAA7uGqescaQLokuPRcPUbYoqg@mail.gmail.com> (raw)
In-Reply-To: <20201108051730.2042693-15-dima@arista.com>

On Sat, Nov 7, 2020 at 9:18 PM Dmitry Safonov <dima@arista.com> wrote:
>
> Instead of having every architecture to define vdso_base/vdso_addr etc,
> provide a generic mechanism to track landing in userspace.
> It'll minimize per-architecture difference, the number of callbacks to
> provide.
>
> Originally, it started from thread [1] where the need for .close()
> callback on vm_special_mapping was pointed, this generic code besides
> removing duplicated .mremap() callbacks provides a cheaper way to
> support munmap() on vdso mappings without introducing .close() callbacks
> for every architecture (with would bring even more code duplication).

I find the naming odd.  It's called "user_landing", which is
presumably a hard-to-understand shorthand for "user mode landing pad
for return from a signal handler if SA_RESTORER is not set".  But,
looking at the actual code, it's not this at all -- it's just the vDSO
base address.

So how about just calling it vdso_base?  I'm very much in favor of
consolidating and cleaning up, and improving the vdso remap/unmap
code, but I'm not convinced that we should call it anything other than
the vdso base.

--Andy

  reply	other threads:[~2020-11-08 19:04 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-08  5:17 [PATCH 00/19] Add generic user_landing tracking Dmitry Safonov
2020-11-08  5:17 ` Dmitry Safonov
2020-11-08  5:17 ` Dmitry Safonov
2020-11-08  5:17 ` [PATCH 01/19] x86/elf: Check in_x32_syscall() in compat_arch_setup_additional_pages() Dmitry Safonov
2020-11-08  5:17 ` [PATCH 02/19] elf: Move arch_setup_additional_pages() to generic elf.h Dmitry Safonov
2020-11-13  6:58   ` kernel test robot
2020-11-13  6:58     ` kernel test robot
2020-11-13  7:01   ` kernel test robot
2020-11-13  7:01     ` kernel test robot
2020-11-08  5:17 ` [PATCH 03/19] arm64: Use in_compat_task() in arch_setup_additional_pages() Dmitry Safonov
2020-11-08  5:17   ` Dmitry Safonov
2020-11-08  5:17 ` [PATCH 04/19] x86: Remove compat_arch_setup_additional_pages() Dmitry Safonov
2020-11-08  5:17 ` [PATCH 05/19] elf: " Dmitry Safonov
2020-11-08  5:17 ` [PATCH 06/19] elf/vdso: Reuse arch_setup_additional_pages() parameters Dmitry Safonov
2020-11-13  6:57   ` kernel test robot
2020-11-13  6:57     ` kernel test robot
2020-11-13  8:04   ` kernel test robot
2020-11-13  8:04     ` kernel test robot
2020-11-08  5:17 ` [PATCH 07/19] elf: Use sysinfo_ehdr in ARCH_DLINFO() Dmitry Safonov
2020-11-08  5:17   ` Dmitry Safonov
2020-11-08  5:17 ` [PATCH 08/19] arm/vdso: Remove vdso pointer from mm->context Dmitry Safonov
2020-11-08  5:17 ` [PATCH 09/19] s390/vdso: Remove vdso_base " Dmitry Safonov
2020-11-08  5:17 ` [PATCH 10/19] sparc/vdso: Remove vdso " Dmitry Safonov
2020-11-08  5:17   ` Dmitry Safonov
2020-11-08  5:17 ` [PATCH 11/19] mm/mmap: Make vm_special_mapping::mremap return void Dmitry Safonov
2020-11-08  5:17 ` [PATCH 12/19] x86/signal: Land on &frame->retcode when vdso isn't mapped Dmitry Safonov
2020-11-08 19:06   ` Andy Lutomirski
2020-11-09  1:22     ` Dmitry Safonov
2020-11-08  5:17 ` [PATCH 13/19] x86/signal: Check if vdso_image_32 is mapped before trying to land on it Dmitry Safonov
2020-11-08  5:17 ` [PATCH 14/19] mm: Add user_landing in mm_struct Dmitry Safonov
2020-11-08 19:04   ` Andy Lutomirski [this message]
2020-11-09  1:25     ` Dmitry Safonov
2020-11-08  5:17 ` [PATCH 15/19] x86/vdso: Migrate to user_landing Dmitry Safonov
2020-11-08  5:17 ` [PATCH 16/19] arm/vdso: " Dmitry Safonov
2020-11-08  5:17 ` [PATCH 17/19] arm64/vdso: Migrate compat signals " Dmitry Safonov
2020-11-08  5:17 ` [PATCH 18/19] arm64/vdso: Migrate native " Dmitry Safonov
2020-11-08  5:17 ` [PATCH 19/19] mips/vdso: Migrate " Dmitry Safonov
2020-11-13  9:58   ` kernel test robot
2020-11-13  9:58     ` kernel test robot
2020-11-08 19:07 ` [PATCH 00/19] Add generic user_landing tracking Andy Lutomirski
2020-11-08 19:07   ` Andy Lutomirski
2020-11-08 19:07   ` Andy Lutomirski
2020-11-09  1:27   ` Dmitry Safonov
2020-11-09  1:27     ` Dmitry Safonov
2020-11-09  1:27     ` Dmitry Safonov

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=CALCETrUYJB3SMFEfD0CiVk9FMAA7uGqescaQLokuPRcPUbYoqg@mail.gmail.com \
    --to=luto@kernel.org \
    --cc=0x7f454c46@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=dima@arista.com \
    --cc=guoren@kernel.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tsbogend@alpha.franken.de \
    --cc=vincenzo.frascino@arm.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will@kernel.org \
    --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: 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.