Re: [PATCH] Only send pdeath_signal when getppid changes.
On 4/10/07, Roland McGrath <[EMAIL PROTECTED]> wrote: > Does a parent death signal make most sense between separately written programs? I don't think it does. It has always seemed an utterly cockamamy feature to me, and I've never understood what actually motivated it. It's useful, but the other case is more important. > Does a parent death signal make most sense between processes that are part of > a larger program. That is the only way I can really see it being used. The only actual example of use I know is what Albert Cahalan reported. To my mind, the only semantics that matter for pdeath_signal are what previous uses expected in the past and still need for compatibility. If we started with a fresh rationale from the ground up on what the feature is good for, I am rather skeptical it would pass muster to be added today. Until inotify and dnotify work on /proc/12345/task, there really isn't an alternative for some of us. Polling is unusable. Ideally one could pick any container, session, process group, mm, task group, or task for notification of state change. State change means various things like destruction, addition of something new, exec, etc. (stuff one can see in /proc) With appropriate privs, having the debug-related stuff would be good as well. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Only send pdeath_signal when getppid changes.
> Does a parent death signal make most sense between separately written > programs? I don't think it does. It has always seemed an utterly cockamamy feature to me, and I've never understood what actually motivated it. > Does a parent death signal make most sense between processes that are part of > a larger program. That is the only way I can really see it being used. The only actual example of use I know is what Albert Cahalan reported. To my mind, the only semantics that matter for pdeath_signal are what previous uses expected in the past and still need for compatibility. If we started with a fresh rationale from the ground up on what the feature is good for, I am rather skeptical it would pass muster to be added today. Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Only send pdeath_signal when getppid changes.
Oleg Nesterov <[EMAIL PROTECTED]> writes: > On 04/10, Eric W. Biederman wrote: >> >> So this patch fixes the pdeath_signal behaviour only sending a signal >> when the results of getppid would change. > > Don't get me wrong, I personally like this patch very much. However, Good point. I guess we have a simple question. Does a parent death signal make most sense between separately written programs? If so this patch is a bug fix. Does a parent death signal make most sense between processes that are part of a larger program. If so there is little point to this patch. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Only send pdeath_signal when getppid changes.
On 04/10, Eric W. Biederman wrote: > > So this patch fixes the pdeath_signal behaviour only sending a signal > when the results of getppid would change. Don't get me wrong, I personally like this patch very much. However, A long ago, Albert Cahalan (cc-ed) wrote: > > I rely on thread-to-thread pdeath notification for my emulator. > I also need notification on loss of a thread-group or mm, so I do > my best to emulate those based on thread-to-thread notification. > > ... > > The way I use it pdeath_signal: > > The parent is one of many tasks within a task group. > The child is not within that thread group, but shares VM. > (the child is single threaded, existing only to get the signal) > For each task in the thread group, there is a child task > waiting for parent death notification. (there are two other > tasks sharing VM but not in the task group: one to do > async memory searching, and one to communicate with > a user interface for debugging -- like an interactive valgrind) Oleg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Only send pdeath_signal when getppid changes.
Currently each thread can requrest to be notified when it's parent
terminates, and receive a thread specific signal when that occurs.
That we set this on a per thread granularity and then send it to the
whole thread group seems silly, but whatever.
Currently we send a signal when the results of getppid don't change if
our parent thread dies and we are reparented to a different thread.
This seems counterintuitive to what I would expect when programming in
user space and is a major maitenance issue to continue doing.
The only users I recall using this have non threaded parents and
pdeath_signal predates CLONE_THREAD so arguably this code has been
broken with threaded parents since the day CLONE_THREAD was introduced
and no one ever screamed loudly enough to get it fixed.
So this patch fixes the pdeath_signal behaviour only sending a signal
when the results of getppid would change.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
This patch is against 2.6.21-rc6-mm1 (with utrace applied)
but except for context in the diff that should not matter.
kernel/exit.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/exit.c b/kernel/exit.c
index 1d91de8..1ec0d1f 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -618,10 +618,6 @@ choose_new_parent(struct task_struct *p, struct
task_struct *reaper)
static void
reparent_thread(struct task_struct *p, struct task_struct *father)
{
- if (p->pdeath_signal)
- /* We already hold the tasklist_lock here. */
- group_send_sig_info(p->pdeath_signal, SEND_SIG_NOINFO, p);
-
/* Move the child from its dying parent to the new one. */
list_move_tail(>sibling, >parent->children);
@@ -635,6 +631,10 @@ reparent_thread(struct task_struct *p, struct task_struct
*father)
if (p->exit_signal != -1)
p->exit_signal = SIGCHLD;
+ if (p->pdeath_signal)
+ /* We already hold the tasklist_lock here. */
+ group_send_sig_info(p->pdeath_signal, SEND_SIG_NOINFO, p);
+
/* If we'd notified the old parent about this child's death,
* also notify the new parent.
*/
--
1.5.0.g53756
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Only send pdeath_signal when getppid changes.
Currently each thread can requrest to be notified when it's parent
terminates, and receive a thread specific signal when that occurs.
That we set this on a per thread granularity and then send it to the
whole thread group seems silly, but whatever.
Currently we send a signal when the results of getppid don't change if
our parent thread dies and we are reparented to a different thread.
This seems counterintuitive to what I would expect when programming in
user space and is a major maitenance issue to continue doing.
The only users I recall using this have non threaded parents and
pdeath_signal predates CLONE_THREAD so arguably this code has been
broken with threaded parents since the day CLONE_THREAD was introduced
and no one ever screamed loudly enough to get it fixed.
So this patch fixes the pdeath_signal behaviour only sending a signal
when the results of getppid would change.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
This patch is against 2.6.21-rc6-mm1 (with utrace applied)
but except for context in the diff that should not matter.
kernel/exit.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/exit.c b/kernel/exit.c
index 1d91de8..1ec0d1f 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -618,10 +618,6 @@ choose_new_parent(struct task_struct *p, struct
task_struct *reaper)
static void
reparent_thread(struct task_struct *p, struct task_struct *father)
{
- if (p-pdeath_signal)
- /* We already hold the tasklist_lock here. */
- group_send_sig_info(p-pdeath_signal, SEND_SIG_NOINFO, p);
-
/* Move the child from its dying parent to the new one. */
list_move_tail(p-sibling, p-parent-children);
@@ -635,6 +631,10 @@ reparent_thread(struct task_struct *p, struct task_struct
*father)
if (p-exit_signal != -1)
p-exit_signal = SIGCHLD;
+ if (p-pdeath_signal)
+ /* We already hold the tasklist_lock here. */
+ group_send_sig_info(p-pdeath_signal, SEND_SIG_NOINFO, p);
+
/* If we'd notified the old parent about this child's death,
* also notify the new parent.
*/
--
1.5.0.g53756
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Only send pdeath_signal when getppid changes.
On 04/10, Eric W. Biederman wrote: So this patch fixes the pdeath_signal behaviour only sending a signal when the results of getppid would change. Don't get me wrong, I personally like this patch very much. However, A long ago, Albert Cahalan (cc-ed) wrote: I rely on thread-to-thread pdeath notification for my emulator. I also need notification on loss of a thread-group or mm, so I do my best to emulate those based on thread-to-thread notification. ... The way I use it pdeath_signal: The parent is one of many tasks within a task group. The child is not within that thread group, but shares VM. (the child is single threaded, existing only to get the signal) For each task in the thread group, there is a child task waiting for parent death notification. (there are two other tasks sharing VM but not in the task group: one to do async memory searching, and one to communicate with a user interface for debugging -- like an interactive valgrind) Oleg. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Only send pdeath_signal when getppid changes.
Oleg Nesterov [EMAIL PROTECTED] writes: On 04/10, Eric W. Biederman wrote: So this patch fixes the pdeath_signal behaviour only sending a signal when the results of getppid would change. Don't get me wrong, I personally like this patch very much. However, Good point. I guess we have a simple question. Does a parent death signal make most sense between separately written programs? If so this patch is a bug fix. Does a parent death signal make most sense between processes that are part of a larger program. If so there is little point to this patch. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Only send pdeath_signal when getppid changes.
Does a parent death signal make most sense between separately written programs? I don't think it does. It has always seemed an utterly cockamamy feature to me, and I've never understood what actually motivated it. Does a parent death signal make most sense between processes that are part of a larger program. That is the only way I can really see it being used. The only actual example of use I know is what Albert Cahalan reported. To my mind, the only semantics that matter for pdeath_signal are what previous uses expected in the past and still need for compatibility. If we started with a fresh rationale from the ground up on what the feature is good for, I am rather skeptical it would pass muster to be added today. Thanks, Roland - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Only send pdeath_signal when getppid changes.
On 4/10/07, Roland McGrath [EMAIL PROTECTED] wrote: Does a parent death signal make most sense between separately written programs? I don't think it does. It has always seemed an utterly cockamamy feature to me, and I've never understood what actually motivated it. It's useful, but the other case is more important. Does a parent death signal make most sense between processes that are part of a larger program. That is the only way I can really see it being used. The only actual example of use I know is what Albert Cahalan reported. To my mind, the only semantics that matter for pdeath_signal are what previous uses expected in the past and still need for compatibility. If we started with a fresh rationale from the ground up on what the feature is good for, I am rather skeptical it would pass muster to be added today. Until inotify and dnotify work on /proc/12345/task, there really isn't an alternative for some of us. Polling is unusable. Ideally one could pick any container, session, process group, mm, task group, or task for notification of state change. State change means various things like destruction, addition of something new, exec, etc. (stuff one can see in /proc) With appropriate privs, having the debug-related stuff would be good as well. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
