When building with CONFIG_PARAVIRT, but without CONFIG_PARAVIRT_XXL,
a build failure might happen due to arch/x86/include/asm/irqflags.h
only including asm/paravirt.h when CONFIG_PARAVIRT_XXL is set.

This was spotted when testing a patch removing the
"#include <asm/paravirt.h>" from another header.

Fixes: 22cc5ca5de52 ("x86/paravirt: Move halt paravirt calls under CONFIG_PARAVIRT")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202601152203.plJOoOEF-lkp@intel.com/
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/irqflags.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
index a1193e9d65f2..4d4d02e31287 100644
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -96,11 +96,11 @@ static __always_inline void halt(void)
 	native_halt();
 }
 #endif /* __ASSEMBLY__ */
+#else
+#include <asm/paravirt.h>
 #endif /* CONFIG_PARAVIRT */
 
-#ifdef CONFIG_PARAVIRT_XXL
-#include <asm/paravirt.h>
-#else
+#ifndef CONFIG_PARAVIRT_XXL
 #ifndef __ASSEMBLER__
 #include <linux/types.h>
 
-- 
2.51.0

On Thu, Jan 15, 2026 at 05:10:14PM +0100, Juergen Gross wrote:
> When building with CONFIG_PARAVIRT, but without CONFIG_PARAVIRT_XXL,
> a build failure might happen due to arch/x86/include/asm/irqflags.h
> only including asm/paravirt.h when CONFIG_PARAVIRT_XXL is set.
> 
> This was spotted when testing a patch removing the
> "#include <asm/paravirt.h>" from another header.
> 
> Fixes: 22cc5ca5de52 ("x86/paravirt: Move halt paravirt calls under CONFIG_PARAVIRT")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202601152203.plJOoOEF-lkp@intel.com/

So this got reported against a patchset which is not upstream yet, yet your
Fixes: points to a patch from ~year ago.

The right thing to do would be to take *that* fix and prepend your
not-upstrea-yet set with it.

Also, why does *this* fix need to go to all kernels which contain the patch in
Fixes?

All this sounds weird.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On 15.01.26 18:45, Borislav Petkov wrote:
> On Thu, Jan 15, 2026 at 05:10:14PM +0100, Juergen Gross wrote:
>> When building with CONFIG_PARAVIRT, but without CONFIG_PARAVIRT_XXL,
>> a build failure might happen due to arch/x86/include/asm/irqflags.h
>> only including asm/paravirt.h when CONFIG_PARAVIRT_XXL is set.
>>
>> This was spotted when testing a patch removing the
>> "#include <asm/paravirt.h>" from another header.
>>
>> Fixes: 22cc5ca5de52 ("x86/paravirt: Move halt paravirt calls under CONFIG_PARAVIRT")
>> Reported-by: kernel test robot <lkp@intel.com>
>> Closes: https://lore.kernel.org/oe-kbuild-all/202601152203.plJOoOEF-lkp@intel.com/
> 
> So this got reported against a patchset which is not upstream yet, yet your
> Fixes: points to a patch from ~year ago.

Yes. The problem was introduced by that patch. It was pure luck paravirt.h
got included via another header.

> The right thing to do would be to take *that* fix and prepend your
> not-upstrea-yet set with it.

Yes, this would be a possibility. I still can do that, but I saw no real reason
to resend the other 5 patches without any change.

> Also, why does *this* fix need to go to all kernels which contain the patch in
> Fixes?

Whenever another patch is being backported results in the same problem, it will
be mitigated by my fix.

> All this sounds weird.

TBH I'm quite puzzled that this build failure hasn't been seen before. As I said
above: pure luck.


Juergen

On Thu, Jan 15, 2026 at 07:29:37PM +0100, Jürgen Groß wrote:
> Yes. The problem was introduced by that patch. It was pure luck paravirt.h
> got included via another header.

So there's no configuration right now which triggers this problem?

> Yes, this would be a possibility. I still can do that, but I saw no real reason
> to resend the other 5 patches without any change.

You mean, you expect me to read minds? :)

> TBH I'm quite puzzled that this build failure hasn't been seen before. As I said
> above: pure luck.

Sorry, we don't do "pure luck."

This either fixes something in the *current* kernel or if not, it should be
applied as an urgent fix when it does after "pure luck" has been debugged
properly and explained.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On 19.01.26 12:36, Borislav Petkov wrote:
> On Thu, Jan 15, 2026 at 07:29:37PM +0100, Jürgen Groß wrote:
>> Yes. The problem was introduced by that patch. It was pure luck paravirt.h
>> got included via another header.
> 
> So there's no configuration right now which triggers this problem?

