From: "H. Peter Anvin" <hpa@zytor.com>
To: Dmitry Safonov <dima@arista.com>, linux-kernel@vger.kernel.org
Cc: 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>, 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@kernel.org
Subject: Re: [PATCH v3 00/23] Add generic vdso_base tracking
Date: Wed, 11 Oct 2023 16:20:06 -0700 [thread overview]
Message-ID: <eec6b477-67b5-49d6-b6f4-dd2c242b9bdb@zytor.com> (raw)
In-Reply-To: <20210611180242.711399-1-dima@arista.com>
On 6/11/21 11:02, Dmitry Safonov wrote:
>
> Patches set is based on linux-next (next-20201123) and it depends on
> changes in x86/cleanups (those reclaim TIF_IA32/TIF_X32) and also
> on my changes in akpm (fixing several mremap() issues).
>
> Logically, the patches set divides on:
> - patch 1: a cleanup for patches in x86/cleanups
> - patches 2-13: cleanups for arch_setup_additional_pages()
> - patches 13-14: x86 signal changes for unmapped vdso
> - patches 15-22: provide generic vdso_base in mm_struct
> - patch 23: selftest for unmapped vDSO & fast syscalls
>
> In the end, besides cleanups, it's now more predictable what happens for
> applications with unmapped vdso on architectures those support .mremap()
> for vdso/sigpage.
>
> I'm aware of only one user that unmaps vdso - Valgrind [2].
> (there possibly are more, but this one is "special", it unmaps vdso, but
> not vvar, which confuses CRIU [Checkpoint Restore In Userspace], that's
> why I'm aware of it)
>
There was another discussion that might be relevant: actually
associating the vdso with an actual file, and allowing a program to map
said file normally if it want access to one that it normally wouldn't
have (say, /proc/vdso/x86_64.so versus /proc/vdso/i386.so on the same
system.)
The "catch", of course, is that this file will need to be mapped as
MAP_SHARED because of vdso data.
-hpa
prev parent reply other threads:[~2023-10-11 23:21 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-11 18:02 [PATCH v3 00/23] Add generic vdso_base tracking Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 01/23] x86/elf: Check in_x32_syscall() in compat_arch_setup_additional_pages() Dmitry Safonov
2021-06-19 20:41 ` Thomas Gleixner
2021-06-21 20:59 ` Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 02/23] elf: Move arch_setup_additional_pages() to generic elf.h Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 03/23] arm/elf: Remove needless ifdef CONFIG_MMU Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 04/23] arm64: Use in_compat_task() in arch_setup_additional_pages() Dmitry Safonov
2021-06-11 18:02 ` Dmitry Safonov
2021-06-15 10:21 ` Will Deacon
2021-06-15 10:21 ` Will Deacon
2021-06-11 18:02 ` [PATCH v3 05/23] x86: Remove compat_arch_setup_additional_pages() Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 06/23] elf: " Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 07/23] vdso: Set mm->context.vdso only on success of _install_special_mapping() Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 08/23] elf/vdso: Modify arch_setup_additional_pages() parameters Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 09/23] elf: Use sysinfo_ehdr in ARCH_DLINFO() Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 10/23] arm/vdso: Remove vdso pointer from mm->context Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 11/23] s390/vdso: Remove vdso_base " Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 12/23] sparc/vdso: Remove vdso " Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 13/23] mm/mmap: Make vm_special_mapping::mremap return void Dmitry Safonov
2021-06-17 7:20 ` Christophe Leroy
2021-06-21 21:12 ` Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 14/23] x86/signal: Land on &frame->retcode when vdso isn't mapped Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 15/23] x86/signal: Check if vdso_image_32 is mapped before trying to land on it Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 16/23] mm: Add vdso_base in mm_struct Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 17/23] x86/vdso: Migrate to generic vdso_base Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 18/23] arm/vdso: " Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 19/23] arm64/vdso: Migrate compat signals " Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 20/23] arm64/vdso: Migrate native " Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 21/23] mips/vdso: Migrate " Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 22/23] powerpc/vdso: Migrate native signals " Dmitry Safonov
2021-06-15 12:52 ` Michael Ellerman
2021-06-17 6:30 ` Christophe Leroy
2021-06-17 6:36 ` Christophe Leroy
2021-06-17 7:34 ` Christophe Leroy
2021-06-21 21:22 ` Dmitry Safonov
2021-06-11 18:02 ` [PATCH v3 23/23] x86/vdso/selftest: Add a test for unmapping vDSO Dmitry Safonov
2021-06-11 18:21 ` Shuah Khan
2021-06-11 18:37 ` Dmitry Safonov
2021-06-11 18:43 ` Shuah Khan
2021-06-17 9:13 ` [PATCH v3 00/23] Add generic vdso_base tracking Christophe Leroy
2021-06-21 21:57 ` Dmitry Safonov
2022-03-09 15:41 ` Christophe Leroy
2022-03-10 21:17 ` Dmitry Safonov
2022-08-19 9:17 ` Christophe Leroy
2022-08-23 19:13 ` Dmitry Safonov
2023-10-11 10:28 ` Christophe Leroy
2023-10-11 23:20 ` H. Peter Anvin [this message]
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=eec6b477-67b5-49d6-b6f4-dd2c242b9bdb@zytor.com \
--to=hpa@zytor.com \
--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=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=luto@kernel.org \
--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.