>> But,my patch has another purpose,protect some key variables(such
>> as:task->mm,task->nsproxy,etc) to recover init coredump from
>> fulldump,if sub-threads finish do_exit(),
> Yes I know.
> But the purpose of this SIGNAL_GROUP_EXIT check is not clear and not
> documented. That is why I said
Hi,
On 03/23, qianli zhao wrote:
>
> Hi,Oleg
>
> > You certainly don't understand me :/
>
> > Please read my email you quoted below. I didn't mean the current logic.
> > I meant the logic after your patch which moves atomic_dec_and_test() and
> > panic() before exit_signals().
>
> Sorry, I think
Hi,Oleg
> You certainly don't understand me :/
> Please read my email you quoted below. I didn't mean the current logic.
> I meant the logic after your patch which moves atomic_dec_and_test() and
> panic() before exit_signals().
Sorry, I think I see what you mean now.
You mean that after apply
On 03/23, qianli zhao wrote:
>
> Hi,Oleg
>
> > No, there is at least one alive init thread. If they all have exited, we
> > have
> > the thread which calls panic() above.
>
> By current logic, setting PF_EXITING(exit_signals()) is before the
> panic(),
You certainly don't understand me :/
Hi,Oleg
> No, there is at least one alive init thread. If they all have exited, we have
> the thread which calls panic() above.
By current logic, setting PF_EXITING(exit_signals()) is before the
panic(),find_alive_thread() determines the PF_EXITING of all child
threads, the panic thread's
On 03/22, Oleg Nesterov wrote:
>
> On 03/22, qianli zhao wrote:
> >
> > Moving the decrement position should only affect between new and old
> > code position of movement of the decrement of
> > signal->live.
>
> Why do you think so? It can affect _any_ code which runs under
> "if (group_dead)".
On 03/22, qianli zhao wrote:
>
> Moving the decrement position should only affect between new and old
> code position of movement of the decrement of
> signal->live.
Why do you think so? It can affect _any_ code which runs under
"if (group_dead)". Again, I don't see anything wrong, but I didn't
Hi,
It seems that we don't understand each other.
If we move atomic_dec_and_test(signal->live) and do
if (group_dead && is_global_init)
panic(...);
before setting PF_EXITING like your patch does, then zap_pid_ns_processes()
simply won't be called.
Because:
On 03/21,
Hi,Eric,Oleg
> It is a bit tricky to tell if the movement of the decrement of
> signal->live is safe
It is hard to say whether it is safe or not,below are just a few of my thoughts
> That affects current_is_single threaded
> which is used by unshare, setns of the time namespace, and setting
>
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
On 03/19, qianli zhao wrote:
>
> I will think about the risks of movement of the decrement of
> signal->live before exit_signal().
> If is difficult to judge movement of the decrement of signal->live is
> safe,how about only test 'signal->live==1' not use group_dead?
>
> Such as:
> diff --git
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
On 03/18, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
>
> > On 03/18, qianli zhao wrote:
> >>
> >> In addition, the patch also protects the init process state to
> >> successfully get usable init coredump.
> >
> > Could you spell please?
> >
> > Does this connect to SIGNAL_GROUP_EXIT
Hi,Eric
> As I understand it this patch has two purposes:
> 1. Avoid the BUG_ON in zap_pid_ns_processes when !CONFIG_PID_NS
> 2. panic as early as possible so exiting threads don't removing
> interesting debugging state.
Your understanding is very correct,this is what my patch wants to do
> I
Hi,Oleg
> 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
Oleg Nesterov writes:
> On 03/18, qianli zhao wrote:
>>
>> Hi,Oleg
>>
>> Thank you for your reply.
>>
>> >> When init sub-threads running on different CPUs exit at the same time,
>> >> zap_pid_ns_processe()->BUG() may be happened.
>>
>> > and why do you think your patch can't prevent this?
>>
>>
On 03/18, qianli zhao wrote:
>
> Hi,Oleg
>
> Thank you for your reply.
>
> >> When init sub-threads running on different CPUs exit at the same time,
> >> zap_pid_ns_processe()->BUG() may be happened.
>
> > and why do you think your patch can't prevent this?
>
> > Sorry, I must have missed
Hi,Oleg
Thank you for your reply.
>> When init sub-threads running on different CPUs exit at the same time,
>> zap_pid_ns_processe()->BUG() may be happened.
> and why do you think your patch can't prevent this?
> Sorry, I must have missed something. But it seems to me that you are trying
> to
On 03/17, Qianli Zhao wrote:
>
> From: Qianli Zhao
>
> When init sub-threads running on different CPUs exit at the same time,
> zap_pid_ns_processe()->BUG() may be happened.
and why do you think your patch can't prevent this?
Sorry, I must have missed something. But it seems to me that you are
From: Qianli Zhao
When init sub-threads running on different CPUs exit at the same time,
zap_pid_ns_processe()->BUG() may be happened.
And every thread status is abnormal after exit(PF_EXITING set,task->mm=NULL
etc),
which makes it difficult to parse coredump from fulldump normally.
In order to
20 matches
Mail list logo
