Hi,Oleg
> How? Perhaps I missed something again, but I don't think this is possible.
> zap_pid_ns_processes() simply won't be called, find_child_reaper() will
> see the !PF_EXITING thread which calls panic().
> So I think this should be documented somehow, at least in the changelog.
This problem occurs when both two init threads enter the do_exit,
One of the init thread is syscall sys_exit_group,and set SIGNAL_GROUP_EXIT
The other init thread perform ret_to_user()->get_signal() and found
SIGNAL_GROUP_EXIT is set,then do_group_exit()->do_exit(),since there
are no alive init threads it finally goes to
zap_pid_ns_processes() and BUG().
Please refer to the sequence diagram below(that has been written into
the changelog),and callstack is also below:
kernel log:
[ 24.705376] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00007f00
[ 24.705382] CPU: 4 PID: 552 Comm: init Tainted: G S O
4.14.180-perf-g4483caa8ae80-dirty #1
[ 24.705390] kernel BUG at include/linux/pid_namespace.h:98!
PID: 1 TASK: ffffffc973126900 CPU: 7 COMMAND: "init"
#0 [ffffff800805ba60] perf_trace_kernel_panic_late at ffffff99ac0bcbcc
#1 [ffffff800805bac0] die at ffffff99ac08dc64
#2 [ffffff800805bb10] bug_handler at ffffff99ac08e398
#3 [ffffff800805bbc0] brk_handler at ffffff99ac08529c
#4 [ffffff800805bc80] do_debug_exception at ffffff99ac0814e4
->exception
/home/work/courbet-r-stable-build/kernel/msm-4.14/include/linux/pid_namespace.h:
98
96static inline void zap_pid_ns_processes(struct pid_namespace *ns)
97{
98 BUG();
99}
#5 [ffffff800805bdf0] el1_dbg at ffffff99ac083298
#6 [ffffff800805be20] do_exit at ffffff99ac0c22e8
#7 [ffffff800805be80] do_group_exit at ffffff99ac0c2658
#8 [ffffff800805beb0] sys_exit_group at ffffff99ac0c266c
#9 [ffffff800805bff0] el0_svc_naked at ffffff99ac083cfc
PID: 552 TASK: ffffffc9613c8f00 CPU: 4 COMMAND: "init"
#0 [ffffff801455b870] __delay at ffffff99ad32cc14
#1 [ffffff801455b8b0] __const_udelay at ffffff99ad32cd10
#2 [ffffff801455b8c0] msm_trigger_wdog_bite at ffffff99ac5d5be0
#3 [ffffff801455b980] do_msm_restart at ffffff99acccc3f8
#4 [ffffff801455b9b0] machine_restart at ffffff99ac085dd0
#5 [ffffff801455b9d0] emergency_restart at ffffff99ac0eb6dc
#6 [ffffff801455baf0] panic at ffffff99ac0bd008
========> /home/work/courbet-r-stable-build/kernel/msm-4.14/kernel/exit.c:
842
836 if (group_dead) {
837 /*
838 * If the last thread of global init has exited, panic
839 * immediately to get a useable coredump.
840 */
841 if (unlikely(is_global_init(tsk)))
842 panic("Attempted to kill init! exitcode=0x%08x\n",
843 tsk->signal->group_exit_code ?: (int)code);
#7 [ffffff801455bb70] do_exit at ffffff99ac0c257c
#8 [ffffff801455bbd0] do_group_exit at ffffff99ac0c2644
#9 [ffffff801455bcc0] get_signal at ffffff99ac0d1384
#10 [ffffff801455be60] do_notify_resume at ffffff99ac08b2a8
#11 [ffffff801455bff0] work_pending at ffffff99ac083b8c
core4 core7
... sys_exit_group()
do_group_exit()
- sig->flags = SIGNAL_GROUP_EXIT
- zap_other_threads()
do_exit() //PF_EXITING is set
ret_to_user()
do_notify_resume()
get_signal()
- signal_group_exit
- goto fatal;
do_group_exit()
do_exit() //PF_EXITING is set
- panic("Attempted to kill init! exitcode=0x%08x\n")
exit_notify()
find_alive_thread() //no alive
sub-threads
zap_pid_ns_processes()
//CONFIG_PID_NS is not set
BUG()
Oleg Nesterov <o...@redhat.com> 于2021年3月20日周六 上午12:32写道：
>
> On 03/19, qianli zhao wrote:
> >
> > > But then I don't understand the SIGNAL_GROUP_EXIT check added by your
> > > patch. Do we really need it if we want to avoid zap_pid_ns_processes()
> > > when the global init exits?
> >
> > I think check SIGNAL_GROUP_EXIT is necessary,or panic() will happen
> > after all init sub-threads do_exit(),so the following two situations
> > will happen:
> > 1.According to the timing in the changelog,
> > zap_pid_ns_processes()->BUG() maybe happened.
>
> How? Perhaps I missed something again, but I don't think this is possible.
>
> zap_pid_ns_processes() simply won't be called, find_child_reaper() will
> see the !PF_EXITING thread which calls panic().
>
> So I think this should be documented somehow, at least in the changelog.
>
> Oleg.
>