I don't know any. This doesn't mean there is none.

> 
>> Yes, this would be a possibility. I still can do that, but I saw no real reason
>> to resend the other 5 patches without any change.
> 
> You mean, you expect me to read minds? :)

Oh, you can't? ;-)

> 
>> TBH I'm quite puzzled that this build failure hasn't been seen before. As I said
>> above: pure luck.
> 
> Sorry, we don't do "pure luck."
> 
> This either fixes something in the *current* kernel or if not, it should be
> applied as an urgent fix when it does after "pure luck" has been debugged
> properly and explained.

Well, your call in this case.

So do you want me to resend the series triggering the issue with this patch
prepended, or are you fine with applying this patch to the tip branch for
the next merge window, and wait for the other series to get the needed Acks?


Juergen

On Mon, Jan 19, 2026 at 12:52:50PM +0100, Jürgen Groß wrote:
> So do you want me to resend the series triggering the issue with this patch
> prepended, or are you fine with applying this patch to the tip branch for
> the next merge window, and wait for the other series to get the needed Acks?

Or, you could redesign your set in a way so that the build error doesn't
happen and there's no need for an urgent patch with a questionable Fixes: tag?

Also, the "pure luck" thing would need debugging too, to figure out why the
build error happens.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On 19.01.26 14:28, Borislav Petkov wrote:
> On Mon, Jan 19, 2026 at 12:52:50PM +0100, Jürgen Groß wrote:
>> So do you want me to resend the series triggering the issue with this patch
>> prepended, or are you fine with applying this patch to the tip branch for
>> the next merge window, and wait for the other series to get the needed Acks?
> 
> Or, you could redesign your set in a way so that the build error doesn't
> happen and there's no need for an urgent patch with a questionable Fixes: tag?
> 
> Also, the "pure luck" thing would need debugging too, to figure out why the
> build error happens.
> 

Ah, yes. The build error happens due to the change of io.h: instead of
including paravirt.h only paravirt-base.h is included. Obviously several
sources did include io.h and irqflags.h, but no other header including
paravirt.h.


Juergen

On Mon, Jan 19, 2026 at 02:58:45PM +0100, Jürgen Groß wrote:
> Ah, yes. The build error happens due to the change of io.h: instead of
> including paravirt.h only paravirt-base.h is included. Obviously several
> sources did include io.h and irqflags.h, but no other header including
> paravirt.h.

So your io set needs the paravirt pile from tip/x86/paravirt. So you can
include paravirt.h in there and no need for a "fix" patch.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On 19.01.26 15:10, Borislav Petkov wrote:
> On Mon, Jan 19, 2026 at 02:58:45PM +0100, Jürgen Groß wrote:
>> Ah, yes. The build error happens due to the change of io.h: instead of
>> including paravirt.h only paravirt-base.h is included. Obviously several
>> sources did include io.h and irqflags.h, but no other header including
>> paravirt.h.
> 
> So your io set needs the paravirt pile from tip/x86/paravirt. So you can
> include paravirt.h in there and no need for a "fix" patch.
> 

Sigh.

paravirt.h is a big hammer.

Switching to paravirt-base.h is part of the goal to reduce include hell
with paravirt.

Why do you insist on keeping irqflags.h inconsistent by not defining
some prototypes if CONFIG_PARAVIRT is set, but not CONFIG_PARAVIRT_XXL.

Commit 22cc5ca5de52 was just missing the part of my patch. It was wrong.
Should have moved the "#include <asm/paravirt.h>" from the
CONFIG_PARAVIRT_XXL to the CONFIG_PARAVIRT umbrella, just like my
patch.

Or do you really think everyone including irqflags.h should include
io.h, too?


Juergen

On Mon, Jan 19, 2026 at 03:22:57PM +0100, Jürgen Groß wrote:
> Why do you insist on keeping irqflags.h inconsistent by not defining
> some prototypes if CONFIG_PARAVIRT is set, but not CONFIG_PARAVIRT_XXL.

The only thing I'm insisting on is proper patch documentation because stable
patches do get looked at by stable folks so it better be clear what we're
fixing.

> Commit 22cc5ca5de52 was just missing the part of my patch. It was wrong.
> Should have moved the "#include <asm/paravirt.h>" from the
> CONFIG_PARAVIRT_XXL to the CONFIG_PARAVIRT umbrella, just like my
> patch.

So this makes more sense. Your current patch is fixing 22cc5ca5de52. But
nothing breaks currently, only after you switch to including paravirt-base.h
and not the big fat header.

