lkml.org 
[lkml]   [2012]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectself_exec_id/parent_exec_id && CLONE_PARENT
(change subject)

On 03/11, Oleg Nesterov wrote:
>
> Well, I don't think it is right to add this counter into task_struct.
>
> It should be per-process, signal_struct makes more sense. Or may be
> mm_struct.
>
> Btw this is also true for parent_exec_id/self_exec_id, but this is
> another story.

In fact I think it would be nice to kill parent_exec_id/self_exec_id.

Afaics, this only problem is clone(CLONE_PARENT | SIGXXX). I expect
the answer is "no, can break existing applications", but I'll ask
anyway.

Can't we change this? IOW, can't we modify copy_process

- p->exit_signal = (clone_flags & CLONE_THREAD) ? -1 : (clone_flags & CSIGNAL);
+ p->exit_signal =
+ (clone_flags & CLONE_THREAD) ? -1 :
+ (clobe_flags & CLONE_PARENT) ? current->group_leader->exit_signal :
+ (clone_flags & CSIGNAL);

(or simply use SIGCHLD instead of group_leader->exit_signal).

Then we can kill parent_exec_id/self_exec_id if me modify de_thread()
to set ->exit_signal = SIGCHLD for every child.

I am also asking because the change above looks like the fix to me.
The child must not control its ->exit_signal, it is the parent who
decides which signal the child should use for notification.

And to me, clone(CLONE_PARENT | SIGXXX) looks like a violation of
rule above.

Oleg.



\
 
 \ /
  Last update: 2012-03-11 19:01    [W:0.195 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site