[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250306235802.ff0f406acd0117bcfe927082@linux-foundation.org>
Date: Thu, 6 Mar 2025 23:58:02 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
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>,
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>, Thomas
Weißschuh <thomas.weissschuh@...utronix.de>
Subject: Re: linux-next: manual merge of the tip tree with the mm tree
On Fri, 7 Mar 2025 15:14:26 +1100 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> Hi all,
>
> 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.
>
> and we have the same between commit
>
> 035f34159d61 ("mseal sysmap: enable x86-64")
>
> from the mm tre and commit
>
> dafde29605eb ("x86/vdso: Switch to generic storage implementation")
>
> So I have reverted 035f34159d61 as well.
Thanks.
How about this? I scooped Thomas's series into mm.git and merged
Peter's mseal series on top. I'll sort this out during the merge
window, after the tip tree has merged.
Pushed out now. Peter, please check my handiwork.
Powered by blists - more mailing lists