Which means that the patch at the beginning of this thread should be the first
patch in your io set, it should have a Fixes: tag but we should NOT send it to
stable because nothing breaks there.

Your io patchset, at a quick glance, is cleanups so it won't go to stable
either so no need for that fix to go stable either.

Does that sound like a good strategy?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On 19.01.26 16:46, Borislav Petkov wrote:
> On Mon, Jan 19, 2026 at 03:22:57PM +0100, Jürgen Groß wrote:
>> Why do you insist on keeping irqflags.h inconsistent by not defining
>> some prototypes if CONFIG_PARAVIRT is set, but not CONFIG_PARAVIRT_XXL.
> 
> The only thing I'm insisting on is proper patch documentation because stable
> patches do get looked at by stable folks so it better be clear what we're
> fixing.
> 
>> Commit 22cc5ca5de52 was just missing the part of my patch. It was wrong.
>> Should have moved the "#include <asm/paravirt.h>" from the
>> CONFIG_PARAVIRT_XXL to the CONFIG_PARAVIRT umbrella, just like my
>> patch.
> 
> So this makes more sense. Your current patch is fixing 22cc5ca5de52. But
> nothing breaks currently, only after you switch to including paravirt-base.h
> and not the big fat header.
> 
> Which means that the patch at the beginning of this thread should be the first
> patch in your io set, it should have a Fixes: tag but we should NOT send it to
> stable because nothing breaks there.
> 
> Your io patchset, at a quick glance, is cleanups so it won't go to stable
> either so no need for that fix to go stable either.
> 
> Does that sound like a good strategy?
> 

Fine with me.

I'll change the commit message to:

   Commit 22cc5ca5de52 ("x86/paravirt: Move halt paravirt calls under
   CONFIG_PARAVIRT") moved some paravirt hooks from the CONFIG_PARAVIRT_XXL
   umbrella to CONFIG_PARAVIRT, but missed to move the associated
   "#include <asm/paravirt.h>" in irqflags.h from CONFIG_PARAVIRT_XXL to
   CONFIG_PARAVIRT.

   This hasn't resulted in build failures yet, as all use cases of irqflags.h
   had paravirt.h included via other header files, even without
   CONFIG_PARAVIRT_XXL being set.

   In order to allow changing those other header files, e.g. by no longer
   including paravirt.h, fix irqflags.h by moving inclusion of paravirt.h
   under the CONFIG_PARAVIRT umbrella.

Is that fine with you?


Juergen

On Mon, Jan 19, 2026 at 05:02:22PM +0100, Jürgen Groß wrote:
> I'll change the commit message to:
> 
>   Commit 22cc5ca5de52 ("x86/paravirt: Move halt paravirt calls under
>   CONFIG_PARAVIRT") moved some paravirt hooks from the CONFIG_PARAVIRT_XXL
>   umbrella to CONFIG_PARAVIRT, but missed to move the associated
>   "#include <asm/paravirt.h>" in irqflags.h from CONFIG_PARAVIRT_XXL to
>   CONFIG_PARAVIRT.
> 
>   This hasn't resulted in build failures yet, as all use cases of irqflags.h
>   had paravirt.h included via other header files, even without
>   CONFIG_PARAVIRT_XXL being set.
> 
>   In order to allow changing those other header files, e.g. by no longer
>   including paravirt.h, fix irqflags.h by moving inclusion of paravirt.h
>   under the CONFIG_PARAVIRT umbrella.
> 
> Is that fine with you?

Yap, LGTM.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

On 19.01.26 14:28, Borislav Petkov wrote:
> On Mon, Jan 19, 2026 at 12:52:50PM +0100, Jürgen Groß wrote:
>> So do you want me to resend the series triggering the issue with this patch
>> prepended, or are you fine with applying this patch to the tip branch for
>> the next merge window, and wait for the other series to get the needed Acks?
> 
> Or, you could redesign your set in a way so that the build error doesn't
> happen and there's no need for an urgent patch with a questionable Fixes: tag?
> 
> Also, the "pure luck" thing would need debugging too, to figure out why the
> build error happens.
> 

Well, the patch IS the fix for the build error.

paravirt.h just needs to be included if CONFIG_PARAVIRT is set. It isn't
enough to include it only if CONFIG_PARAVIRT_XXL is set.

The patch listed under "Fixes:" moved the halt related functions from the
CONFIG_PARAVIRT_XXL to the CONFIG_PARAVIRT umbrella, but missed to move
the #include of paravirt.h, too. This is what my patch is doing.


Juergen