Re: [PATCH 1/4] ptrace: temporary revert the recent ptrace/jobctl rework
On 06/21, Roland McGrath wrote: OK, so here's my (hacky) idea: (1) Forget ptrace-via-utrace. Have utrace be a separate thing. This way the recent ptrace changes won't matter. This is what V2 does. (2) But, what about ptrace co-existing well with utrace? Make them mutually exclusive - a ptraced-process can't be utraced and a utraced-process can't be ptraced. We had this situation before for a while. It has the substantial downside that e.g. you cannot do any system-wide systemtap tracing without making all strace and gdb use impossible. Yes, we can't make them mutually exclusive, this can't work. So V2 tries to teach them play well together. Assuming the above is a semi-reasonable idea, it might be a lot less work than updating the ptrace-via-utrace code to handle the new ptrace changes. That's for Oleg to say. (Sorry, Oleg. ;-) Oh, I am not sure what is simpler ;) Oleg.
Re: [PATCH 1/4] ptrace: temporary revert the recent ptrace/jobctl rework
On 06/21/2011 10:25 AM, Oleg Nesterov wrote: OK, I won't argue. So we need to rework utrace/ptrace in 3.0, then we should do this again in 3.1. I'll try to do something. I have a thought here, I'm not familiar enough with utrace internals to know whether it is a good one or not. Originally, implementing ptrace via utrace was optional - if I remember correctly there was a define that turned it off and on. One of the good things about implementing ptrace-via-utrace is that they co-existed well - you could ptrace a process that you were also using utrace on. If I remember correctly, during one of the utrace reviews, making ptrace-via-utrace optional was requested to be removed. Now with the recent ptrace changes, still implementing ptrace-via-utrace will take some work. OK, so here's my (hacky) idea: (1) Forget ptrace-via-utrace. Have utrace be a separate thing. This way the recent ptrace changes won't matter. (2) But, what about ptrace co-existing well with utrace? Make them mutually exclusive - a ptraced-process can't be utraced and a utraced-process can't be ptraced. Assuming the above is a semi-reasonable idea, it might be a lot less work than updating the ptrace-via-utrace code to handle the new ptrace changes. -- David Smith dsm...@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax)
Re: [PATCH 1/4] ptrace: temporary revert the recent ptrace/jobctl rework
OK, so here's my (hacky) idea: (1) Forget ptrace-via-utrace. Have utrace be a separate thing. This way the recent ptrace changes won't matter. (2) But, what about ptrace co-existing well with utrace? Make them mutually exclusive - a ptraced-process can't be utraced and a utraced-process can't be ptraced. We had this situation before for a while. It has the substantial downside that e.g. you cannot do any system-wide systemtap tracing without making all strace and gdb use impossible. Assuming the above is a semi-reasonable idea, it might be a lot less work than updating the ptrace-via-utrace code to handle the new ptrace changes. That's for Oleg to say. (Sorry, Oleg. ;-) Thanks, Roland
Re: [PATCH 1/4] ptrace: temporary revert the recent ptrace/jobctl rework
On Tue, Jun 21, 2011 at 05:25:19PM +0200, Oleg Nesterov wrote: I understand. Once again, it was supposed to be a temporary solution until fedora switches to 3.1. And the reverted code does not make the real difference so far, the user-visible changes are minor. Yeah, I understand, it just looks bad for us. OK, I won't argue. So we need to rework utrace/ptrace in 3.0, then we should do this again in 3.1. I'll try to do something. I don't think worrying about 3.0 is necessary... it won't ship in anything, and we should be well on our way to 3.1 by the time we branch F-16 in 5 weeks, focusing effort there seems more sensible. (Rawhide will be changing awfully rapidly in the mean time anyway.) --Kyle
[PATCH 1/4] ptrace: temporary revert the recent ptrace/jobctl rework
Temporary revert the following patches to keep utrace/utrace-ptrace working:
40ae717d1e78d982bd469b2013a4cbf4ec1ca434
ptrace: fix signal-wait_chldexit usage in
task_clear_group_stop_trapping()
321fb561971ba0f10ce18c0f8a4b9fbfc7cef4b9
ptrace: ptrace_check_attach() should not do s/STOPPED/TRACED/
ee77f075921730b2b465880f9fd4367003bdab39
signal: Turn SIGNAL_STOP_DEQUEUED into GROUP_STOP_DEQUEUED
780006eac2fe7f4d2582da16a096e5a44c4767ff
signal: do_signal_stop: Remove the unneeded
task_clear_group_stop_pending()
244056f9dbbc6dc4126a301c745fa3dd67d8af3c
job control: Don't send duplicate job control stop notification while
ptraced
ceb6bd67f9b9db765e1c29405f26e8460391badd
job control: Notify the real parent of job control events regardless of
ptrace
62bcf9d992ecc19ea4f37ff57ee0be3e843e
job control: Job control stop notifications should always go to the
real parent
75b95953a56969a990e6ce154b260be83818fe71
job control: Add @for_ptrace to do_notify_parent_cldstop()
45cb24a1da53beb70f09efccc0373f6a47a9efe0
job control: Allow access to job control events through ptracees
9b84cca2564b9a5b2d064fb44d2a55a5b44473a0
job control: Fix ptracer wait(2) hang and explain notask_error clearing
408a37de6c95832a4880a88a742f89f0cc554d06
job control: Don't set group_stop exit_code if re-entering job control
stop
0e9f0a4abfd80f8adca624538d479d95159b16d8
ptrace: Always put ptracee into appropriate execution state
e3bd058f62896ec7a2c605ed62a0a811e9147947
ptrace: Collapse ptrace_untrace() into __ptrace_unlink()
d79fdd6d96f46fabb779d86332e3677c6f5c2a4f
ptrace: Clean transitions between TASK_STOPPED and TRACED
5224fa3660ad3881d2f2ad726d22614117963f10
ptrace: Make do_signal_stop() use ptrace_stop() if the task is being
ptraced
0ae8ce1c8c5b9007ce6bfc83ec2aa0dfce5bbed3
ptrace: Participate in group stop from ptrace_stop() iff the task is
trapping for group stop
39efa3ef3a376a4e53de2f82fc91182459d34200
signal: Use GROUP_STOP_PENDING to stop once for a single group stop
e5c1902e9260a0075ea52cb5ef627a8d9aaede89
signal: Fix premature completion of group stop when interfered by ptrace
fe1bc6a0954611b806f9e158eb0817cf8ba21660
ptrace: Add @why to ptrace_stop()
edf2ed153bcae52de70db00a98b0e81a5668e563
ptrace: Kill tracehook_notify_jctl()
This obviously reverts some user-visible fixes, but the fixed problems
are very old and minor, they were never reported. In the long term we
need another solution.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
fs/exec.c |1 -
include/linux/sched.h | 17 +--
include/linux/tracehook.h | 27
kernel/exit.c | 77 ++-
kernel/ptrace.c | 116 +---
kernel/signal.c | 339 +
6 files changed, 148 insertions(+), 429 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index 6075a1e..82b5379 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1769,7 +1769,6 @@ static int zap_process(struct task_struct *start, int
exit_code)
t = start;
do {
- task_clear_group_stop_pending(t);
if (t != current t-mm) {
sigaddset(t-pending.signal, SIGKILL);
signal_wake_up(t, 1);
diff --git a/include/linux/sched.h b/include/linux/sched.h
index a837b20..6c42e24 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -663,8 +663,9 @@ struct signal_struct {
* Bits in flags field of signal_struct.
*/
#define SIGNAL_STOP_STOPPED0x0001 /* job control stop in effect */
-#define SIGNAL_STOP_CONTINUED 0x0002 /* SIGCONT since WCONTINUED reap */
-#define SIGNAL_GROUP_EXIT 0x0004 /* group exit in progress */
+#define SIGNAL_STOP_DEQUEUED 0x0002 /* stop signal dequeued */
+#define SIGNAL_STOP_CONTINUED 0x0004 /* SIGCONT since WCONTINUED reap */
+#define SIGNAL_GROUP_EXIT 0x0008 /* group exit in progress */
/*
* Pending notifications to parent.
*/
@@ -1283,7 +1284,6 @@ struct task_struct {
int exit_state;
int exit_code, exit_signal;
int pdeath_signal; /* The signal sent when the parent dies */
- unsigned int group_stop;/* GROUP_STOP_*, siglock protected */
/* ??? */
unsigned int personality;
unsigned did_exec:1;
@@ -1803,17 +1803,6 @@ extern void thread_group_times(struct task_struct *p,
cputime_t *ut, cputime_t *
#define tsk_used_math(p) ((p)-flags PF_USED_MATH)
#define used_math() tsk_used_math(current)
-/*
- * task-group_stop flags
- */
-#define GROUP_STOP_SIGMASK 0x/* signr of the last group stop */
-#define GROUP_STOP_PENDING (1 16) /* task should
Re: [PATCH 1/4] ptrace: temporary revert the recent ptrace/jobctl rework
On 06/20, Kyle McMartin wrote: On Mon, Jun 20, 2011 at 06:07:44PM +0200, Oleg Nesterov wrote: Temporary revert the following patches to keep utrace/utrace-ptrace working: huge list of patches here This obviously reverts some user-visible fixes, but the fixed problems are very old and minor, they were never reported. In the long term we need another solution. Dude, that's just not acceptable, that's way too much offset to deal with against upstream, Yes, this reverts 20 patches. But they only touch the ptrace/stop paths, there won't be more changes in this area until 3.1. especially since it's looking like uprobes will get merged in 3.1... Probably yes. In any case, this series should be dropped when fedora switches to 3.1. I'll try to do something more clever for 3.1 if utrace is still needed. Until then we need something for systemtap... Oleg.
Re: [PATCH 1/4] ptrace: temporary revert the recent ptrace/jobctl rework
On Mon, Jun 20, 2011 at 12:16:34PM -0400, Kyle McMartin wrote: On Mon, Jun 20, 2011 at 06:07:44PM +0200, Oleg Nesterov wrote: Temporary revert the following patches to keep utrace/utrace-ptrace working: huge list of patches here This obviously reverts some user-visible fixes, but the fixed problems are very old and minor, they were never reported. In the long term we need another solution. Dude, that's just not acceptable, that's way too much offset to deal with against upstream, especially since it's looking like uprobes will get merged in 3.1... (at least, a lot of the comments seem to have been well-addressed on linux-mm.) I have still yet to see a justification why we want to continue carrying utrace in Fedora at all. And We want it in RHEL isn't a good enough answer. It's been FIVE years that we carried that thing without it getting upstream. What benefit is there in continuing to carry this thing at all ? Utrace has been an absolute disaster from a merging standpoint. Even Xen didn't take this long to get upstream. Dave
Re: [PATCH 1/4] ptrace: temporary revert the recent ptrace/jobctl rework
On 06/20/2011 09:44 AM, Dave Jones wrote: What benefit is there in continuing to carry this thing at all ? Utrace has been an absolute disaster from a merging standpoint. Even Xen didn't take this long to get upstream. I can't dispute the upstream disappointment, but the obvious benefit is enabling uprobes for systemtap. There are a growing number of packages building in markers with systemtap-sdt-devel for debugging and tracing, so they will expect a way to hook into these. Yes, the impending inode-uprobes will be sufficient for this case, but it's a step backwards in other respects as well. Josh
Re: [PATCH 1/4] ptrace: temporary revert the recent ptrace/jobctl rework
On Mon, Jun 20, 2011 at 10:18:26AM -0700, Josh Stone wrote: On 06/20/2011 09:44 AM, Dave Jones wrote: What benefit is there in continuing to carry this thing at all ? Utrace has been an absolute disaster from a merging standpoint. Even Xen didn't take this long to get upstream. I can't dispute the upstream disappointment, but the obvious benefit is enabling uprobes for systemtap. There are a growing number of packages building in markers with systemtap-sdt-devel for debugging and tracing, so they will expect a way to hook into these. Yes, the impending inode-uprobes will be sufficient for this case, but it's a step backwards in other respects as well. I'm sure both the Fedora systemtap users will be bummed if it stops working, but the truth is outside of RHEL, and the people who actually work on systemtap, afaics, no-one gives a damn. Dave
Re: [PATCH 1/4] ptrace: temporary revert the recent ptrace/jobctl rework
On 06/20/2011 10:28 AM, Dave Jones wrote: On Mon, Jun 20, 2011 at 10:18:26AM -0700, Josh Stone wrote: On 06/20/2011 09:44 AM, Dave Jones wrote: What benefit is there in continuing to carry this thing at all ? Utrace has been an absolute disaster from a merging standpoint. Even Xen didn't take this long to get upstream. I can't dispute the upstream disappointment, but the obvious benefit is enabling uprobes for systemtap. There are a growing number of packages building in markers with systemtap-sdt-devel for debugging and tracing, so they will expect a way to hook into these. Yes, the impending inode-uprobes will be sufficient for this case, but it's a step backwards in other respects as well. I'm sure both the Fedora systemtap users will be bummed if it stops working, but the truth is outside of RHEL, and the people who actually work on systemtap, afaics, no-one gives a damn. Packagers are adding these markers of their own accord, and in most cases are getting them upstream as well. It is only kernel developers who are so hostile/apathetic/etc. Josh
Re: [PATCH 1/4] ptrace: temporary revert the recent ptrace/jobctl rework
On Mon, Jun 20, 2011 at 10:43:55AM -0700, Josh Stone wrote: Packagers are adding these markers of their own accord, and in most cases are getting them upstream as well. It is only kernel developers who are so hostile/apathetic/etc. We only deviate from the upstream kernel to fix bugs, backport features or add code that has a clear path to upstream. We do not deviate from the upstream kernel to revert a bunch of upstream fixes in order to add a feature that's been there for half a decade and still isn't upstream, especially when there's been approximately zero user demand for it to appear in Fedora. That's a practical attitude, not a hostile or apathetic one. -- Matthew Garrett | mj...@srcf.ucam.org
