[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250307081733-c161a60a-a466-4f38-9024-0d89d7ff13d0@linutronix.de>
Date: Fri, 7 Mar 2025 08:20:27 +0100
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Stephen Rothwell <sfr@...b.auug.org.au>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>, Jeff Xu <jeffxu@...omium.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Linux Next Mailing List <linux-next@...r.kernel.org>,
Nam Cao <namcao@...utronix.de>
Subject: Re: linux-next: manual merge of the tip tree with the mm tree
Hi Stephen,
On Fri, Mar 07, 2025 at 03:14:26PM +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/arm64/kernel/vdso.c
>
> between commit:
>
> 6742f72d084b ("mseal sysmap: enable arm64")
>
> from the mm tree and commit:
>
> 0b3bc3354eb9 ("arm64: vdso: Switch to generic storage implementation")
>
> from the tip tree.
>
> I didn't fix it up - couldn't figure it out, so just reverted the former
> for today as it was simpler.
>
> It looks like VM_SEALED_SYSMAP needs to be added to
> vdso_install_vvar_mapping(), but that is generic across all the
> architectures using GENERIC_VDSO_DATA_STORE.
This resolution should be correct.
VM_SEALED_SYSMAP only does something if CONFIG_MSEAL_SYSTEM_MAPPINGS is set.
<snip>
Thomas
Powered by blists - more mailing lists