linux-kernel - Re:Re: [PATCH] genirq: Fix gpio irq will fail to be resend under certain conditions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Tue, 11 Jun 2024 23:41:53 +0800 (CST)
From: zzz  <luuiiruo@....com>
To: "Thomas Gleixner" <tglx@...utronix.de>
Cc: linux-kernel@...r.kernel.org
Subject: Re:Re: [PATCH] genirq: Fix gpio irq will fail to be resend under
 certain conditions

tglx,
    I'm sorry for my vague description. First, let me answer your questions.

>This has nothing to do with GPIO interrupts. It's a general problem
>vs. resend, no?
Yes, i think it's a general interrupts problem, but i found it while testing gpio interrupts.

>So what you are saying is:
>An interrupt is disabled, but the wakeup function of the interrupt is
>enabled, right?
Yes.

>Now the system enters suspend and the interrupt is raised, which
>triggers the wakeup function, right?
Yes.

>Now the system enters suspend nevertheless. How can that happen?
Although the device is woken up by gpio irq, it may re-enter suspend after some time.

>Due to that the IRQS_REPLAY flag will be set. How so? IRQS_REPLAY is
>only set from the resend function.
When entering suspend , the path is as follows:
suspend_device_irqs()
    suspend_device_irq()
        __enable_irq()
            irq_startup()
                check_irq_resend()   --IRQS_REPLAY flag is set in this function.

>Due to that IRQS_REPLAY will not be cleared because the irq_may_run()
>condition is not cleared. Sure, but how does any of this happen in the
>first place?
I will show you a complete process.

>Before you send me a decipherable description of the problem, let me ask
>you a few obvious questions:
>  1) Why is the interrupt disabled _and_ marked as wakeup interrupt?
I have a pin named DATA.
When there is no connection, DATA needs to be a recognition function, the 
interrupt enabled and wakeup are used here.
When there is connection, DATA is used communication function, the interrupt 
disabled and wakeup are used here.

>  2) If it should still wakeup the system even if disabled, then the
>     interrupt chip should have the IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND
>     flag set. That's not the case, right?
No, IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND flag will be set.


Second, I wil show you complete process by timeline:

1.device is suspend, irq disable, wakeup enable, every state is normal now;

2.device is suspend, irq disable, wakeup enable, irq raised and trigger wakeup, 
IRQS_PENDING flag will be set;

3.device is active, irq disable, wakeup enable, devices enter suspend afte some 
time, this step will executes check_irq_resend(), IRQS_REPLAY flag will be set. 
Please refer to the paths listed above.
And check_irq_resend() will call handle_fasteoi_irq(), but irq_may_run() return false,
so IRQS_REPLAY flag not be clear.

4.device is suspend, irq disable, wakeup enable, device wakeup again, we set irq 
enable, and let device enter suspend;

5.device is suspend, irq enable, wakeup enable, irq raised and trigger wakeup, will 
executes check_irq_resend(), but IRQS_REPLAY flag is set, so irq thread_fn() will not 
be executes.


Thanks!
zzz