utrace-ptrace still has some known problems, but I'd like to
do some prepatations beforehand.
Oleg.
Add some temporary hacks into ptrace_check_attach() for now to make
it almost correct.
- check child-parent == current after ptrace_lookup_engine(),
this way we can't race with ptrace_attach().
- check task_is_stopped_or_traced() before utrace_control(UTRACE_STOP),
the child must be already
The changes in tracehook_prepare_clone() and tracehook_report_clone()
are no longer needed, we can revert them to lessen the size of the
first patch(es) and simplify the review/merging.
The reverted changes were necessary before, now
- tracehook_prepare_clone()
none of -ptrace
Trivial. Pick the new random value to use it instead of PT_PTRACED.
We need this old or new bit only to make sure task_ptrace() != 0.
This allows us to simplify/lessen the first patch(es) we are going
to send to lkml, because now we can drop some of unnecessary changes
outside of ptrace.c.
See
On 10/18, Oleg Nesterov wrote:
The semantics is that the entry report always does like
UTRACE_SYSCALL_ABORT to skip the actual call, and then
there is no exit report.
Thanks! this is easy.
Hmm. This is not what I see in upstream kernel...
Afaics, PTRACE_SYSEMU means:
- cancel
On 10/19, Oleg Nesterov wrote:
On 10/18, Oleg Nesterov wrote:
The semantics is that the entry report always does like
UTRACE_SYSCALL_ABORT to skip the actual call, and then
there is no exit report.
Thanks! this is easy.
Hmm. This is not what I see in upstream kernel...
Afaics
On 10/19, Oleg Nesterov wrote:
On 10/19, Oleg Nesterov wrote:
On 10/18, Oleg Nesterov wrote:
The semantics is that the entry report always does like
UTRACE_SYSCALL_ABORT to skip the actual call, and then
there is no exit report.
Thanks! this is easy.
Hmm
Cleanups.
Tomorrow: PTRACE_SYSEMU/PTRACE_SYSEMU_SINGLESTEP
The semantics is that the entry report always does like
UTRACE_SYSCALL_ABORT to skip the actual call, and then
there is no exit report.
Thanks! this is easy.
What about PTRACE_SYSEMU_SINGLESTEP ? I will read the code
tomorrow, but
I'd with very much it were true.
Kill VFORKDONE code. It doesn't rellay work just fools the poor tests.
---
kernel/ptrace.c |7 ---
1 file changed, 7 deletions(-)
--- PU/kernel/ptrace.c~95_KILL_VFORK_DONE 2009-10-17 16:00:40.0
+0200
+++ PU/kernel/ptrace.c 2009-10-17
If the tracer sets PTRACE_O_TRACEVFORKDONE but not PTRACE_O_TRACEVFORK,
clone(CLONE_VFORK) should be reported too, so in this case event must
be PTRACE_EVENT_VFORK_DONE.
But we can't return UTRACE_STOP. Since CLONE_VFORK is set, utrace will
actually stop the tracee in
ptrace.c | 50 +-
1 file changed, 25 insertions(+), 25 deletions(-)
This! nearly! killed! me!
I spent the WHOLE DAY doing this...
Good luck to anybody who want to review this code ;)
It is simple, but the rationality is not understandable
On 10/15, Roland McGrath wrote:
Roland, do you see other problems with attach/detach which
should be fixed before v1?
It depends what v1 means, on which I am not entirely clear.
The definition of v1 is very simple and absolutely precise.
The code is v1 when Roland thinks we can make the
On 10/15, Roland McGrath wrote:
ptrace_detach(sig) checks valid_signal(sig) to detect the
explicit detach and passes bool voluntary to ptrace_wake_up().
ptrace_detach_task() does. ptrace_detach() has already bailed out
if !valid_signal(sig) was really pass in from userland.
On 10/15, Roland McGrath wrote:
This reminds me, it is still not clear what should we actually do when the
killed tracee calls tracehook_report_exit(), but this is another story.
IMHO the truly desireable behavior is to distinguish real SIGKILL (userland
kill, oom_kill) from normal
On 10/15, Roland McGrath wrote:
We have a callback
void my_report_callback(...)
{
if (ptr)
dereference(ptr);
}
And the tracer does:
void *tmp = ptr;
ptr = NULL;
utrace_barrier(my_engine);
kfree(tmp);
This
On 10/15, Roland McGrath wrote:
Tracee, finish_callback() path:
if (action == UTRACE_DETACH)
engine-ops = utrace_detached_ops;
utrace-reporting = NULL;
no barries, no utrace-lock() in between.
Tracer, utrace_barrier() under utrace-lock:
if
On 10/16, Oleg Nesterov wrote:
On 10/15, Roland McGrath wrote:
Roland, do you see other problems with attach/detach which
should be fixed before v1?
It depends what v1 means, on which I am not entirely clear.
The definition of v1 is very simple and absolutely precise.
The code
ptrace_wake_up() clears tracee-exit_code, this is racy and no longer needed.
This was needed previously when -exit_code was checked by callbacks. Now
-exit_code is only used by do_wait(), and we have no reasons to clear it.
If the tracee exits or stops again -exit_code will be correctly updated
On 10/13, Ananth N Mavinakayanahalli wrote:
Use set_stop_code() wherever possible.
Signed-off-by: Ananth N Mavinakayanahalli ana...@in.ibm.com
---
kernel/ptrace.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: ptrace-13oct/kernel/ptrace.c
On 10/13, Ananth N Mavinakayanahalli wrote:
Rename ptrace_context() to get_ptrace_context() and use it for better
code readability. (I know it doesn't take a ref or anything; feel free to
ignore)
Well. As for naming, personally I don't care and agree with any naming.
I cc'ed Roland, if he
Cleanup self-detaching code + nice cleanup from Ananth.
Tomorrow: change detach to be as close as possible to upstream
wrt stop/wakeup behaviour.
Oleg.
From: Ananth N Mavinakayanahalli ana...@in.ibm.com
Use set_stop_code() wherever possible.
Signed-off-by: Ananth N Mavinakayanahalli ana...@in.ibm.com
---
kernel/ptrace.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- PU/kernel/ptrace.c~84_REPORT_SIGNAL_USE_HELPER
Tomorrow: change detach to be as close as possible to upstream
wrt stop/wakeup behaviour.
OK, I decided to send the incomplete changes today.
Tomorrow: tweak implicit-detach's behaviour.
Oleg.
Change ptrace_detach() to use ptrace_wake_up() which provokes the
unconditional wakeup for compatibility. Now utrace-ptrace passes
attach-wait-on-stopped, the only test it failed compared to upstream.
This is still not exactly right, implicit detach (exit_ptrace() path)
shouldn't do this, will
On 10/11, Roland McGrath wrote:
Roland, Jan, what user-space expects ptrace(DETACH, SIGKILL) should do?
My guess: this should really kill the tracee asap, hence this patch.
As far as killing, it is no more reliable than PTRACE_CONT,SIGKILL.
i.e., will fail if it's not stopped, will be
On 10/11, Roland McGrath wrote:
Issues with ptrace_check_attach(),
- it does utrace_control(UTRACE_STOP).
This is wrong, ptrace_check_attach() must be passive,
while utrace_control(UTRACE_STOP) can actualy stop the
tracee.
This is not inherently problematic
On 10/11, Roland McGrath wrote:
Yes. In particular, ptrace(PTRACE_DETACH, SIGKILL) should cancel
SIGNAL_STOP_STOPPED, yes?
Yes.
OK.
SIGNAL_STOP_DEQUEUED exists for one purpose. It's to ensure that SIGCONT
and SIGKILL can clear it to make complete their required effect of clearing
all
On 09/09, Roland McGrath wrote:
2. Is utrace_barrier() correct Note the example above,
it assumes that utrace_barrier() itself is the barrier
wrt reporting. But, is it?
I don't think I understand the question.
Sorry for delay on this. I have a lot of emails
Roland, please ignore this and the next patch.
We can do the same without UTRACE_ATTACH_MATCH_CHECK.
I don't like to rely on -cred_guard_mutex, but MATCH_CHECK is
not nice too.
On 10/09, Oleg Nesterov wrote:
Implement UTRACE_ATTACH_MATCH_CHECK. With this flag utrace_attach_task(data)
data
Please ignore
[PATCH 77] implement UTRACE_ATTACH_MATCH_CHECK
[PATCH 78] attach: try to re-use the self-detaching engine
patches.
Oleg.
[PATCH 76] fold detach_signal() into ptrace_detach_task() was buggy,
we read engine-date before checking IS_ERR(engine).
---
kernel/ptrace.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- PU/kernel/ptrace.c~79_FIX_DETACH_ENGINE_DEREF 2009-10-10
17:06:11.0 +0200
Change ptrace_attach_task() to re-use the self-detaching engine first,
then do utrace_attach_task(UTRACE_ATTACH_CREATE).
Unlike the previous version, ptrace_attach_task() just calls
ptrace_lookup_engine() and changes context-resume. The only caller
which can find the self-attaching engine is
Make sure that the new debugger doesn't get the old values in
ptrace_context or engine-flags if it re-uses the self-detaching
engine.
In particular, we should clear tracee-exit_code. The new debugger
should not see it via do_wait() until the tracee stops again. This
is racy, but -exit_code
Roland, Jan, what user-space expects ptrace(DETACH, SIGKILL) should do?
My guess: this should really kill the tracee asap, hence this patch.
---
kernel/ptrace.c |5 +
1 file changed, 5 insertions(+)
--- PU/kernel/ptrace.c~83_DETACH_SIGKILL2009-10-10 17:43:28.0
+0200
Issues with ptrace_check_attach(),
- it does utrace_control(UTRACE_STOP).
This is wrong, ptrace_check_attach() must be passive,
while utrace_control(UTRACE_STOP) can actualy stop the
tracee.
- even if it doesn't, this is wrong when we have multiple
On 10/10, Jan Kratochvil wrote:
On Sat, 10 Oct 2009 18:24:21 +0200, Oleg Nesterov wrote:
On 10/06, Jan Kratochvil wrote:
Yes, I agree with the current general behavior of ptrace there is missing:
if (WIFSTOPPED (status) WSTOPSIG (status) == SIGPIPE)
[...snip
On 10/10, Jan Kratochvil wrote:
On Sat, 10 Oct 2009 18:17:12 +0200, Oleg Nesterov wrote:
Roland, Jan, what user-space expects ptrace(DETACH, SIGKILL) should do?
My guess: this should really kill the tracee asap, hence this patch.
attached testcase works for me on both:
kernel-2.6.31.1
Rework get/set siginfo logic. We should never rely on -siginfo != NULL
checks. This is subtle, and if we implement the re-using of engine/context,
this just can't work.
Oleg.
Trivial, add set_stop_code() and turn syscall_code() into
set_syscall_code().
---
kernel/ptrace.c | 28
1 file changed, 16 insertions(+), 12 deletions(-)
--- PU/kernel/ptrace.c~72_SET_CODE_HELPER 2009-10-09 14:18:55.0
+0200
+++ PU/kernel/ptrace.c
To simplify the review:
static int ptrace_rw_siginfo(struct task_struct *tracee,
struct ptrace_context *context,
siginfo_t *info, bool write)
{
unsigned long flags;
int
Introduce detach_signal(sig) helper. It is called by ptrace_detach_task()
instead of removed ptrace_do_detach()-send_sig().
!valid_signal(sig) means that the tracer exits and detaches implicitly.
If sig == 0 - nothing to do, just detach and return. If the tracee
reported the signal, it will be
Implement UTRACE_ATTACH_MATCH_CHECK. With this flag utrace_attach_task(data)
data is the function pointer which checks engine-data instead of simple
comparison.
Todo: comment + rename.
---
include/linux/utrace.h |1 +
kernel/utrace.c|5 +
2 files changed, 6 insertions(+)
Change ptrace_attach_task() to re-use the self-detaching engine first,
then do utrace_attach_task(UTRACE_ATTACH_CREATE).
Todo:
- re-check this all (and test)
- rename check()
- cleanups the mess in ptrace_attach_task()
- ptrace_detach_task() should clear
Incomplete reply, just can't read/think/concentrate today...
On 10/07, Roland McGrath wrote:
We had a lengthy discussion about this.
Yes. I only ever wanted that revert then because it was too late in the
2.6.30 cycle to hash this all out and get it really right. I meant that
we should
On 10/07, Roland McGrath wrote:
void set_stop_code(struct ptrace_context *ctx, int event)
{
ctx-stop_code = (event 8) | SIGTRAP;
}
void set_syscall_code(struct ptrace_context *ctx, int event)
{
set_stop_code(ctx, event);
On 10/07, Roland McGrath wrote:
Naming: as usual, I agree in advance with any suggestions.
The ev_ prefix no longer refers to anything inherently obvious in the code.
If you want a common prefix for the struct it should be on all its fields
and it should be something evocative of struct
On 10/07, Roland McGrath wrote:
Make it something like:
static inline void set_stop_code(struct ptrace_context *ctx, int event)
{
ctx-stop_code = (event 8) | SIGTRAP |
(event = PTRACE_EVENT_SYSCALL_ENTRY
(ctx-options
On 10/06, Roland McGrath wrote:
[...snip a lot of useful info...]
Thanks Roland.
I need to read this carefully tomorrow.
- perhaps it makes sense to change force_sig_info() to use
lock_task_sighand(), then we can avoid taking taskist around
send_sigtrap().
This feels
On 10/07, Roland McGrath wrote:
+ if (context-siginfo)
+ return ptrace_rw_siginfo(tracee, context, info, false);
- return error;
+ memset(info, 0, sizeof(*info));
+ info-si_signo = SIGTRAP;
+ info-si_code = context-ev_code; // XXX: ev_code was already cleared!!!
On 10/06, Jan Kratochvil wrote:
On Mon, 05 Oct 2009 04:32:08 +0200, Oleg Nesterov wrote:
[...]
Firstly, I think we should un-revert
edaba2c5334492f82d39ec35637c6dea5176a977.
This unconditional wakeup is hopelessly wrong imho, and it is removed
from utrace-ptrace code. But this breaks
On 10/07, Jan Kratochvil wrote:
OK, this is really a border case I did not mean.
In such case the SIGHUP handler still is not fully execting and as the
non-realtime signals do not nest (count) it is OK it gets activated only once.
I did mean some more normal case of:
ptrace
On 10/06, Jan Kratochvil wrote:
On Mon, 05 Oct 2009 21:00:37 +0200, Oleg Nesterov wrote:
On 10/05, Jan Kratochvil wrote:
On Mon, 05 Oct 2009 04:51:32 +0200, Oleg Nesterov wrote:
Currently, if a tracer does ptrace(DETACH, tracee, SIGXXX)
and then another/same tracer does ptrace
On 10/06, Jan Kratochvil wrote:
On Tue, 06 Oct 2009 15:10:10 +0200, Oleg Nesterov wrote:
Once again. Suppose that the tracer does ptrace(PTRACE_DETACH, SIGXXX).
Currently, if the next thacer attaches right after this detach it has no
way to intercept SIGXXX, it will be never reported via
On 10/06, Jan Kratochvil wrote:
On Tue, 06 Oct 2009 19:14:28 +0200, Oleg Nesterov wrote:
On 10/06, Jan Kratochvil wrote:
[...]
If it is not reported to the new tracer then it will be always
processed by the tracee, is it right?
Yes, sure.
(But, just in case... if the tracer
Trivial, move the annoying PTRACE_O_TRACESYSGOOD check into the new helper,
syscall_code().
---
kernel/ptrace.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
--- PU/kernel/ptrace.c~66_SYSGOOD_HELPER2009-10-06 00:50:01.0
+0200
+++
Trivial, to simplify the review of the next patches.
-ev_name is used as rvalue in ptrace_resume(), add the trivial helper
to read this member.
---
kernel/ptrace.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
--- PU/kernel/ptrace.c~67_GET_STOP_CODE_HELPER 2009-10-06
Kill context-ev_name, it is always eq to (ev_code 8) since the
previous patch.
I think it makes sense to add another helper for (event 8) | signr,
but I failed to invent the name.
We can also kill context-signr, we can use (ev_code 0xFF) byte instead.
---
kernel/ptrace.c | 16
On 10/05, Oleg Nesterov wrote:
On 10/05, Jan Kratochvil wrote:
On Mon, 05 Oct 2009 04:51:32 +0200, Oleg Nesterov wrote:
It is not trivial to implement, and I don't understand why
it is important to keep this behaviour. But we have the test
case which checks this: attach-into-signal
(add Roland)
On 10/01, Jan Kratochvil wrote:
the ptrace-testsuite
http://sourceware.org/systemtap/wiki/utrace/tests
currently FAILs (also) on Fedora 12 kernel-2.6.31.1-48.fc12.x86_64 for:
FAIL: detach-stopped
FAIL: stopped-attach-transparency
Do you agree with the
Jan, Roland, I have the question.
Currently, if a tracer does ptrace(DETACH, tracee, SIGXXX)
and then another/same tracer does ptrace(ATTACH, tracee)
then SIGXXX will not be reported to the new tracer.
Why? Should utrace-ptrace be 100% compatible here?
It is not trivial to implement, and I
misc + context-siginfo changes
Oleg.
do_ptrace_notify_stop()-do_notify_parent_cldstop() is not safe
when called by tracer.
By the time we take tasklist the tracee can be SIGKILL'ed and
released by our sub-thread. In this case it is wrong to notify
its -real_parent.
If -real_parent has exited, then do_notify_parent_cldstop()
can use
task_struct-ptrace_message is no longer needed.
I wonder why compat_ptrace_request() does (compat_ulong_t)ptrace_message,
put_user(x, ptr) uses __typeof__(*ptr).
---
kernel/ptrace.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
--- PU/kernel/ptrace.c~59_NO_PTRACE_MESSAGE
Add ptrace_context-signr. The tracer just sets context-signr = data
and resumes the tracee, the tracee updates context-siginfo if needed.
When the tracee reports the signal it sets context-signr = info-si_signo.
This matches the current behaviour, but perhaps it would be bettter to set
-signr =
- Change ptrace_getsiginfo() to use ptrace_rw_siginfo().
- Fix the semantics. We should return EINVAL only if the tracee
was stopped. If it didn't report the signal, we fill siginfo
like ptrace_notify() did.
Note! Currently do_ptrace_notify_stop() clears context-ev_code for
debugging
Like the previous patch, but if the tracee didn't report a signal we
do nothing but return success.
Currently ptrace_notify() always sets -last_siginfo != NULL which can
be update via PTRACE_SETSIGINFO, but this info will be never used.
We pretend siginfo was updated for compatibility but the
ptrace_report_signal(UTRACE_SIGNAL_HANDLER) should be never called
with a valid context-siginfo, move the corresponding WARN_ON() up.
---
kernel/ptrace.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- PU/kernel/ptrace.c~60_SIGNAL_HANDLER_WARN_ALWAYS2009-10-02
A separate patch to discuss the comments/naming.
Introduce the new helper, ptrace_rw_siginfo(), to access context-siginfo.
It assumes the tracee must have the valid -siginfo != NULL unless we race
with SIGKILL, see the next patches.
---
kernel/ptrace.c | 37
On top of 4492770dc8d2312da9518e8b85fb0e49dc3da510 in your
utrace-ptrace branch.
Oleg.
Kill context-ev_array[].
Add the new members to struct ptrace_context:
-ev_mesg: for task_struct-ptrace_message
-ev_code: for task_struct-exit_code
-ev_name: this is unique identifier for ptrace_resume().
We don't actually need both ev_code and ev_name, but
ptrace_resume(data) should process data in case of
PTRACE_EVENT_SYSCALL and PTRACE_EVENT_SIGNAL events.
---
kernel/ptrace.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
--- PU/kernel/ptrace.c~54_RESUME_USE_DATA 2009-10-01 21:53:01.0
Change ptrace_resume() to report the artificial SYSCALL_EXIT stop
when needed.
This is trivial, but I am not sure yet what should we do with the
stacked JCTL stops.
ptrace_report_clone() is not exactly right too, will be fixed later.
This and the next patches add another switch(-ev_name), I'll
utrace-ptrace can't rely on syscall_trace_leave()-send_sigtrap(), we
should generate this trap by hand.
To do this we have to split PTRACE_EVENT_SYSCALL into
PTRACE_EVENT_SYSCALL_ENTRY and PTRACE_EVENT_SYSCALL_EXIT to identify
the latter case which needs a trap.
Note! I think we can avoid using
Hi Jan,
On 10/01, Jan Kratochvil wrote:
the ptrace-testsuite
http://sourceware.org/systemtap/wiki/utrace/tests
currently FAILs (also) on Fedora 12 kernel-2.6.31.1-48.fc12.x86_64 for:
FAIL: detach-stopped
Please recall our previous discussion about
On 09/25, Roland McGrath wrote:
it being after the syscall insn, but (in vanilla ptrace, and at the
time of report_clone callbacks at utrace level) without the return
value register having been written yet.
And how we can implement this?
regs-ax is updated right after call
On 09/25, Oleg Nesterov wrote:
On 09/25, Roland McGrath wrote:
it being after the syscall insn, but (in vanilla ptrace, and at the
time of report_clone callbacks at utrace level) without the return
value register having been written yet.
And how we can implement
On 09/25, Roland McGrath wrote:
- Change ptrace_resume_signal() to use context-siginfo under -siglock,
like ptrace_{get,set}siginfo() do.
I don't think the log/comments give a clear picture of why this is the
thing to do. To wit, I'm not even sure at the moment it is necessary.
It
Just in case, please ignore
[PATCH 54] PTRACE_SINGLESTEP shouldn't bypass SYSCALL_EXIT
[PATCH 55] workaround to pass the assert() at step-from-clone.c:193
patches. You were right, there are ugly even as temporary changes.
And unneeded.
Currently the code wrongly assumes that
On 09/23, Roland McGrath wrote:
It's a further oddity that you can single-step (or not) into the
system call and then get a ptrace stop inside it, that being for
PTRACE_EVENT_FORK et al. From there, the thread register state shows
it being after the syscall insn, but (in vanilla ptrace, and
On 09/22, Roland McGrath wrote:
I think the only cases where you can have a ptrace stop followed by
actually taking the ret_from_sys_call path are tracehook_report_clone stops
(i.e. the stop inside a clone/fork/vfork syscall). If you last used
PTRACE_CONT or whatever and then hit
The new ptrace-tests/tests/syscall-from-clone.c fails as expected.
Because, following your suggestion, I postponed the final changes in
ptrace_report_clone() until we fix the more important things. But since
we have the new test-case, add the trivial fix.
ptrace_report_clone() still needs
The new test ptrace-tests/tests/step-from-clone.c fails.
I didn't know that PTRACE_SINGLESTEP is not user-mode only. I thought
that the next stop should happen only after return to user-mode.
However, the current behaviour is that PTRACE_SINGLESTEP acts like
PTRACE_SYSCALL (but see below), if
This is the temporary fix for the new step-from-clone.c test-case.
Actually kludge, not the fix. But I don't understand the rationale
behind the current behaviour yet.
So, this test does:
ptrace(PTRACE_SETOPTIONS, PTRACE_O_TRACESYSGOOD);
ptrace(PTRACE_CONT);
// tracee
On 09/23, Roland McGrath wrote:
Yes, but this has nothing to do with utrace-ptrace. If we last used
PTRACE_CONT, the tracee stops in utrace_resume() path before return to
the user-mode, syscall_trace_leave() can't be called.
If I follow what you mean, that is just the x86 bug (now fixed
On 09/23, Roland McGrath wrote:
However, the current behaviour is that PTRACE_SINGLESTEP acts like
PTRACE_SYSCALL (but see below), if the tracee is not going to return
to user-mode yet. Say, PTRACE_EVENT_VFORK.
Not really. Given what I just wrote, I'm not sure if you want me
to merge
I think ptrace_report_signal() is mostly finished.
Unlike vanilla kernel, the tracer fixups the context of -siginfo
if we change si_signo, not the tracee. task_pid_vnr() is not namespace
friendly, but I think we don't care. At least now.
And the question:
ptrace_report_signal:
- Change ptrace_resume_signal() to use context-siginfo under -siglock,
like ptrace_{get,set}siginfo() do.
- Document why this is safe.
- Also, use ACCESS_ONCE() which implies the compiler barrier. This is
only theoretical issue, but still.
---
kernel/ptrace.c | 27
ptrace_report_signal(UTRACE_SIGNAL_HANDLER) should be never called
with a valid context-siginfo, move the corresponding WARN_ON() up.
---
kernel/ptrace.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- PU/kernel/ptrace.c~57_SIGNAL_HANDLER_WARN_ALWAYS2009-09-24
Not sure you will like it, hence the separate patch.
ptrace_{get,set}siginfo() need ACCESS_ONCE() to fix the theoretical
problem, and they also need a comment to explain why it is safe to
dereference -siginfo under -siglock.
I think it would be more readable if we add the trivial helper, just
to
On 09/23, Roland McGrath wrote:
Hmm. Not sure how to fix this...
Well, one thing it can do is just punt them down to UTRACE_REPORT.
It's only a non-guaranteed optimization that these effects happen
directly from utrace_control() without being reinforced by a final
Implement PTRACE_SINGLESTEP/PTRACE_SINGLEBLOCK.
As usual, this needs further cleanups, but I hope the code is more
or less correct.
Oleg.
Change ptrace_resume() path to pass the correct action argument
to utrace_control(), the current code always uses UTRACE_RESUME
while PTRACE_SINGLEXXX needs UTRACE_XXXSTEP.
Introduce ptrace_context-resume to remember this action, we have
to re-assert it from report_quiesce/report_signal
Change ptrace_report_signal() to handle UTRACE_SIGNAL_HANDLER case
correctly: just push the new stop event if the tracer wants stepping.
We do not set context-siginfo = info, this would be wrong because
we do not report a signal. I wonder how the tracer can distinguish
this case from the real
Thanks Roland.
But now I am even more confused...
On 09/20, Roland McGrath wrote:
- PTRACE_SINGLESTEP does user_enable_single_step()
- when the tracee returns to user mode, the next instruction
causes exception, do_debug()-send_sigtrap() sends SIGTRAP
- the tracee
On 09/21, Oleg Nesterov wrote:
However,
int main(void)
{
assert(0 == prctl(666));
printf(after prctl\n);
return 0;
}
dies with Trace/breakpoint trap, dmesg says:
prctl: before=10246
prctl: after=10346
On 09/21, Oleg Nesterov wrote:
Yes, I modified the patch a bit (see below) to print the syscall number,
Forgot to attach the patch. I guess it is not really needed, but
just in case.
Oleg.
--- TTT/kernel/sys.c~TF_FBG 2009-06-17 14:11:26.0 +0200
+++ TTT/kernel/sys.c2009-09-21
Help! I spent all Sunday trying to do something with PTRACE_SINGLESTEP.
And I am totally confused, to the point I don't even know how/what to ask.
OK. Please forget about utrace. The tracee sleeps in, say, ptrace_signal()-
ptrace_stop() path. The tracer does ptrace(PTRACE_SINGLESTEP, data = 0).
On 09/14, Roland McGrath wrote:
Basically, we have ev_push() and ev_pop(), that is all.
I don't mean it's hard to understand what the code does.
It's clear enough that it's a simple ring buffer scheme.
But just having that extra data structure is extra complexity and storage
even so.
I seem to find the problem, and I do not see a simple solution.
Will try to think more tomorrow with a fresh head, but perhaps
you can help. looks like we need some changes in utrace/signal
layer.
Suppose that a tracee is going to report, say, PTRACE_EVENT_FORK.
The callback returns UTRACE_STOP.
Misc changes, more preparations for ptrace_report_signal().
Oleg.
301 - 400 of 551 matches
Mail list logo
