linux-kernel - Re: [PATCH] kernel/reboot: enhance dmesg logging for system restart

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

Message-ID: <CACmEs-4mntpn8SQVgx5Qv9W8cmWQ__=1ds_j=vXxcDp27=SXLA@mail.gmail.com>
Date: Fri, 7 Jun 2024 23:05:07 +0900
From: 이동민 <ldmldm05@...il.com>
To: Faiyaz Mohammed <quic_faiyazm@...cinc.com>
Cc: benjamin.bara@...data.com, dmitry.osipenko@...labora.com, lee@...nel.org, 
	daniel.lezcano@...aro.org, j.granados@...sung.com, 
	linux-kernel@...r.kernel.org, dongmin.lee@...ux.dev
Subject: Re: [PATCH] kernel/reboot: enhance dmesg logging for system restart

On Fri, Jun 7, 2024 at 7:59 PM Faiyaz Mohammed <quic_faiyazm@...cinc.com> wrote:
>
> It is useful to add the PID and Comm information along with command info.
>
> Currently, when system reboot kernel logs don not print PID and Comm:
>
> reboot: Restarting system with command 'reboot,scheduled_reboot'
> reboot: Restarting system with command 'RescueParty'
> reboot: Restarting system with command 'bootloader'
> reboot: Restarting system with command 'recovery'
> reboot: Restarting system with command 'userrequested,recovery’
>
> For Example after adding PID and Comm:
>
> reboot: PID: 1 Comm: init Restarting system with command 'shell'
> reboot: PID: 1 Comm: init Restarting system with command 'bootloader'

Printing out PID and COMM information might be useful for getting
which task is triggered system reboot. However, It's never a critical
information that deserves printed with pr_emerg() to whoever want the
system to be rebooted, unless the kernel is in a problematic
situation.

If reboot is called by user space via reboot system call, reboot is
never a problematic situation because it's user's intend in the
kernel's view. Other kernel codes which invokes involuntary restart
such as temperature overheat (drivers/memory/emif.c:622), already
prints out the situation before invoking system_reboot(), hence, there
is no reason to print out who called system_reboot().

Again, system reboot is not kernel panic, oops nor bug. If your intend
is to debug the reboot handler's behavior more easily, just set a
breakpoint for kernel_restart() function with gdb.

--
Best Regards,
Dongmin Lee

https://ldmsys.net/