linux-kernel - Re: Regression: system freeze on resume from suspend introduced by printk per-console suspended state

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: <trinity-1a192a62-60e6-4c78-a0fb-2705ba7f6832-1769217761219@3c-app-mailcom-bs16>
Date: Sat, 24 Jan 2026 02:22:41 +0100
From: ysard <ysard_git@....fr>
To: Petr Mladek <pmladek@...e.com>
Cc: John Ogness <john.ogness@...utronix.de>, linux-kernel@...r.kernel.org,
 senozhatsky@...omium.org
Subject: Re: Regression: system freeze on resume from suspend introduced by
 printk per-console suspended state

On Fri 2026-01-23 13:19:34 +0100, Petr Mladek wrote:
> Also I would expect that the userspace waits until the services
> finish the job before suspending the kernel.

It does:

    janv. 24 00:33:41 systemd[1]: Reached target sleep.target - Sleep.
    janv. 24 00:33:41 systemd[1]: Starting nvidia-suspend.service - NVIDIA system suspend actions...
    janv. 24 00:33:41 suspend[51525]: nvidia-suspend.service
    janv. 24 00:33:41 logger[51525]: <13>Jan 24 00:33:41 suspend: nvidia-suspend.service
    janv. 24 00:33:42 kernel: audit: type=1400 audit(1769211222.373:2351): apparmor="ALLOWED" operation="open" class="file" profile="Xorg" name="/dev/nvidiactl" pid=1441 comm="Xorg" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
    janv. 24 00:33:42 kernel: audit: type=1400 audit(1769211222.969:2352): apparmor="ALLOWED" operation="open" class="file" profile="Xorg" name="/dev/nvidiactl" pid=1441 comm="Xorg" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
    janv. 24 00:33:45 systemd[1]: nvidia-suspend.service: Deactivated successfully.
    janv. 24 00:33:45 systemd[1]: Finished nvidia-suspend.service - NVIDIA system suspend actions.
    janv. 24 00:33:45 systemd[1]: Starting systemd-suspend.service - System Suspend...
    janv. 24 00:33:45 systemd[1]: session-1.scope: Unit now frozen-by-parent.
    janv. 24 00:33:45 systemd[1]: user@...0.service: Unit now frozen-by-parent.
    janv. 24 00:33:45 systemd[1]: user-1000.slice: Unit now frozen-by-parent.
    janv. 24 00:33:45 systemd[1]: user.slice: Unit now frozen.
    janv. 24 00:33:45 systemd-sleep[51562]: Successfully froze unit 'user.slice'.
    janv. 24 00:33:45 systemd-sleep[51562]: Performing sleep operation 'suspend'...
    janv. 24 00:33:45 kernel: PM: suspend entry (deep)


> >     #!/bin/bash
> >
> >     if [ ! -f /proc/driver/nvidia/suspend ]; then
> >         exit 0
> >     fi
> >
> >     RUN_DIR="/var/run/nvidia-sleep"
> >     XORG_VT_FILE="${RUN_DIR}"/Xorg.vt_number
> >
> >     PATH="/bin:/usr/bin"
> >
> >     case "$1" in
> >         suspend|hibernate)
> >             mkdir -p "${RUN_DIR}"
> >             fgconsole > "${XORG_VT_FILE}"
> >             chvt 63
> >             if [[ $? -ne 0 ]]; then
> >                 exit $?
> >             fi
> >             echo "$1" > /proc/driver/nvidia/suspend
> >             exit $?
> >             ;;
> >         resume)
> >             echo "$1" > /proc/driver/nvidia/suspend
> >             #
> >             # Check if Xorg was determined to be running at the time
> >             # of suspend, and whether its VT was recorded.  If so,
> >             # attempt to switch back to this VT.
> >             #
> >             if [[ -f "${XORG_VT_FILE}" ]]; then
> >                 XORG_PID=$(cat "${XORG_VT_FILE}")
> >                 rm "${XORG_VT_FILE}"
> >                 chvt "${XORG_PID}"
> >             fi
> >             exit 0
>
> I just wonder. Could you please try to comment out the various
> commands here and bisect whether the problem is with
> "fgconsole", "chvt", or "echo XXX >/proc/driver/nvidia/suspend"
> commands.
>
> I mean to try to disable the counter parts in the suspend/resume
> code paths and try whether the freeze is still reproducible?

Yes I have a reproducible pattern here. With the service disabled.
The service `nvidia-resume.service` (which basically calls the script
with the 'resume' argument) is expected to start if the resume is 
completed, but the system does not reach this stage during the freeze.

No freeze:
    $ sudo sh -c "
    mkdir -p /var/run/nvidia-sleep \
    && echo 2 > /var/run/nvidia-sleep/Xorg.vt_number \
    && chvt 63 \
    && systemctl suspend"

Freeze:
    $ sudo sh -c "
    mkdir -p /var/run/nvidia-sleep \
    && echo 2 > /var/run/nvidia-sleep/Xorg.vt_number \
    && chvt 63 \
    && echo suspend >/proc/driver/nvidia/suspend \
    && systemctl suspend"

So the problem is related to this command:
    $ echo suspend >/proc/driver/nvidia/suspend

Note that without the systemctl order this command suspends and wakes up the gpu correctly:
    $ sudo sh -c "
    chvt 63 \
    && echo suspend >/proc/driver/nvidia/suspend; \
    sleep 4; \
    echo resume >/proc/driver/nvidia/suspend; \
    chvt 2"


Best regards.