On 09/25, chenqiwu wrote:
>
> On Tue, Sep 24, 2024 at 08:36:35PM +0200, Oleg Nesterov wrote:
> >
> > So what does this patch try to do? Note that unhandled_signal(tsk) returns true
> > if is_global_init(tsk).
> >
> > So it seems that this patch just tries to bypass the show_unhandled_signals and
> > __ratelimit() checks? Or what?
> >
> 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.
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().
I am running this program
void sigh(int sig)
{
printf("SIGSEGV %d\n", getpid());
execl("/usr/bin/sh", "sh", NULL);
printf("exec failed\n");
}
int main(void)
{
signal(SIGSEGV, sigh);
*((char*)(1234)) = 0;
return 1;
}
as a global init under KVM. It works but dmesg reports
init[1]: segfault at 4d2 ip 00000000004006b5 sp 00007ffcf2975170 error 6 in init[6b5,400000+1000] likely on CPU 0 (core 0, socket 0)
Code: e8 c0 fe ff ff bf 6b 07 40 00 e8 56 fe ff ff 90 c9 c3 55 48 89 e5 be 56 06 40 00 bf 0b 00 00 00 e8 80 fe ff ff b8 d2 04 00 00 <c6> 00 00 b8 01 00 00 00 5d c3 90 41 57 41 56 41 89 ff 41 55 41 54
I'll send the patch which removes the is_global_init check from unhandled_signal()
which actually has more problems, afaics. But this all is offtopic.
Oleg.
