* LEROY Christophe <christophe.ler...@cs-soprasteria.com> [240710 17:02]: > > > Le 10/07/2024 à 21:22, Liam R. Howlett a écrit : > > From: "Liam R. Howlett" <liam.howl...@oracle.com> > > > > The arch_unmap call was previously moved above the rbtree modifications > > in commit 5a28fc94c914 ("x86/mpx, mm/core: Fix recursive munmap() > > corruption"). The move was motivated by an issue with calling > > arch_unmap() after the rbtree was modified. > > > > Since the above commit, mpx was dropped from the kernel in 45fc24e89b7c > > ("x86/mpx: remove MPX from arch/x86"), so the motivation for calling > > arch_unmap() prior to modifying the vma tree no longer exists > > (regardless of rbtree or maple tree implementations). > > > > Furthermore, the powerpc implementation is also no longer needed as per > > [1] and [2]. So the arch_unmap() function can be completely removed. > > I'm not sure to understand. Is it replaced by something else ? > We wanted to get rid of arch_unmap() but it was supposed to be replaced > by some core function because the functionnality itself is still > required and indeed all the discussion around [2] demonstrated that not > only powerpc but at least arm and probably others needed to properly > clean-up reference to VDSO mappings on unmapping. > > So as mentioned by Michael you can't just drop that without replacing it > by something else. We need the VDSO signal handling to properly fallback > on stack-based trampoline when the VDSO trampoline gets mapped out.
I'll address this after the part I missed.. > > Or did I miss something ? > I think I missed something in regards to what you need in ppc. >From what I understand, other platforms still map and use the vdso (context.vdso is set), but unmap_arch() does nothing. It is only the powerpc version that clears the vdso pointer if it is unmapped. git grep -w arch_unmap shows: arch/powerpc/include/asm/mmu_context.h arch/x86/include/asm/mmu_context.h include/asm-generic/mm_hooks.h mm/mmap.c The generic and x86 versions are empty. >From the patch set you referenced, we see changes related to the files modified, but I don't think any of them did anything with unmap_arch(). arm: a0d2fcd62ac2 ("vdso/ARM: Make union vdso_data_store available for all architectures") arm64: d0fba04847ae ("arm64: vdso: Use generic union vdso_data_store") mips: d697a9997a0d ("MIPS: vdso: Use generic union vdso_data_store") s390: cb3444cfdb48 ("s390/vdso: Use generic union vdso_data_store") riscv: eba755314fa7 ("riscv: vdso: Use generic union vdso_data_store") ia64 is dead nds32 is dead hexagon has a bunch of vdso work in the logs as well. There is also a6c19dfe3994 ("arm64,ia64,ppc,s390,sh,tile,um,x86,mm: remove default gate area") I do not see sparc changing away from what the patches were doing, but again, the arch_unmap() seems to do nothing there as well. So, what I was looking to do is to avoid a call to arch specific functions that does nothing but set the vdso pointer to NULL for powerpc. The thread referenced in the git bug [1] seems to indicate this is for CRIU unmapping/restoring a task, but CRIU now just moves the vdso mapping (or just works on ppc at this point?). Since [2] hasn't landed, isn't this still broken for CRIU on powerpc as it is? So, are we keeping the unmap_arch() function around, which has errors that were never fixed, for a single application that utilizes a newer method of moving the vdso anyways? On the note of CRIU, it seems it cannot handle tasks which don't have the vdso mapped anymore [3], so setting it to NULL is probably a bad plan even for that one application? So, I think this just leaves the fallback when the VDSO is unmapped.. Well, it seems what people have been doing is unmap the vdso to stop these functions from working [4]. At least this is what some users are doing. The ability to replace this vma with a guard vma leads me to believe that other archs don't fall back at all - please correct me if I'm wrong! I also cannot find any reference to other archs clearing the context.vdso (aside from failures in __setup_additional_pages). But maybe I don't fully understand how this works? Thanks, Liam [1] https://lore.kernel.org/lkml/87d0lht1c0....@concordia.ellerman.id.au/ [2] https://lore.kernel.org/lkml/9c2b2826-4083-fc9c-5a4d-c101858dd...@linux.vnet.ibm.com/ [3] https://github.com/checkpoint-restore/criu/issues/488 [4] https://github.com/insanitybit/void-ship Thanks, Liam