Re: linux-next: build failure after merge of the tip tree

Borislav Petkov
2026-01-09T17:30:18Z

On Wed, Jan 07, 2026 at 11:52:22AM +0100, Borislav Petkov wrote:
> On Wed, Jan 07, 2026 at 02:47:53PM +1100, Stephen Rothwell wrote:
> > So this still failed with yesterday's tip tree, so clearly there is
> > some other change in today's linux-next that has exposed this.
>
> Yes, because tip/master is fine. This is the usual include hell biting us.
>
> > Instead of using the old version of the tip tree, I have just reverted this
> > commit for today.
>
> Ok, below is what fixes it. How do you want to handle this?
>
> ---
> diff --git a/arch/x86/coco/sev/internal.h b/arch/x86/coco/sev/internal.h
> index 039326b5c799..0df642c76626 100644
> --- a/arch/x86/coco/sev/internal.h
> +++ b/arch/x86/coco/sev/internal.h
> @@ -2,6 +2,9 @@
> #ifndef __X86_COCO_SEV_INTERNAL_H__
> #define __X86_COCO_SEV_INTERNAL_H__
>
> +#include <asm/percpu.h>
> +#include <asm/msr.h>
> +
> #define DR7_RESET_VALUE 0x400
>
> extern u64 sev_hv_features;
> diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
> index 0e6c0940100f..9cfbb27a7bab 100644
> --- a/arch/x86/include/asm/sev.h
> +++ b/arch/x86/include/asm/sev.h
> @@ -16,6 +16,7 @@
> #include <asm/coco.h>
> #include <asm/set_memory.h>
> #include <asm/svm.h>
> +#include <asm/pgtable_types.h>
>
> #define GHCB_PROTOCOL_MIN 1ULL
> #define GHCB_PROTOCOL_MAX 2ULL
>
>
> --

Yah, so I took another look at your linux-next merge order and did build the
tree at those points which are before tip/master. I also merged the
"problematic" tip branch tip/x86/sev each time. Result is:

...
96664520b51e Merge branch 'dma-mapping-for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux.git
b59860457d3a Merge branch 'perf-tools-next' of https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git
f22a45b0077d Merge branch 'kbuild-for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux.git

<-- merge tip/x86/sev ontop: NO

90914704bb11 Merge branch 'mm-nonmm-unstable' of https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

<-- OK

dafcd15eda39 Merge branch 'mm-unstable' of https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

<-- OK

0d069c5ced0c (refs/remotes/linux-next/pending-fixes) Merge branch 'for-linux-next-fixes' of https://gitlab.freedesktop.org/drm/misc/kernel.git
b269a870523e Merge branch 'tip/urgent' of https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
2f4bcdcf5ff3 Merge branch 'fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm.git
...

So it is that mm-nonmm-unstable pile of random crap.

Looking through the patches there, there's:

Author: Coiby Xu <coxu@redhat.com> 2026-01-06 10:50:59
Committer: Andrew Morton <akpm@linux-foundation.org> 2026-01-08 23:31:57
Parent: 63cb8b34f8287156b4dd888f05f9ca5415f9da93 (x86/crash: use set_memory_p instead of __set_memory_prot)
Child: ad1b7e9fdddc88f32b129507a85095f2a1bb9766 (ocfs2: add check for free bits before allocation in ocfs2_move_extent())
Branch: remotes/akpm/mm-nonmm-unstable
Follows: mm-hotfixes-stable-2025-12-28-21-50, v6.19-rc3
Precedes:

Reapply "x86/mm: Remove unused __set_memory_prot()"

This reverts commit e1e6cd01d93359e22be84a23c8bb24ee4e04e142 as
__set_memory_prot is unsued (again) after set_memory_p is used instead for
x86_64 kdump LUKS support (CONFIG_CRASH_DM_CRYPT).

which removes this include:

---------------------- arch/x86/include/asm/set_memory.h ----------------------
index 61f56cdaccb5..8d9f1c9aaa4c 100644
@@ -4,7 +4,6 @@

#include <asm/page.h>
#include <asm-generic/set_memory.h>
-#include <asm/pgtable.h>

#define set_memory_rox set_memory_rox
int set_memory_rox(unsigned long addr, int numpages);

---

So I added it back and the tree builds fine.

Well, what can I say: I have been trying for a long time to get akpm to *stop*
taking patches touching arch/x86/ because this causes issues but nope, that
still goes on.

The issue now is cross-tree build failure which ends up in linux-next and gets
detected there. Had this patch above been in tip, none of that would've
happened.

So, Andrew, once again: please stop taking patches touching arch/x86!

This is causing an unnecessary churn and headaches for no good reason
whatsoever!

--
Regards/Gruss,
Boris.