Re: [PATCH v4 2/2] arm64: show signal info for global init

[chenqiwu <qiwuchen55@gmail.com>]

On Wed, Sep 25, 2024 at 02:05:47PM +0200, Oleg Nesterov wrote:
> > >
> > Yes, this patch just try to bypass the show_unhandled_signals and
> > __ratelimit() checks for the global init.
> 
> I think the changelog should explain this.
>
Sure, I will explain this in the changelog of patch v5 if someone else
would ACK this patch.

> But this doesn't look right to me, see below.
> 
> > > OTOH. The is_global_init() check in unhandled_signal() (which predates the git
> > > history) doesn't look right to me. If init has a handler for, say, SIGSEGV, why
> > > should the kernel complain? I need to recheck this logic...
> > >
> > I think the orignal logic is the signal sent to the global init is
> > regarded as unhandled becuase it has SIGNAL_UNKILLABLE feature.
> 
> And? How does this relate to SIGNAL_UNKILLABLE? Again, this check predates
> the git history and the SIGNAL_UNKILLABLE feature. And SIGNAL_UNKILLABLE
> has no effect in this case, see force_sig_info_to_task().
>
Thanks for your explaination!

For the report on ARM64 KVM, the signal sent to the global init by
arm4_force_sig() and the global init do_exit by get_signal().
However, it doesn't show signal info due to show_unhandled_signals
check, because the initial value of show_unhandled_signals is 0
which can be adjusted by /proc/sys/debug/exception-trace in root mode.
In ARM64 productive environment, the default value of show_unhandled_signals
is set to 0 in case of show_unhandled_signals storms, and the debuggers
cannot adjust it dynamically by shell in non-root mode.

Considering the minor case of kill init, this change won't have any
side effect. Let's to see the ARM64 maintainers if really like it :)

Thanks
Qiwu