From: qianli zhao <zhaoqianligood@gmail.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: christian@brauner.io, axboe@kernel.dk,
"Eric W. Biederman" <ebiederm@xmission.com>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Collingbourne <pcc@google.com>,
linux-kernel@vger.kernel.org, Qianli Zhao <zhaoqianli@xiaomi.com>
Subject: Re: [PATCH V3] exit: trigger panic when global init has exited
Date: Sun, 21 Mar 2021 21:04:04 +0800 [thread overview]
Message-ID: <CAPx_LQGLYx8gKJSkCx9hTyPPbCbU=GJL31TPb3s6zxro522U0Q@mail.gmail.com> (raw)
In-Reply-To: <20210319163225.GB19971@redhat.com>
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 <oleg@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.
>
next prev parent reply other threads:[~2021-03-21 13:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-17 12:51 [PATCH V3] exit: trigger panic when global init has exited Qianli Zhao
2021-03-17 14:38 ` Oleg Nesterov
2021-03-18 2:47 ` qianli zhao
2021-03-18 18:04 ` Oleg Nesterov
2021-03-18 19:08 ` Eric W. Biederman
2021-03-19 6:33 ` qianli zhao
2021-03-19 16:34 ` Oleg Nesterov
2021-03-19 16:26 ` Oleg Nesterov
2021-03-21 16:00 ` qianli zhao
2021-03-22 17:07 ` Oleg Nesterov
2021-03-22 17:09 ` Oleg Nesterov
2021-03-19 5:08 ` qianli zhao
2021-03-19 16:32 ` Oleg Nesterov
2021-03-21 13:04 ` qianli zhao [this message]
2021-03-22 16:37 ` Oleg Nesterov
2021-03-23 3:14 ` qianli zhao
2021-03-23 9:00 ` Oleg Nesterov
2021-03-23 11:23 ` qianli zhao
2021-03-24 18:12 ` Oleg Nesterov
2021-03-25 3:00 ` qianli zhao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPx_LQGLYx8gKJSkCx9hTyPPbCbU=GJL31TPb3s6zxro522U0Q@mail.gmail.com' \
--to=zhaoqianligood@gmail.com \
--cc=axboe@kernel.dk \
--cc=christian@brauner.io \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=pcc@google.com \
--cc=tglx@linutronix.de \
--cc=zhaoqianli@xiaomi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).