linux-kernel - Re: [RFC 3/4] Input: Ignore the KEY_POWER events if hibernation is in progress

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: <552ba489-a876-4ef1-b23f-93cbe8ef6c93@kernel.org>
Date: Wed, 22 Oct 2025 11:40:13 -0500
From: Mario Limonciello <superm1@...nel.org>
To: Muhammad Usama Anjum <usama.anjum@...labora.com>,
 "Rafael J. Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>,
 Pavel Machek <pavel@...nel.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Danilo Krummrich <dakr@...nel.org>,
 Dmitry Torokhov <dmitry.torokhov@...il.com>,
 Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra <peterz@...radead.org>,
 linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-pm@...r.kernel.org, linux-input@...r.kernel.org
Cc: kernel@...labora.com
Subject: Re: [RFC 3/4] Input: Ignore the KEY_POWER events if hibernation is in
 progress

On 10/22/25 11:33 AM, Muhammad Usama Anjum wrote:
> On 10/22/25 2:14 AM, Mario Limonciello (AMD) (kernel.org) wrote:
>>
>>
>> On 10/18/2025 9:21 AM, Muhammad Usama Anjum wrote:
>>> Serio drivers call input_handle_event(). Although the serio drivers have
>>> duplicate events, they have separate code path and call
>>> input_handle_event(). Ignore the KEY_POWER such that this event isn't
>>> sent to the userspace if hibernation is in progress.
>>>
>>> Abort the hibernation by calling pm awake API as well.
>>
>> So do you observe events both from ACPI and from input?  Or was this patch based upon an earlier version of the ACPI patch?
> Yes, I observe events from both ACPI and input driver when power button is pressed.
> AFAIU this happens because of historic reasons of button wired through keyboard
> controller.
> 
> The call to pm_wakeup_dev_event() can be removed. But I've added it for non-ACPI
> devices. Maybe those devices handle only input events through this path. Do you
> think this can be the case?

Well my point was if both are coming through - it's probably better to 
just have pm_wakeup_dev_event() in input and pass the input event from ACPI.

>   >
>> Because it feels like to me perhaps another way to solve this would be for patch 2 to to send the input event and just keep pm_wakeup_dev_event() here instead of both places.
> I was sending input event in patch 2 earlier. I was having difficulty in managing
> so many dependencies in acpi_button_notify(). It suspends the button events. I'll
> reiterate and see if I can achieve this in next series because this would be most
> clean solution.

OK!

> 
>>
>>>
>>> Without this, the event is sent to the userspace and it suspends the
>>> device after hibernation cancellation.
>>>
>>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@...labora.com>
>>> ---
>>>    drivers/input/input.c | 6 ++++++
>>>    1 file changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/input/input.c b/drivers/input/input.c
>>> index a500e1e276c21..0979f18aae6a2 100644
>>> --- a/drivers/input/input.c
>>> +++ b/drivers/input/input.c
>>> @@ -26,6 +26,7 @@
>>>    #include <linux/kstrtox.h>
>>>    #include <linux/mutex.h>
>>>    #include <linux/rcupdate.h>
>>> +#include <linux/suspend.h>
>>>    #include "input-compat.h"
>>>    #include "input-core-private.h"
>>>    #include "input-poller.h"
>>> @@ -362,6 +363,11 @@ void input_handle_event(struct input_dev *dev,
>>>          lockdep_assert_held(&dev->event_lock);
>>>    +    if (code == KEY_POWER && hibernation_in_progress()) {
>>> +        pm_wakeup_dev_event(&dev->dev, 0, true);
>>> +        return;
>>> +    }
>>> +
>>>        disposition = input_get_disposition(dev, type, code, &value);
>>>        if (disposition != INPUT_IGNORE_EVENT) {
>>>            if (type != EV_SYN)
>>
> 
>