* Jeff Xu <jeffxu@xxxxxxxxxx> [240808 21:03]: > On Thu, Aug 8, 2024 at 5:34 PM Pedro Falcato <pedro.falcato@xxxxxxxxx> wrote: > > > > On Fri, Aug 9, 2024 at 12:12 AM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Wed, 7 Aug 2024 22:13:03 +0100 Pedro Falcato <pedro.falcato@xxxxxxxxx> wrote: > > > > > > > This series also depends on (and will eventually very slightly conflict with) > > > > the powerpc series that removes arch_unmap[2]. > > > > > > That's awkward. Please describe the dependency? > > > > One of the transformations done in this patch series (patch 2) assumes > > that arch_unmap either doesn't exist or does nothing. > > PPC is the only architecture with an arch_unmap implementation, and > > through the series I linked they're going to make it work via > > ->close(). > > > > What's the easiest way to deal with this? Can the PPC series go > > through the mm tree? > > > This patch can't be merged until arch_unmap() is all removed (ppc change) I would say that you should just leave the arch_unmap() call in place for now. Are we seriously worried that a powerpc user will try to unmap the VDSO and then get an error that it was mseal'ed after setting the VDSO pointer to NULL? I'm more worried about the Perseid meteor shower hitting me - aka the sky falling. Note that we could already run into an error after setting the vdso pointer to null today. ... Thanks, Liam
