Messages in this thread | | | From | qianli zhao <> | Date | Thu, 11 Mar 2021 12:40:49 +0800 | Subject | Re: [PATCH] exit: trigger panic when init process is set to SIGNAL_GROUP_EXIT |
| |
Hi, Eric Thank you for your suggestion
> At the start of your changelog and your patch subject you describe what > you are doing but not why. For the next revision of the patch please > lead with the why it makes what you are trying to do much easier to > understand.
got it.
> > It does not work to use SIGNAL_UNKILLABLE for this. Normally init > has SIGNAL_UNKILLABLE set. The only case that clears SIGNAL_UNKILLABLE > is force_sig_info_to_task. If the init process exits with exit(2) > SIGNAL_UNKILLABLE will already be set. Which means testing > SIGNAL_UNKILLABLE as your patch does will prevent the panic. >
Ok,using SIGNAL_UNKILLABLE is incorrect.
> Further simply calling panic is sufficient to guarantee that the other > threads don't exit, and that whichever thread calls panic first > will be the reporting thread. The rest of the threads will be caught > in panic_smp_self_stop(), if they happen to be running on other cpus. > > So I would make the whole thing just be: > > /* If global init has exited, > * panic immediately to get a useable coredump. > */ > if (unlikely(is_global_init(tsk) && > (thread_group_empty(tsk) || > (tsk->signal->flags & SIGNAL_GROUP_EXIT)))) { > panic("Attempted to kill init! exitcode=0x%08x\n", > tsk->signal->group_exit_code ?: (int)code); > } > > The thread_group_empty test is needed to handle single threaded > inits. > > Do you think you can respin your patch as something like that? >
Ok.it's a very good change,other CPUs calls to panic() will be caught and execute panic_smp_self_stop(), there is no need to deal with this situation separately when other CPUs exit().
| |