Invitation Vente Privée
Pour ne plus recevoir de courriels de notre part, il vous suffit de vous rendre sur cette page.
Re: [PATCH 5] ptrace: change tracehook_report_syscall_exit() to handle stepping
On 11/23, Srikar Dronamraju wrote: I don't have a powerpc machine, but I think this test-case should see the difference: On a powerpc machine, I did verify that the below test-case differs with your patch. Without the patch it would print the message kernel bug: status=857F shouldn't have 0x80 Great! Thanks a lot. Oleg.
Re: [PATCH 1-13] utrace-ptrace V1, for internal review
On 11/22, Roland McGrath wrote: Perhaps we should send 8-10 to akpm right now? I'm not sure whether that would more useful. It's really up to you. IMHO those are not standalone cleanups like 2-7 (and even 1) are. So to me it makes more sense to have those travel as part of that whole series. Yes, agreed. Oleg.
http://koji.fedoraproject.org/scratch/roland/task_1825649/
At this URL find built rpms (x86_64 and i686 only) that you can install on a Fedora 12 (or rawhide, probably) system. These are the upstream kernel du jour with the current utrace-ptrace branch code (see rpm changelog for commit id). (I tried an f12-flavored build too, but it looks like the current upstream code does not build on ppc.) I tried ptrace-tests on this kernel. step-fork fails as expected, this kernel doesn't have that (utrace-unrelated) upstream fix. On i686, I get no other ptrace-tests failures. On x86_64, detach-sigkill-race consistently fails in tests/ but succeeds in biarch-tests/. Hmm, looks like that fails on stock F-12 kernel (i.e. vanilla ptrace) too, so not a regression. Thanks, Roland
[PATCH 140] join PTRACE_EVENT_SYSCALL_XXX states
No need to to use different ENTRY/EXIT syscall codes any longer.
PTRACE_EVENT_SYSCALL_EXIT was introduced to emulate send_sigtrap()
from syscall_trace_leave(), now we don't do this.
---
kernel/ptrace-utrace.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
--- UTRACE-PTRACE/kernel/ptrace-utrace.c~140_PTRACE_EVENT_SYSCALL
2009-11-21 22:15:51.0 +0100
+++ UTRACE-PTRACE/kernel/ptrace-utrace.c2009-11-23 22:15:21.0
+0100
@@ -70,10 +70,9 @@ struct ptrace_context {
#define PTRACE_O_SYSEMU0x100
-#define PTRACE_EVENT_SYSCALL_ENTRY (1 16)
-#define PTRACE_EVENT_SYSCALL_EXIT (2 16)
-#define PTRACE_EVENT_SIGTRAP (3 16)
-#define PTRACE_EVENT_SIGNAL(4 16)
+#define PTRACE_EVENT_SYSCALL (1 16)
+#define PTRACE_EVENT_SIGTRAP (2 16)
+#define PTRACE_EVENT_SIGNAL(3 16)
/* events visible to user-space */
#define PTRACE_EVENT_MASK 0x
@@ -257,8 +256,7 @@ static void ptrace_detach_task(struct ta
struct ptrace_context *ctx = ptrace_context(engine);
switch (get_stop_event(ctx)) {
- case PTRACE_EVENT_SYSCALL_ENTRY:
- case PTRACE_EVENT_SYSCALL_EXIT:
+ case PTRACE_EVENT_SYSCALL:
if (voluntary)
send_sig_info(sig, SEND_SIG_PRIV, tracee);
break;
@@ -385,9 +383,9 @@ static u32 ptrace_report_clone(enum utra
return UTRACE_STOP;
}
-static inline void set_syscall_code(struct ptrace_context *ctx, int event)
+static inline void set_syscall_code(struct ptrace_context *ctx)
{
- set_stop_code(ctx, event);
+ set_stop_code(ctx, PTRACE_EVENT_SYSCALL);
if (ctx-options PTRACE_O_TRACESYSGOOD)
ctx-stop_code |= 0x80;
}
@@ -411,7 +409,7 @@ static u32 ptrace_report_syscall_entry(u
WARN_ON(ptrace_event_pending(ctx));
- set_syscall_code(ctx, PTRACE_EVENT_SYSCALL_ENTRY);
+ set_syscall_code(ctx);
if (unlikely(ctx-options PTRACE_O_SYSEMU)) {
suppress_sigtrap(task);
@@ -444,7 +442,7 @@ static u32 ptrace_report_syscall_exit(en
return UTRACE_INTERRUPT;
}
- set_syscall_code(ctx, PTRACE_EVENT_SYSCALL_EXIT);
+ set_syscall_code(ctx);
return UTRACE_STOP;
}
@@ -954,7 +952,7 @@ static int ptrace_resume(struct task_str
case PTRACE_EVENT_CLONE:
case PTRACE_EVENT_VFORK_DONE:
if (request == PTRACE_SYSCALL) {
- set_syscall_code(ctx, PTRACE_EVENT_SYSCALL_EXIT);
+ set_syscall_code(ctx);
do_ptrace_notify_stop(ctx, tracee);
return 0;
}
@@ -963,14 +961,13 @@ static int ptrace_resume(struct task_str
/*
* single-stepping. UTRACE_SIGNAL_REPORT will
* synthesize a trap to follow the syscall insn.
-*/
+ */
ctx-signr = SIGTRAP;
action = UTRACE_INTERRUPT;
}
break;
- case PTRACE_EVENT_SYSCALL_EXIT:
- case PTRACE_EVENT_SYSCALL_ENTRY:
+ case PTRACE_EVENT_SYSCALL:
if (data)
send_sig_info(data, SEND_SIG_PRIV, tracee);
break;
Re: Q: UTRACE_SYSCALL_RESUMED logic
On 11/18, Roland McGrath wrote: In any case, what is the rationality? The rationale is that if you see utrace_resume_action(action)==UTRACE_STOP in your callback, then you know another engine asked for stop Yes, but engine can't know if the next one is going to return UTRACE_STOP. You can't know if the next one is going to change the registers and resume, either. That's just the general engine order issue. The only point of UTRACE_SYSCALL_RESUMED is to bring make it as possible to cooperate with a stop-modify-resume engine as it already is with a modify-in-callback engine. OK, thanks. But shouldn't utrace_report_syscall_entry() reset report-action = UTRACE_RESUME after do_report_syscall_entry()? If we stop, report-action remains UTRACE_STOP when we do the reporting loop. Yes, fixed. It is not clear to me why ptrace_report_syscall_entry() uses utrace_syscall_action() under if (UTRACE_SYSCALL_RESUMED). That is what a callback should do if it doesn't have a specific intent. Otherwise you clobber the choice made by a previous engine. This looks a bit strange because it returns the unconditional UTRACE_SYSCALL_RUN below. IOW, if ptrace should obey to another engine's request to abort this syscall, the code should use utrace_syscall_action() consistently. Yes, it should not change the incoming action for a ptrace syscall report. OTOH, PTRACE_O_SYSEMU always aborts. Not sure I understand how different engines can be friendly to each other. The friendly idea can only apply when an engine intends to be noninvasive to userland behavior. i.e., as the lone engine you would not perturb the default behavior, so as a second engine you should not perturb what the last engine chose. When the ptrace engine is doing SYSEMU, it intends to break the normal userland behavior. There is just inherently no way to be noninvasive about it. Thanks, Roland
