Re: [PATCH] uio: eliminate extraneous irq thread under CONFIG_PREEMPT_RT

Re: [PATCH] uio: eliminate extraneous irq thread under CONFIG_PREEMPT_RT

[Sebastian Andrzej Siewior]

Chris, what was the use case to split this?

On 2026-08-19 15:01:00 [+0000], Mike Schanne wrote:
> Commit f8a27dfa4b82d442af1c0645a5acc70cc97c67f6 ("uio: use threaded
> interrupts") makes all uio interrupts threaded by default.  However
> under CONFIG_PREEMPT_RT, all interrupts are already threaded.  This
> results in 2 irq threads per uio instance, adding an unnecessary
> extra context switch per interrupt.
> 
> Do not request a threaded interrupt for uio under CONFIG_PREEMPT_RT
> 
> Signed-off-by: Michael Schanne mschanne@kns.com<mailto:mschanne@kns.com>
> ---
> drivers/uio/uio.c | 17 +++++++++++++----
> 1 file changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> index 004a549c6..4e28777ac 100644
> --- a/drivers/uio/uio.c
> +++ b/drivers/uio/uio.c
> @@ -448,8 +448,12 @@ static irqreturn_t uio_interrupt_handler(int irq, void *dev_id)
>                irqreturn_t ret;
>                 ret = idev->info->handler(irq, idev->info);
> -              if (ret == IRQ_HANDLED)
> -                              ret = IRQ_WAKE_THREAD;
> +             if (ret == IRQ_HANDLED) {
> +                             if (IS_ENABLED(CONFIG_PREEMPT_RT))
> +                                             uio_event_notify(idev->info);
> +                             else
> +                                             ret = IRQ_WAKE_THREAD;
> +             }
>                 return ret;
> }
> @@ -1038,8 +1042,13 @@ int __uio_register_device(struct module *owner,
>                                 * FDs at the time of unregister and therefore may not be
>                                 * freed until they are released.
>                                 */
> -                              ret = request_threaded_irq(info->irq, uio_interrupt_handler, uio_interrupt_thread,
> -                                                                                 info->irq_flags, info->name, idev);
> +                             if (IS_ENABLED(CONFIG_PREEMPT_RT)) {
> +                                             ret = request_irq(info->irq, uio_interrupt_handler,
> +                                                             info->irq_flags, info->name, idev);
> +                             } else {
> +                                             ret = request_threaded_irq(info->irq, uio_interrupt_handler, uio_interrupt_thread,
> +                                                             info->irq_flags, info->name, idev);
> +                             }
>                                if (ret) {
>                                                info->uio_dev = NULL;
>                                                goto err_request_irq;

Sebastian

[PATCH] uio: eliminate extraneous irq thread under CONFIG_PREEMPT_RT

[Mike Schanne]

From 435db0a75de98d2021e02381a15a300137a544b3 Mon Sep 17 00:00:00 2001
From: Michael Schanne <mschanne@kns.com>
Date: Wed, 5 Aug 2026 14:34:22 -0400
Subject: [PATCH] uio: eliminate extraneous irq thread under CONFIG_PREEMPT_RT

Commit f8a27dfa4b82d442af1c0645a5acc70cc97c67f6 ("uio: use threaded
interrupts") makes all uio interrupts threaded by default.  However
under CONFIG_PREEMPT_RT, all interrupts are already threaded.  This
results in 2 irq threads per uio instance, adding an unnecessary
extra context switch per interrupt.

Do not request a threaded interrupt for uio under CONFIG_PREEMPT_RT

Signed-off-by: Michael Schanne <mschanne@kns.com>
---
 drivers/uio/uio.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 004a549c6..4e28777ac 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -448,8 +448,12 @@ static irqreturn_t uio_interrupt_handler(int irq, void *dev_id)
        irqreturn_t ret;

        ret = idev->info->handler(irq, idev->info);
-       if (ret == IRQ_HANDLED)
-               ret = IRQ_WAKE_THREAD;
+       if (ret == IRQ_HANDLED) {
+               if (IS_ENABLED(CONFIG_PREEMPT_RT))
+                       uio_event_notify(idev->info);
+               else
+                       ret = IRQ_WAKE_THREAD;
+       }

        return ret;
 }
@@ -1038,8 +1042,13 @@ int __uio_register_device(struct module *owner,
                 * FDs at the time of unregister and therefore may not be
                 * freed until they are released.
                 */
-               ret = request_threaded_irq(info->irq, uio_interrupt_handler, uio_interrupt_thread,
-                                          info->irq_flags, info->name, idev);
+               if (IS_ENABLED(CONFIG_PREEMPT_RT)) {
+                       ret = request_irq(info->irq, uio_interrupt_handler,
+                               info->irq_flags, info->name, idev);
+               } else {
+                       ret = request_threaded_irq(info->irq, uio_interrupt_handler, uio_interrupt_thread,
+                               info->irq_flags, info->name, idev);
+               }
                if (ret) {
                        info->uio_dev = NULL;
                        goto err_request_irq;
--
2.34.1

This email is non-binding, is subject to contract, and neither Kulicke and Soffa Industries, Inc. nor its subsidiaries (each and collectively “K&S”) shall have any obligation to you to consummate the transactions herein or to enter into any agreement, other than in accordance with the terms and conditions of a definitive agreement if and when negotiated, finalized and executed between the parties. This email and all its contents are protected by International and United States copyright laws. Any reproduction or use of all or any part of this email without the express written consent of K&S is prohibited.

Re: [PATCH] uio: eliminate extraneous irq thread under CONFIG_PREEMPT_RT

[Chris Packham]

Hi Sebastian,

On 20/08/2026 03:06, Sebastian Andrzej Siewior wrote:
> Chris, what was the use case to split this?

I was dealing with having a UIO interrupt for an input on a PCA9539. 
There's some more info on the original email thread[1] but basically 
because the PCA9539 inputs are nested __setup_irq() enforces that anyone 
requesting them does so with a threaded interrupt.

https://lore.kernel.org/all/20240408234050.2056374-3-chris.packham@alliedtelesis.co.nz/

>
> On 2026-08-19 15:01:00 [+0000], Mike Schanne wrote:
>> Commit f8a27dfa4b82d442af1c0645a5acc70cc97c67f6 ("uio: use threaded
>> interrupts") makes all uio interrupts threaded by default.  However
>> under CONFIG_PREEMPT_RT, all interrupts are already threaded.  This
>> results in 2 irq threads per uio instance, adding an unnecessary
>> extra context switch per interrupt.
>>
>> Do not request a threaded interrupt for uio under CONFIG_PREEMPT_RT
>>
>> Signed-off-by: Michael Schanne mschanne@kns.com<mailto:mschanne@kns.com>
>> ---
>> drivers/uio/uio.c | 17 +++++++++++++----
>> 1 file changed, 13 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
>> index 004a549c6..4e28777ac 100644
>> --- a/drivers/uio/uio.c
>> +++ b/drivers/uio/uio.c
>> @@ -448,8 +448,12 @@ static irqreturn_t uio_interrupt_handler(int irq, void *dev_id)
>>                 irqreturn_t ret;
>>                  ret = idev->info->handler(irq, idev->info);
>> -              if (ret == IRQ_HANDLED)
>> -                              ret = IRQ_WAKE_THREAD;
>> +             if (ret == IRQ_HANDLED) {
>> +                             if (IS_ENABLED(CONFIG_PREEMPT_RT))
>> +                                             uio_event_notify(idev->info);
>> +                             else
>> +                                             ret = IRQ_WAKE_THREAD;
>> +             }
>>                  return ret;
>> }
>> @@ -1038,8 +1042,13 @@ int __uio_register_device(struct module *owner,
>>                                  * FDs at the time of unregister and therefore may not be
>>                                  * freed until they are released.
>>                                  */
>> -                              ret = request_threaded_irq(info->irq, uio_interrupt_handler, uio_interrupt_thread,
>> -                                                                                 info->irq_flags, info->name, idev);
>> +                             if (IS_ENABLED(CONFIG_PREEMPT_RT)) {
>> +                                             ret = request_irq(info->irq, uio_interrupt_handler,
>> +                                                             info->irq_flags, info->name, idev);
>> +                             } else {
>> +                                             ret = request_threaded_irq(info->irq, uio_interrupt_handler, uio_interrupt_thread,
>> +                                                             info->irq_flags, info->name, idev);
>> +                             }
>>                                 if (ret) {
>>                                                 info->uio_dev = NULL;
>>                                                 goto err_request_irq;
> Sebastian

Re: [PATCH] uio: eliminate extraneous irq thread under CONFIG_PREEMPT_RT

[Sebastian Andrzej Siewior]

On 2026-08-19 20:48:51 [+0000], Chris Packham wrote:
> Hi Sebastian,
Hi Chris,

> On 20/08/2026 03:06, Sebastian Andrzej Siewior wrote:
> > Chris, what was the use case to split this?
> 
> I was dealing with having a UIO interrupt for an input on a PCA9539. 
> There's some more info on the original email thread[1] but basically 
> because the PCA9539 inputs are nested __setup_irq() enforces that anyone 
> requesting them does so with a threaded interrupt.
> 
> https://lore.kernel.org/all/20240408234050.2056374-3-chris.packham@alliedtelesis.co.nz/

so you wrote:

|    Prior to this the UIO registration fails with:
|    
|      [    6.484699] uio_pdrv_genirq detect-gpio-9: unable to register uio device
|      [    6.484722] uio_pdrv_genirq detect-gpio-9: probe with driver uio_pdrv_genirq failed with error -22
|    
|    The -EINVAL ultimately comes from __setup_irq() where it knows the
|    interrupt descriptor is nested but we haven't provided a thread_fn.

So we talk about this piece of kernel/irq/manage.c:

|         /*
|          * Check whether the interrupt nests into another interrupt
|          * thread.
|          */
|         nested = irq_settings_is_nested_thread(desc);
|         if (nested) {
|                 if (!new->thread_fn) {
|                         ret = -EINVAL;
|                         goto out_mput;
|                 }
|                 /*
|                  * Replace the primary handler which was provided from
|                  * the driver for non nested interrupt handling by the
|                  * dummy function which warns when called.
|                  */
|                 new->handler = irq_nested_primary_handler;
|         } else {

If so, you realize that uio_interrupt_handler() isn't called at all?

Sebastian

Re: [PATCH] uio: eliminate extraneous irq thread under CONFIG_PREEMPT_RT

[Ahmed S. Darwish]

On Wed, 19 Aug 2026, Mike Schanne wrote:
> @@ -1038,8 +1042,13 @@ int __uio_register_device(struct module *owner,
>                  * FDs at the time of unregister and therefore may not be
>                  * freed until they are released.
>                  */
> -               ret = request_threaded_irq(info->irq, uio_interrupt_handler, uio_interrupt_thread,
> -                                          info->irq_flags, info->name, idev);
> +               if (IS_ENABLED(CONFIG_PREEMPT_RT)) {
> +                       ret = request_irq(info->irq, uio_interrupt_handler,
> +                               info->irq_flags, info->name, idev);
> +               } else {
> +                       ret = request_threaded_irq(info->irq, uio_interrupt_handler, uio_interrupt_thread,
> +                               info->irq_flags, info->name, idev);
> +               }
>

There should be a better way to do this.

The whole point of PREEMPT_RT is not to add random conditionals like that
inside drivers code.

Thanks,
Ahmed

Re: [PATCH] uio: eliminate extraneous irq thread under CONFIG_PREEMPT_RT

[Sebastian Andrzej Siewior]

On 2026-08-20 16:12:22 [+0200], To Chris Packham wrote:
> 
> If so, you realize that uio_interrupt_handler() isn't called at all?

Mike could you please post a patch which reverts f8a27dfa4b82d ("uio:
use threaded interrupts") because

- it breaks the threadirqs case including PREEMPT_RT 
- I doubt that it solved the reported problem because it does not invoke
  the primary handler of UIO at all because it gets overwritten to
  irq_nested_primary_handler().

As for the Chris case, I would suggest to check the IRQ for
irq_settings_is_nested_thread() and then use request_threaded_irq().

Sebastian