All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Filipe Brandenburger <filbranden@gmail.com>
Cc: Tejun Heo <tj@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] prctl: pdeath_signal sent when parent thread (instead of parent process) dies
Date: Mon, 4 Jun 2012 18:15:16 +0200	[thread overview]
Message-ID: <20120604161516.GA11243@redhat.com> (raw)
In-Reply-To: <CABe66sWwvCq=vWq5=ojbgHZeG764BGvts0cMJExTVrTeHRS+KA@mail.gmail.com>

Hi Filipe,

On 06/01, Filipe Brandenburger wrote:
>
> On Fri, Jun 1, 2012 at 3:02 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> > Filipe, you can't even imagine how much do I like this change
> > personally ;) Although I think that pdeath_signal code should
> > be moved into reparent_leader(). I suggested this many times.
>
> Yes, that would really make sense!

Forgot to mention, and we should make ->pdeath_signal per-process.

> > But I was told there are users which depend on current behaviour,
> > they really want to know when the parent _thread_ exits.
>
> Hmmm... but is it the parent thread inside the same process or the
> thread of the parent process that forked it?

It is the parent thread inside the same process which forked the
child initially. Assuming you are asking about the exiting "father"
thread.

> doesn't really make any
> sense to me...

Same here ;) that is why I tried to change this logic too.

Parent/child relationship is process-wide. task->parent points to
the thread, but this is just the technical detail and it is only
needed because we have __WNOTHREAD (see do_wait).

IOW. I think we should move ->pdeath_signal from task_struct to
signal_struct, and then do

	--- x/kernel/exit.c
	+++ x/kernel/exit.c
	@@ -770,6 +770,9 @@ static void reparent_leader(struct task_
		if (same_thread_group(p->real_parent, father))
			return;
	 
	+	if (p->signal->pdeath_signal)
	+		group_send_sig_info(p->signal->pdeath_signal, SEND_SIG_NOINFO, p);
	+
		/* We don't want people slaying init.  */
		p->exit_signal = SIGCHLD;
	 
	@@ -806,9 +809,6 @@ static void forget_original_parent(struc
					BUG_ON(t->ptrace);
					t->parent = t->real_parent;
				}
	-			if (t->pdeath_signal)
	-				group_send_sig_info(t->pdeath_signal,
	-						    SEND_SIG_NOINFO, t);
			} while_each_thread(p, t);
			reparent_leader(father, p, &dead_children);
		}

Oleg.


  reply	other threads:[~2012-06-04 16:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-29 22:59 [PATCH 1/1] prctl: pdeath_signal sent when parent thread (instead of parent process) dies Filipe Brandenburger
2012-06-01 19:02 ` Oleg Nesterov
2012-06-01 20:00   ` Filipe Brandenburger
2012-06-04 16:15     ` Oleg Nesterov [this message]
2012-06-12  1:28 ` [PATCHv2 0/1] prctl: move pdeath_signal from task_struct to signal_struct Filipe Brandenburger
2012-06-12  1:28 ` [PATCHv2 1/1] " Filipe Brandenburger
2012-06-12 16:19   ` Oleg Nesterov
2012-06-13 15:46     ` Albert Cahalan
2012-06-15  3:57       ` Filipe Brandenburger

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=20120604161516.GA11243@redhat.com \
    --to=oleg@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=filbranden@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rientjes@google.com \
    --cc=tj@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.