linux-kernel - Can ETIME be returned instead of EBUSY in the kernel suspend flow?

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>] [day] [month] [year] [list]

Message-ID: <CACkwYU2PqXouAe9QPSMkE3he9magn2hDfLiKSOC7FBJT6QDPWw@mail.gmail.com>
Date: Tue, 30 Jan 2024 13:13:14 -0800
From: Pranav Prasad <pranavpp@...gle.com>
To: rafael@...nel.org, pavel@....cz, len.brown@...el.com, 
	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Kelly Rossmoyer <krossmo@...gle.com>, John Stultz <jstultz@...gle.com>
Subject: Can ETIME be returned instead of EBUSY in the kernel suspend flow?

Hi!

I am proposing a patch in which I want to return the errno code ETIME instead of
EBUSY in enter_state() in the kernel suspend flow. Currently, EBUSY is returned
when an imminent alarm is pending which is checked in alarmtimer_suspend() in
alarmtimer.c. The proposed patch series moves the check to enter_state() in
suspend.c to catch a potential suspend failure early in the suspend
flow. I want to
replace EBUSY with ETIME to make it more diagnosable in userspace, and may
be more appropriate considering a timer is about to expire.

I am reaching out to get an opinion from the suspend maintainers if this would
act as any potential risk in the suspend flow which only has EBUSY, EAGAIN, and
EINVAL as return error codes currently. The patch of interest is attached with
this email. Thank you!

Regards,
Pranav Prasad

Download attachment "Proposed_ETIME_Solution.patch" of type "application/octet-stream" (6760 bytes)