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
