REGRESSION on linux-next (next-20260115)

REGRESSION on linux-next (next-20260115)

[Borah, Chaitanya Kumar]

Hello all,

Hope you are doing well. I am Chaitanya from the linux graphics team in 
Intel.

This mail is regarding a regression we are seeing in our CI runs[1] on
linux-next repository.

Since the version next-20260115 [2], we are seeing the following regression

`````````````````````````````````````````````````````````````````````````````````
<4>[   23.283209] ------------[ cut here ]------------
<4>[   23.283226] WARNING: kernel/irq/manage.c:1502 at 
__setup_irq+0x5a0/0x850, CPU#0: (udev-worker)/246
...
<4>[   23.283398] Call Trace:
<4>[   23.283403]  <TASK>
<4>[   23.283420]  ? __pfx_int0002_irq+0x10/0x10 [intel_int0002_vgpio]
<4>[   23.283442]  request_threaded_irq+0x117/0x230
<4>[   23.283467]  devm_request_threaded_irq+0x7b/0x120
<4>[   23.283480]  ? __pfx_int0002_irq+0x10/0x10 [intel_int0002_vgpio]
<4>[   23.283501]  int0002_probe+0xde/0x200 [intel_int0002_vgpio]
<4>[   23.283524]  platform_probe+0x43/0xa0
<4>[   23.283541]  really_probe+0xf1/0x410
<4>[   23.283560]  __driver_probe_device+0x8c/0x190
<4>[   23.283576]  driver_probe_device+0x24/0xd0
<4>[   23.283592]  __driver_attach+0x10f/0x240
<4>[   23.283605]  ? __pfx___driver_attach+0x10/0x10
<4>[   23.283618]  bus_for_each_dev+0x7f/0xe0
<4>[   23.283639]  driver_attach+0x1e/0x30
<4>[   23.283651]  bus_add_driver+0x163/0x2a0
<4>[   23.283669]  driver_register+0x5e/0x130
<4>[   23.283678]  ? __pfx_int0002_driver_init+0x10/0x10 
[intel_int0002_vgpio]
<4>[   23.283693]  __platform_driver_register+0x1e/0x30
<4>[   23.283705]  int0002_driver_init+0x1c/0xff0 [intel_int0002_vgpio]
<4>[   23.283719]  do_one_initcall+0x5e/0x3a0
<4>[   23.283747]  do_init_module+0x97/0x2b0
<4>[   23.283764]  load_module+0x2dd3/0x2ee0
<4>[   23.283811]  ? kernel_read_file+0x2b1/0x320
<4>[   23.283835]  init_module_from_file+0xf4/0x120
<4>[   23.283845]  ? init_module_from_file+0xf4/0x120
<4>[   23.283885]  idempotent_init_module+0x117/0x330
<4>[   23.283926]  __x64_sys_finit_module+0x73/0xf0
<4>[   23.283944]  x64_sys_call+0x1d68/0x26b0
<4>[   23.283954]  do_syscall_64+0x93/0x1470
<4>[   23.283969]  ? lock_release+0xcd/0x280
<4>[   23.283979]  ? handle_mm_fault+0x1e7/0x300
<4>[   23.284006]  ? irqentry_exit+0x17d/0x7c0
<4>[   23.284024]  ? exc_page_fault+0xbb/0x250
<4>[   23.284039]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
<4>[   23.284049] RIP: 0033:0x7f298172728d
`````````````````````````````````````````````````````````````````````````````````
Detailed log can be found in [3].

After bisecting the tree, the following patch [4] seems to be the first 
"bad" commit

`````````````````````````````````````````````````````````````````````````````````````````````````````````
commit aef30c8d569c0f31715447525640044c74feb26f
Author: Sebastian Andrzej Siewior bigeasy@linutronix.de
Date:   Mon Jan 12 14:40:13 2026 +0100


     genirq: Warn about using IRQF_ONESHOT without a threaded handler
`````````````````````````````````````````````````````````````````````````````````````````````````````````

Looking at the irq register code in int0002_vgpio.c, it seems the 
warning comes from

         ret = devm_request_irq(dev, irq, int0002_irq,
                                IRQF_ONESHOT | IRQF_SHARED, "INT0002", 
chip);

