linux-kernel - Re: [PATCH] Input: gpio-keys - fix a sleep while atomic with PREEMPT

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]

Message-ID: <bd6c5a45-f6ee-4cdc-99fe-6af22e30015b@foss.st.com>
Date: Wed, 28 May 2025 09:55:38 +0200
From: Gatien CHEVALLIER <gatien.chevallier@...s.st.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
CC: Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Clark Williams
	<clrkwllms@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Paul Cercueil
	<paul@...pouillou.net>, <linux-input@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-rt-devel@...ts.linux.dev>,
        Fabrice
 Gasnier <fabrice.gasnier@...s.st.com>
Subject: Re: [PATCH] Input: gpio-keys - fix a sleep while atomic with
 PREEMPT_RT

Hello Sebastian,

On 5/27/25 16:41, Sebastian Andrzej Siewior wrote:
> On 2025-05-27 15:36:37 [+0200], Gatien CHEVALLIER wrote:
>> Hello Sebastian,
> Hello Gatien,
> 
>> Can you elaborate on "This flag change makes not difference on
>> !PREEMPT_RT" please? IIUC,this makes the callback not run in hard IRQ
>> context, even in !PREEMPT_RT, no?
> 
> If you set
> - HRTIMER_MODE_REL_HARD
>    then the callback runs in
>    - hardirq context on !PREEMPT_RT
>    - hardirq context on PREEMPT_RT.
> 
> - HRTIMER_MODE_REL
>    then the callback runs in
>    - hardirq context on !PREEMPT_RT
>    - preemptible softirq on PREEMPT_RT.
> 
> - HRTIMER_MODE_REL_SOFT
>    then the callback runs in
>    - softirq context on !PREEMPT_RT
>    - preemptible softirq on PREEMPT_RT.
> 
> Therefore if you switch HRTIMER_MODE_REL_HARD -> HRTIMER_MODE_REL then
> it is a nop on !PREEMPT_RT.
> 

Thank you for the details.

>> Regarding the need of the spin_lock: gpio_keys_irq_timer() and
>> gpio_keys_irq_isr() appear to access the same resources. Can't we
>> have a concurrent access on it from:
>> HR timer interrupt // GPIO interrupt?
> 
> Yes, it could.
> 
>> But looking back at the patch, this situation does not depend on
>> the HRTIMER_MODE_REL_HARD flag. So maybe it should be addressed
>> separately.
> 
> Yes, please.
> 

Ok, I will do that in V2

>> On the other hand, I should use the new
>> guard(spinlock_irqsave)(&bdata->lock);
> 
> Yes, please. The other instance already does so.
> 
> Sebastian

Ok

Best regards,
Gatien