Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 12/09, Eric W. Biederman wrote:
>>
>> Oleg below is my proof of concept patch, which really needs to be
>> broken up into a whole patch series, so the changes are small
>> enough we can do a thorough audit on them. Anyway take a look
>> and see what
On 12/09, Eric W. Biederman wrote:
>
> Oleg below is my proof of concept patch, which really needs to be
> broken up into a whole patch series, so the changes are small
> enough we can do a thorough audit on them. Anyway take a look
> and see what you think.
Amazing ;)
This patch certainly needs
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 12/09, Eric W. Biederman wrote:
>>
>> Equally messed up is a our status in /proc at that point. Which
>> says our sleeping process is a zombie.
>
> Yes, this is annoying.
>
>> I'm thinking we need to do at least some of the thread group leadership
>>
On 12/09, Eric W. Biederman wrote:
>
> Equally messed up is a our status in /proc at that point. Which
> says our sleeping process is a zombie.
Yes, this is annoying.
> I'm thinking we need to do at least some of the thread group leadership
> transfer in do_exit, instead of de_thread. Then p->g
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 12/08, Eric W. Biederman wrote:
>>
>> Oleg Nesterov <[EMAIL PROTECTED]> writes:
>>
>> > p->exit_state != 0 doesn't mean this process is dead, it may have
> sub-threads.
>> >
>> > However, the new "p->exit_state && thread_group_empty(p)" check is not
On 12/08, Eric W. Biederman wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> writes:
>
> > p->exit_state != 0 doesn't mean this process is dead, it may have
> > sub-threads.
> >
> > However, the new "p->exit_state && thread_group_empty(p)" check is not
> > correct
> > either, this is just the tempor
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> p->exit_state != 0 doesn't mean this process is dead, it may have sub-threads.
>
> However, the new "p->exit_state && thread_group_empty(p)" check is not correct
> either, this is just the temporary hack. Perhaps we can just remove this
> check,
> but I
p->exit_state != 0 doesn't mean this process is dead, it may have sub-threads.
However, the new "p->exit_state && thread_group_empty(p)" check is not correct
either, this is just the temporary hack. Perhaps we can just remove this check,
but I don't understand orphaned process groups magic. At all
8 matches
Mail list logo