Looking at the history, this flag was added by the Commit 8f812373d195 
("platform/x86: intel: int0002_vgpio: Pass IRQF_ONESHOT to 
request_irq()") to resolve another issue.

Any proposals for solving the WARN_ON?

Thank you.

Regards

Chaitanya

[1]
https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20260115
[3]
https://intel-gfx-ci.01.org/tree/linux-next/next-20260115/fi-bsw-n3050/boot0.txt
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20260115&id=aef30c8d569c0f31715447525640044c74feb26f 

Re: REGRESSION on linux-next (next-20260115)

[Sebastian Andrzej Siewior]

On 2026-01-21 12:42:16 [+0530], Borah, Chaitanya Kumar wrote:
> commit aef30c8d569c0f31715447525640044c74feb26f
> Author: Sebastian Andrzej Siewior bigeasy@linutronix.de
> Date:   Mon Jan 12 14:40:13 2026 +0100
> 
> 
>     genirq: Warn about using IRQF_ONESHOT without a threaded handler
> `````````````````````````````````````````````````````````````````````````````````````````````````````````
> 
> Looking at the irq register code in int0002_vgpio.c, it seems the warning
> comes from
> 
>         ret = devm_request_irq(dev, irq, int0002_irq,
>                                IRQF_ONESHOT | IRQF_SHARED, "INT0002", chip);
> 
> Looking at the history, this flag was added by the Commit 8f812373d195
> ("platform/x86: intel: int0002_vgpio: Pass IRQF_ONESHOT to request_irq()")
> to resolve another issue.
> 
> Any proposals for solving the WARN_ON?

Do you have the ACPI interrupt also on the same interrupt on the board
in question?

Sebastian

Re: REGRESSION on linux-next (next-20260115)

[Borah, Chaitanya Kumar]

On 1/21/2026 1:23 PM, Sebastian Andrzej Siewior wrote:
> On 2026-01-21 12:42:16 [+0530], Borah, Chaitanya Kumar wrote:
>> commit aef30c8d569c0f31715447525640044c74feb26f
>> Author: Sebastian Andrzej Siewior bigeasy@linutronix.de
>> Date:   Mon Jan 12 14:40:13 2026 +0100
>>
>>
>>      genirq: Warn about using IRQF_ONESHOT without a threaded handler
>> `````````````````````````````````````````````````````````````````````````````````````````````````````````
>>
>> Looking at the irq register code in int0002_vgpio.c, it seems the warning
>> comes from
>>
>>          ret = devm_request_irq(dev, irq, int0002_irq,
>>                                 IRQF_ONESHOT | IRQF_SHARED, "INT0002", chip);
>>
>> Looking at the history, this flag was added by the Commit 8f812373d195
>> ("platform/x86: intel: int0002_vgpio: Pass IRQF_ONESHOT to request_irq()")
>> to resolve another issue.
>>
>> Any proposals for solving the WARN_ON?
> 
> Do you have the ACPI interrupt also on the same interrupt on the board
> in question?
> 

Looks like it.
   9:          1          0  IO-APIC   9-fasteoi   acpi, INT0002

==
Chaitanya

> Sebastian

Re: REGRESSION on linux-next (next-20260115)

[Sebastian Andrzej Siewior]

On 2026-01-21 13:59:38 [+0530], Borah, Chaitanya Kumar wrote:
> 
> Looks like it.
>   9:          1          0  IO-APIC   9-fasteoi   acpi, INT0002

Does the following help?

diff --git a/drivers/platform/x86/intel/int0002_vgpio.c b/drivers/platform/x86/intel/int0002_vgpio.c
index 6f5629dc3f8db..562e880256436 100644
--- a/drivers/platform/x86/intel/int0002_vgpio.c
+++ b/drivers/platform/x86/intel/int0002_vgpio.c
@@ -206,8 +206,8 @@ static int int0002_probe(struct platform_device *pdev)
 	 * FIXME: augment this if we managed to pull handling of shared
 	 * IRQs into gpiolib.
 	 */
-	ret = devm_request_irq(dev, irq, int0002_irq,
-			       IRQF_ONESHOT | IRQF_SHARED, "INT0002", chip);
+	ret = devm_request_irq(dev, irq, int0002_irq, IRQF_SHARED, "INT0002",
+			       chip);
 	if (ret) {
 		dev_err(dev, "Error requesting IRQ %d: %d\n", irq, ret);
 		return ret;
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 266f2b39213a0..b2bb878abd113 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -228,7 +228,7 @@ static inline int __must_check
 devm_request_irq(struct device *dev, unsigned int irq, irq_handler_t handler,
 		 unsigned long irqflags, const char *devname, void *dev_id)
 {
-	return devm_request_threaded_irq(dev, irq, handler, NULL, irqflags,
+	return devm_request_threaded_irq(dev, irq, handler, NULL, irqflags | IRQF_COND_ONESHOT,
 					 devname, dev_id);
 }
 
My guess would be that the int0002_vgpio.c results in a warning without
requesting the interrupt while the interrupt.h change should fix it and
the warning should be gone.

> ==
> Chaitanya

Sebastian

Re: REGRESSION on linux-next (next-20260115)

[Hans de Goede]

Hi,

On 21-Jan-26 10:01, Sebastian Andrzej Siewior wrote:
> On 2026-01-21 13:59:38 [+0530], Borah, Chaitanya Kumar wrote:
>>
>> Looks like it.
>>   9:          1          0  IO-APIC   9-fasteoi   acpi, INT0002
> 
> Does the following help?
> 
> diff --git a/drivers/platform/x86/intel/int0002_vgpio.c b/drivers/platform/x86/intel/int0002_vgpio.c
> index 6f5629dc3f8db..562e880256436 100644
> --- a/drivers/platform/x86/intel/int0002_vgpio.c
> +++ b/drivers/platform/x86/intel/int0002_vgpio.c
> @@ -206,8 +206,8 @@ static int int0002_probe(struct platform_device *pdev)
>  	 * FIXME: augment this if we managed to pull handling of shared
>  	 * IRQs into gpiolib.
>  	 */
> -	ret = devm_request_irq(dev, irq, int0002_irq,
> -			       IRQF_ONESHOT | IRQF_SHARED, "INT0002", chip);
> +	ret = devm_request_irq(dev, irq, int0002_irq, IRQF_SHARED, "INT0002",
> +			       chip);
>  	if (ret) {
>  		dev_err(dev, "Error requesting IRQ %d: %d\n", irq, ret);
>  		return ret;
> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> index 266f2b39213a0..b2bb878abd113 100644
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -228,7 +228,7 @@ static inline int __must_check
>  devm_request_irq(struct device *dev, unsigned int irq, irq_handler_t handler,
>  		 unsigned long irqflags, const char *devname, void *dev_id)
>  {
> -	return devm_request_threaded_irq(dev, irq, handler, NULL, irqflags,
> +	return devm_request_threaded_irq(dev, irq, handler, NULL, irqflags | IRQF_COND_ONESHOT,
>  					 devname, dev_id);
>  }
>  
> My guess would be that the int0002_vgpio.c results in a warning without
> requesting the interrupt while the interrupt.h change should fix it and
> the warning should be gone.

Right, so as the commit message of commit 8f812373d195 ("platform/x86: intel:
int0002_vgpio: Pass IRQF_ONESHOT to request_irq()") explains
the int0002_vgpio driver *must* use the same flags to request
the IRQ as the ACPI core does, which is why it passes IRQF_ONESHOT
even though it does not have a threaded handler.

This worked fine until commit aef30c8d569c ("genirq: Warn about using
IRQF_ONESHOT without a threaded handler") as Chaitanya's bisect
pointed out.

Sebastian as I agree that switching to IRQF_COND_ONESHOT on
the int0002_vgpio.c side is a good way to fix this.

But If I'm reading your proposed changes correct then your suggestion
is to drop IRQF_ONESHOT from int0002_vgpio.c and then instead of
replacing it with IRQF_COND_ONESHOT you want to always pass
IRQF_COND_ONESHOT when using the non-threaded request_irq functions?

I'm not objecting against this, just making sure I understand
correctly.

Note in that case you should also add this to the non devm_
prefixed version.

Regards,

Hans

Re: REGRESSION on linux-next (next-20260115)

[Sebastian Andrzej Siewior]

On 2026-01-21 11:20:53 [+0100], Hans de Goede wrote:
> Hi,
Hi,

> Right, so as the commit message of commit 8f812373d195 ("platform/x86: intel:
> int0002_vgpio: Pass IRQF_ONESHOT to request_irq()") explains
> the int0002_vgpio driver *must* use the same flags to request
> the IRQ as the ACPI core does, which is why it passes IRQF_ONESHOT
> even though it does not have a threaded handler.
> 
> This worked fine until commit aef30c8d569c ("genirq: Warn about using
> IRQF_ONESHOT without a threaded handler") as Chaitanya's bisect
> pointed out.

Avoiding forced-threading on the int0002_vgpio handler is actually a
problem on PREEMPT_RT. But yeah no complains from the stack.

> Sebastian as I agree that switching to IRQF_COND_ONESHOT on
> the int0002_vgpio.c side is a good way to fix this.
> 
> But If I'm reading your proposed changes correct then your suggestion
> is to drop IRQF_ONESHOT from int0002_vgpio.c and then instead of
> replacing it with IRQF_COND_ONESHOT you want to always pass
> IRQF_COND_ONESHOT when using the non-threaded request_irq functions?

Correct.

> I'm not objecting against this, just making sure I understand
> correctly.
> 
> Note in that case you should also add this to the non devm_
> prefixed version.

You mean request_irq() as it has been done in commit
   c37927a203fa2 ("genirq: Set IRQF_COND_ONESHOT in request_irq()")

or did I miss yet another wrapper?

> Regards,
> 
> Hans

Sebastian

Re: REGRESSION on linux-next (next-20260115)

[Hans de Goede]

Hi,

On 21-Jan-26 11:39, Sebastian Andrzej Siewior wrote:
> On 2026-01-21 11:20:53 [+0100], Hans de Goede wrote:
>> Hi,
> Hi,
> 
>> Right, so as the commit message of commit 8f812373d195 ("platform/x86: intel:
>> int0002_vgpio: Pass IRQF_ONESHOT to request_irq()") explains
>> the int0002_vgpio driver *must* use the same flags to request
>> the IRQ as the ACPI core does, which is why it passes IRQF_ONESHOT
>> even though it does not have a threaded handler.
>>
>> This worked fine until commit aef30c8d569c ("genirq: Warn about using
>> IRQF_ONESHOT without a threaded handler") as Chaitanya's bisect
>> pointed out.
> 
> Avoiding forced-threading on the int0002_vgpio handler is actually a
> problem on PREEMPT_RT. But yeah no complains from the stack.
> 
>> Sebastian as I agree that switching to IRQF_COND_ONESHOT on
>> the int0002_vgpio.c side is a good way to fix this.
>>
>> But If I'm reading your proposed changes correct then your suggestion
>> is to drop IRQF_ONESHOT from int0002_vgpio.c and then instead of
>> replacing it with IRQF_COND_ONESHOT you want to always pass
>> IRQF_COND_ONESHOT when using the non-threaded request_irq functions?
> 
> Correct.
> 
>> I'm not objecting against this, just making sure I understand
>> correctly.
>>
>> Note in that case you should also add this to the non devm_
>> prefixed version.
> 
> You mean request_irq() as it has been done in commit
>    c37927a203fa2 ("genirq: Set IRQF_COND_ONESHOT in request_irq()")

Yes I meant plain request_irq(), I was not aware this was already
done there.

Regards,

Hans

Re: REGRESSION on linux-next (next-20260115)

[Borah, Chaitanya Kumar]

On 1/21/2026 2:31 PM, Sebastian Andrzej Siewior wrote:
> On 2026-01-21 13:59:38 [+0530], Borah, Chaitanya Kumar wrote:
>>
>> Looks like it.
>>    9:          1          0  IO-APIC   9-fasteoi   acpi, INT0002
> 
> Does the following help?
> 
> diff --git a/drivers/platform/x86/intel/int0002_vgpio.c b/drivers/platform/x86/intel/int0002_vgpio.c
> index 6f5629dc3f8db..562e880256436 100644
> --- a/drivers/platform/x86/intel/int0002_vgpio.c
> +++ b/drivers/platform/x86/intel/int0002_vgpio.c
> @@ -206,8 +206,8 @@ static int int0002_probe(struct platform_device *pdev)
>   	 * FIXME: augment this if we managed to pull handling of shared
>   	 * IRQs into gpiolib.
>   	 */
> -	ret = devm_request_irq(dev, irq, int0002_irq,
> -			       IRQF_ONESHOT | IRQF_SHARED, "INT0002", chip);
> +	ret = devm_request_irq(dev, irq, int0002_irq, IRQF_SHARED, "INT0002",
> +			       chip);
>   	if (ret) {
>   		dev_err(dev, "Error requesting IRQ %d: %d\n", irq, ret);
>   		return ret;
> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> index 266f2b39213a0..b2bb878abd113 100644
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -228,7 +228,7 @@ static inline int __must_check
>   devm_request_irq(struct device *dev, unsigned int irq, irq_handler_t handler,
>   		 unsigned long irqflags, const char *devname, void *dev_id)
>   {
> -	return devm_request_threaded_irq(dev, irq, handler, NULL, irqflags,
> +	return devm_request_threaded_irq(dev, irq, handler, NULL, irqflags | IRQF_COND_ONESHOT,
>   					 devname, dev_id);
>   }
>   
> My guess would be that the int0002_vgpio.c results in a warning without
> requesting the interrupt while the interrupt.h change should fix it and
> the warning should be gone.
> 

This helps. Thank you for the patch. Would you be floating it soon?

==
Chaitanya

Re: REGRESSION on linux-next (next-20260115)

[Sebastian Andrzej Siewior]

On 2026-01-21 17:43:50 [+0530], Borah, Chaitanya Kumar wrote:
> This helps. Thank you for the patch. Would you be floating it soon?

Yes, I will. I consider this as a tested-by.

Sebastian