Received-SPF: pass (google.com: domain of linux-kernel+bounces-206216-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240607105906.4192924-1-quic_faiyazm@quicinc.com>
In-Reply-To: <20240607105906.4192924-1-quic_faiyazm@quicinc.com>
From: =?UTF-8?B?7J2064+Z66+8?= <ldmldm05@gmail.com>
Date: Fri, 7 Jun 2024 23:05:07 +0900
Message-ID: <CACmEs-4mntpn8SQVgx5Qv9W8cmWQ__=1ds_j=vXxcDp27=SXLA@mail.gmail.com>
Subject: Re: [PATCH] kernel/reboot: enhance dmesg logging for system restart
To: Faiyaz Mohammed <quic_faiyazm@quicinc.com>
Cc: benjamin.bara@skidata.com, dmitry.osipenko@collabora.com, lee@kernel.org, 
	daniel.lezcano@linaro.org, j.granados@samsung.com, 
	linux-kernel@vger.kernel.org, dongmin.lee@linux.dev
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 7, 2024 at 7:59=E2=80=AFPM Faiyaz Mohammed <quic_faiyazm@quicin=
c.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=E2=80=99
>
> 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/