Re: [PATCH 04/24] PM: hibernate: move finding the resume device out of software_resume

From: Linux regression tracking #adding (Thorsten Leemhuis)
Date: Sat Aug 05 2023 - 09:07:35 EST

[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; the text you find below is based on a few templates
paragraphs you might have encountered already in similar form.
See link in footer if these mails annoy you.]

On 03.08.23 10:27, Vlastimil Babka wrote:
> On 5/31/23 14:55, Christoph Hellwig wrote:
>> software_resume can be called either from an init call in the boot code,
>> or from sysfs once the system has finished booting, and the two
>> invocation methods this can't race with each other.
>> For the latter case we did just parse the suspend device manually, while
>> the former might not have one. Split software_resume so that the search
>> only happens for the boot case, which also means the special lockdep
>> nesting annotation can go away as the system transition mutex can be
>> taken a little later and doesn't have the sysfs locking nest inside it.
>> Signed-off-by: Christoph Hellwig <hch@xxxxxx>
>> Acked-by: Rafael J. Wysocki <rafael@xxxxxxxxxx>
> This caused a regression for me in 6.5-rc1+, fix below.
> ----8<----
>>From 95a310ae6cfae9b3cab61e54a1bce488c3ab93a1 Mon Sep 17 00:00:00 2001
> From: Vlastimil Babka <vbabka@xxxxxxx>
> Date: Wed, 2 Aug 2023 15:46:18 +0200
> Subject: [PATCH] PM: hibernate: fix resume_store() return value when
> hibernation not available
> On a laptop with hibernation set up but not actively used, and with
> secure boot and lockdown enabled kernel, 6.5-rc1 gets stuck on boot with
> the following repeated messages:
> A start job is running for Resume from hibernation using device /dev/system/swap (24s / no limit)
> lockdown_is_locked_down: 25311154 callbacks suppressed
> Lockdown: systemd-hiberna: hibernation is restricted; see man kernel_lockdown.7
> ...
> Checking the resume code leads to commit cc89c63e2fe3 ("PM: hibernate:
> move finding the resume device out of software_resume") which
> inadvertently changed the return value from resume_store() to 0 when
> !hibernation_available(). This apparently translates to userspace
> write() returning 0 as in number of bytes written, and userspace looping
> indefinitely in the attempt to write the intended value.
> Fix this by returning the full number of bytes that were to be written,
> as that's what was done before the commit.
> Fixes: cc89c63e2fe3 ("PM: hibernate: move finding the resume device out of software_resume")
> [...]

Thanks for the report. To be sure the issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
tracking bot:

#regzbot ^introduced cc89c63e2fe3
#regzbot title pm: boot problems when hibernate is configured and kernel
locked down
#regzbot fix: PM: hibernate: fix resume_store() return value when
hibernation not available
#regzbot ignore-activity

This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.

Developers: When fixing the issue, remember to add 'Link:' tags pointing
to the report (the parent of this mail). See page linked in footer for

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
Everything you wanna know about Linux kernel regression tracking:
That page also explains what to do if mails like this annoy you.