implement user_enable_single_step() should add
user_single_step_siginfo() also.
Signed-off-by: Oleg Nesterov o...@redhat.com
Acked-by: Roland McGrath rol...@redhat.com
---
include/linux/ptrace.h | 12
1 file changed, 12 insertions(+)
--- V1/include/linux/ptrace.h~3_DEFAULT_HELPER
(already in mm: ptrace-powerpc-implement-user_single_step_siginfo.patch)
Suggested by Roland.
Implement user_single_step_siginfo() for powerpc.
Signed-off-by: Oleg Nesterov o...@redhat.com
Acked-by: Roland McGrath rol...@redhat.com
---
arch/powerpc/include/asm/ptrace.h |2 ++
arch/powerpc
);
assert(pid == wait(status));
if (status == 0x57F)
return 0;
printf(kernel bug: status=%X shouldn't have 0x80\n, status);
return 1;
}
Signed-off-by: Oleg Nesterov o...@redhat.com
Acked-by: Roland McGrath
(already in mm: ptrace-x86-implement-user_single_step_siginfo.patch)
Suggested by Roland.
Implement user_single_step_siginfo() for x86. Extract this code
from send_sigtrap().
Since x86 calls tracehook_report_syscall_exit(step = 0) the new
helper is not used yet.
Signed-off-by: Oleg Nesterov o
the syscall-exit stop.
Change syscall_trace_leave() to pass the correct step argument to
tracehook and remove the send_sigtrap() logic.
Signed-off-by: Oleg Nesterov o...@redhat.com
Acked-by: Roland McGrath rol...@redhat.com
---
arch/x86/kernel/ptrace.c | 21 +++--
1 file
-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/tracehook.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- V1/include/linux/tracehook.h~8_TRACEHOOK_KILL_PTRACED_CHECKS
2009-11-24 19:52:10.0 +0100
+++ V1/include/linux/tracehook.h2009-11-24 20:29
to check PT_PTRACED, ptrace-utrace doesn't set it.
Signed-off-by: Roland McGrath rol...@redhat.com
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/tracehook.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- V1/include/linux/tracehook.h~9_SIGNAL_HANDLER_CK_PTRACE
Export __ptrace_detach() and do_notify_parent_cldstop() for
ptrace-utrace.
Signed-off-by: Roland McGrath rol...@redhat.com
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/ptrace.h |1 +
include/linux/sched.h |1 +
kernel/ptrace.c|2 +-
kernel/signal.c
No functional changes, preparation for the next patch.
Move the code which can be shared with ptrace-utrace up, before
__ptrace_link(). This way ptrace-utrace needs a single #ifdef in
ptrace.c.
Signed-off-by: Roland McGrath rol...@redhat.com
Signed-off-by: Oleg Nesterov o...@redhat.com
On 11/24, Andi Kleen wrote:
Oleg Nesterov o...@redhat.com writes:
From: Roland McGrath rol...@redhat.com
This adds the utrace facility, a new modular interface in the kernel
for implementing user thread tracing and debugging. This fits on top
of the tracehook_* layer, so the new code
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
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
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(-)
No functional changes.
Move the code which can be shared with utrace-ptrace up, before
__ptrace_link().
---
kernel/ptrace.c | 556
1 file changed, 278 insertions(+), 278 deletions(-)
--- UTRACE-PTRACE/kernel/ptrace.c~136_REORDER_FUNCS
If I understand correctly, we are not going to have CONFIG_UTRACE_PTRACE,
CONFIG_UTRACE should use utrace-ptrace unconditionally.
Remove CONFIG_UTRACE_PTRACE. I do not know where is the right place for
CONFIG_UTRACE option and what the help text should say, I assume you can
fix this patch or make
implement user_enable_single_step() should add
user_single_step_siginfo() also.
Signed-off-by: Oleg Nesterov o...@redhat.com
Acked-by: Roland McGrath rol...@redhat.com
---
include/linux/ptrace.h | 12
1 file changed, 12 insertions(+)
--- V1/include/linux/ptrace.h~3_DEFAULT_HELPER
the syscall-exit stop.
Change syscall_trace_leave() to pass the correct step argument to
tracehook and remove the send_sigtrap() logic.
Signed-off-by: Oleg Nesterov o...@redhat.com
Acked-by: Roland McGrath rol...@redhat.com
---
arch/x86/kernel/ptrace.c | 21 +++--
1 file
No functional changes, preparation for utrace-ptrace.
task_ptrace() != 0 if and only if PT_PTRACED bit is set, kill
some PT_PTRACED checks in tracehook.h to ensure the result is
the same with or without utrace which doesn't set PT_PTRACED.
Signed-off-by: Oleg Nesterov o...@redhat.com
Export __ptrace_detach() and do_notify_parent_cldstop() for
ptrace-utrace.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/ptrace.h |1 +
include/linux/sched.h |1 +
kernel/ptrace.c|2 +-
kernel/signal.c|2 +-
4 files changed, 4 insertions(+), 2
mv kernel/ptrace.c kernel/ptrace-utrace.c.
Then I will send the patch which restores the old ptrace.c and
moves kernel/ptrace-common.h into it as you suggested before.
I am not sure what is the best way to do these renames but I hope
this doesn't really matter, utrace-ptrace branch is only for
On 11/18, Roland McGrath wrote:
So maybe you will look at this and merge them before I do.
Whatever we do, perhaps it makes sense to apply your patch
in https://www.redhat.com/archives/utrace-devel/2009-November/msg00109.html
first and then do further changes?
This way we will have the working
On 11/18, Roland McGrath wrote:
Hmm. not sure I understand how this can work. I mean, this won't
enable stepping (in this particular case we are discussing).
I might be confused. I'm thinking of two cases: the report_syscall_entry
pass yields UTRACE_SINGLESTEP, or that it yields
On 11/18, Roland McGrath wrote:
I added tracehook_init_task() in my tree. I don't see much benefit in
sending any tracehook patch upstream for this. tracehook_init_task()
corresponds to tracehook_free_task(), which is only added by utrace
(and both would just be empty in a separate
On 11/18, Roland McGrath wrote:
Once again. The tracee sleeps in SYSCALL_ENTER. The tracer resumes
the tracee via utrace_control(UTRACE_SINGLESTEP).
Right. This is another strange corner. It doesn't necessarily make
especially good sense intrinsically for single-step to have this meaning
Just can't understand UTRACE_SYSCALL_RESUMED code.
To the pointed, I tried to read the docs:
* When %UTRACE_STOP is used in @report_syscall_entry, then @task
* stops before attempting the system call. In this case, another
* @report_syscall_entry callback follows after
On 11/16, Roland McGrath wrote:
You cited the one most obvious case: utrace_get_signal() has just run, so
finish_resume_report() has just run and everything is already as we want.
What else?
I think, we can say that finish_resume_report() must be never called
without reporting loop if
On top of your patch in
https://www.redhat.com/archives/utrace-devel/2009-November/msg00109.html
I attached this patch below just in case. As expected, it fixes
the problem with the lost TIF_SINGLESTEP.
Oleg.
--- UTRACE-PTRACE/kernel/utrace.c~__ROLAND_RESUME_FIX 2009-11-18
21:16:23.0
We should never call finish_resume_report(report) when
report-action == UTRACE_RESUME, this can destroy the result
of the previous finish_resume_report().
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/utrace.c |8 +---
1 file changed, 5 insertions(+), 3 deletions
.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/utrace.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
--- UTRACE-PTRACE/kernel/utrace.c~2_FINISH_REPORT_CK_RESUME_UNDER_LOCK
2009-11-19 02:24:41.0 +0100
+++ UTRACE-PTRACE/kernel/utrace.c 2009-11-19 02:40
I'll reply tomorrow, it is to late for me.
But I noticed the funny detail in your email,
On 11/18, Roland McGrath wrote:
Yes. But, hmm.
utrace_stop(task, utrace, UTRACE_RESUME); /* XXX */
This XXX was there about passing UTRACE_RESUME, because that's not really
right.
I
On 11/16, Oleg Nesterov wrote:
On 11/16, Oleg Nesterov wrote:
And I didn't check make xcheck, I guess it still crashes the kernel.
Yes it does. I am almost sure the bug should be trivial, but
somehow can't find find it.
Found the trivial but nasty problem.
tracehook_finish_clone
On 11/17, Oleg Nesterov wrote:
On 11/16, Oleg Nesterov wrote:
On 11/16, Oleg Nesterov wrote:
And I didn't check make xcheck, I guess it still crashes the kernel.
Yes it does. I am almost sure the bug should be trivial, but
somehow can't find find it.
Found the trivial but nasty
On 11/16, Roland McGrath wrote:
The change we talked about before seems simple enough and should cover this
without new kludges in the ptrace layer. I did this (commit f19442c).
I will reply to this in the next email, I'd like to discuss
another minor related issue first.
I noticed this
On 11/16, Roland McGrath wrote:
Whatever temporary hacks are fine by me one way or the other.
They will just be coming out later along with assorted other cleanup.
We certainly do want to get this right in the utrace layer.
Yes. But imho it is always good to test/review the patches against
On 11/16, Roland McGrath wrote:
But this smp_rmb() in task_utrace_struct() is only needed when the
caller does something like
if (task_utrace_flags(tsk))
do_something(task_utrace_struct());
If you look at where task_utrace_struct() is used, it's basically always
like
In short, it is just wrong to call finish_resume_report() in utrace_resume()
without reporting loop, because utrace never clears TIF_NOTIFY_RESUME. It is
very possible we enter utrace_resume() with utrace-resume == UTRACE_RESUME,
in this case finish_resume_report() does user_disable_single_step().
This needs more comment, I'll try to add them in a separate patch.
With the recent changes in utrace API utrace_control(UTRACE_SINGLESTEP)
postpones enable_step() to utrace_resume() stage. The tracee can pass
tracehook_report_syscall_exit() without TIF_SINGLESTEP, this breaks
the send_sigtrap()
Just in case, forgot to clarify...
On 11/16, Oleg Nesterov wrote:
With this patch make check passes all tests again (to clarify, except
some tests which upstream doesn't pass too), including this one:
with this patch +
[HACK] utrace: fix utrace_resume()-finish_resume_report() logic
And I
On 11/16, Roland McGrath wrote:
Now, if we race with another task doing utrace_task_alloc() and see
-utrace != NULL, why should we see the correctly initialized *utrace?
utrace_task_alloc() needs wmb(), and the code like above
read_barrier_depends().
Ok. Please review what I put in
On 11/16, Oleg Nesterov wrote:
And I didn't check make xcheck, I guess it still crashes the kernel.
Yes it does. I am almost sure the bug should be trivial, but
somehow can't find find it. Just fyi, to ensure this is connected
to utrace-indirect I applied the hack below and the bug goes away
On 11/16, Roland McGrath wrote:
But read_barrier_depends() does nothig except on alpha, why should we
care?
I thought this was the barrier you were talking about. Anyway, we should
be pedantically correct about these. (People do even still build
Linux/Alpha.)
Yes, sure. I meant, we
On 11/15, Oleg Nesterov wrote:
On 11/13, Oleg Nesterov wrote:
Roland, I pulled the last changes in your tree (utrace-cleanup merged
in utrace-ptrace) and did some testing.
In short: utrace-ptrace does not work at all.
It fails a lot (if not most) of tests, in particular
sa
On 11/15, Oleg Nesterov wrote:
With this patch the kernel passes all tests except single-step ones, as
expected.
Forgot to mention, your tree lacks these patches we sent upstream:
ptrace-introduce-user_single_step_siginfo-helper.patch
ptrace-powerpc-implement
().
UPD: tested the kernel with this patch, now late-ptrace-may-attach-check
crashes the kernel silently (no output under kvm).
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/utrace.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- UTRACE-PTRACE/kernel/utrace.c
On 11/16, Oleg Nesterov wrote:
UPD: tested the kernel with this patch, now late-ptrace-may-attach-check
crashes the kernel silently (no output under kvm).
Repeated this test. Got several oopses, bad spinlock magic in utrace-lock.
The stack trace varies, often from utrace_get_signal().
Oh
On 11/12, Oleg Nesterov wrote:
On 11/12, Roland McGrath wrote:
I did some tweaks that I think address the several things you've raised.
But I didn't try to reply point by point. I've merged everything up now,
so the utrace-cleanup branch is gone. Please review the current code
By the previous discussion, revert 603e19c41ba5c97e48a25543c63c081c5fe64137
for now.
But keep WARN_ON(resume != XXX_STEP), it may help.
---
kernel/ptrace.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
--- PU/kernel/ptrace.c~130_REVERT_KILL_PTRACE_EVENT_SIGTRAP
PTRACE_SINGLESTEP after syscall-exit shouldn't trigger the trap before
return to user-mode. This was the x86 spicific oddity which is already
fixed in -mm by
ptrace-x86-change-syscall_trace_leave-to-rely-on-tracehook-when-stepping.patch
---
kernel/ptrace.c |6 ++
1 file changed, 2
Change ptrace_report_signal() to report SIGTRAP via
user_single_step_siginfo() + force_sig_info().
---
kernel/ptrace.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
--- PU/kernel/ptrace.c~132_USER_SINGLE_STEP_INFO2009-11-13
22:35:40.0 +0100
On 11/11, Roland McGrath wrote:
I saw you have utrace-syscall-resumed branch but never looked at it.
For those not concerned with its purpose, there is one thing you must
know. Every report_syscall_entry callback must do:
if (utrace_syscall_action(action) == UTRACE_SYSCALL_RESUMED)
On 11/02, Roland McGrath wrote:
- unlike send_sigtrap()-force_sig_info() we don't unblock
SIGTRAP or reset the handler
This is nicer for debugger things actually, but we don't have such niceness
for real traps and won't soon. IMHO it is best to start with doing exactly
what the
Just noticed I didn't reply to this message,
On 10/30, Roland McGrath wrote:
If the tracee was STOPPED/TRACED, then it is equivalent to
PTRACE_CONT,SIGKILL.
Otherwise it has no effect except it can race with exit() and spoil
-exit_code,
and wake_up_process() is not good if course. (I
On 11/12, Roland McGrath wrote:
I did some tweaks that I think address the several things you've raised.
But I didn't try to reply point by point. I've merged everything up now,
so the utrace-cleanup branch is gone. Please review the current code and
post about anything we still need to
On 11/10, Roland McGrath wrote:
This change affects ia64, microblaze, parisc, powerpc, sh. They pass
nonzero step argument to tracehook but since it was ignored the tracee
reports via ptrace_notify(), this is not right and not consistent.
This could be more explicit about the details of
On 11/10, Roland McGrath wrote:
Ok. I realize it's largely separate, but I think we want to hash through
this along with the other set of after-report-behavior problems.
Also, it doesn't seem sensible to fiddle with utrace_report_syscall_entry
separate from resolving UTRACE_SYSCALL_RESUMED
Seriously, I don't think it makes sense to factor out memset +
si_signo = SIGTRAP. Imho we need a single helper which can/should
be overriden by arch's.
How about this?
Oleg.
Currently there is no way to synthesize a single-stepping trap in the
arch-independent manner. This patch adds the default helper which fills
siginfo_t, arch/ can can override it.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/ptrace.h | 12
1 file changed, 12
and not consistent.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/tracehook.h |7 +++
1 file changed, 7 insertions(+)
--- TH/include/linux/tracehook.h~3_TRACEHOOK_HANDLE_STEPPING2009-11-10
01:03:22.0 +0100
+++ TH/include/linux/tracehook.h2009-11-10 22:00
Implement user_single_step_siginfo() for x86. Extract this code
from send_sigtrap().
Since x86 calls tracehook_report_syscall_exit(step = 0) the new
helper is not used yet.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
arch/x86/include/asm/ptrace.h |2 ++
arch/x86/kernel/ptrace.c
the send_sigtrap() logic.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
arch/x86/kernel/ptrace.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
--- TH/arch/x86/kernel/ptrace.c~5_X86_CONVERT_SYSCALL_LEAVE 2009-11-10
22:21:42.0 +0100
+++ TH/arch/x86/kernel
Ugh. I sent the patches before I checked email.
On 11/10, Roland McGrath wrote:
Oh... this adds more naming problems. And this way x86's send_sigtrap()
can't use this helper easily.
It's true. Another approach would be to genericize send_sigtrap so that
all arch's can use it, and call
On 11/09, Roland McGrath wrote:
OK, how about these 2 simple patches for upstream? Then we can change
powerpc, etc.
Perhaps, instead of arch_has_fill_sigtrap_info we can start with the
patch below? Since tracehook_report_syscall_exit() is inline we can
can add the if (step) code
On 11/06, Roland McGrath wrote:
All that part does is move all decisions about what to do into the
tracehook/utrace/ptrace layers out of arch code.
...
After the arch/tracehook cleanup we've been discussing, what happens here
is consistent across machines.
Yes, agreed. Just I greatly
Extract arch_fill_sigtrap_info() from send_sigtrap() and change
syscall_trace_leave() to rely on tracehook_report_syscall_exit()
to handle stepping.
Note: before this patch x86 generated the unnecessary SIGTRAP
when PTRACE_SINGLESTEP done at the syscall-exit stop, now x86
matches other
On 10/28, Roland McGrath wrote:
I've made a new branch, utrace-cleanup.
This forks from utrace-indirect and has:
26fefca utrace: sticky resume action
28b2774 utrace: remove -stopped field
I am not sure I understand the new code in details - too much changes.
Anyway, I can never understand
A killed tracee should do nothing until the tracer drops utrace-lock.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/tracehook.h |2 ++
include/linux/utrace.h|2 ++
kernel/utrace.c | 16 +++-
3 files changed, 19 insertions(+), 1 deletion
shouldn't copy_process() do clear_tsk_thread_flag(child, TIF_SINGLESTEP) ?
I'll recheck this, but looks like both upstream and utrace-ptrace
should do this. Otherwise, the new child can start with TIF_SINGLESTEP
copied from parent's ti-flags. This looks just wrong, but if we do not
auto-attach
It took me more time/efforts than I expected, and probably needs
more changes.
I still owe you review/fixes for utrace-cleanup branch.
Oleg.
As you suggested, we can simplify ptrace_request()-ptrace_resume()
path, ptrace_resume_action() checks all for resume requests except
PTRACE_CONT.
---
kernel/ptrace.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
---
Preparation, no functional changes.
- change ptrace_report_signal()-resume_signal() to clear ctx-signr,
not only ctx-siginfo. This allows us to overload ctx-signr.
IOW, with this patch ctx-signr != 0 is only possible when a tracee
is stopped with the valid ctx-siginfo after reporting the
Move send_sigtrap() logic from ptrace_resume() to ptrace_report_signal().
ptrace_resume() sets ctx-signr = SIGTRAP and returns UTRACE_INTERRUPT.
ptrace_report_signal() notices SIGTRAP, fills *info and reports the signal.
fill_sigtrap_info() mimics x86-specific send_sigtrap(), therefore:
Suppose that a PTRACE_O_TRACEFORK tracee does fork() and stops in
SYSCALL_ENTRY state. The tracer does PTRACE_SINGLESTEP.
In this case the tracee resumes and stops after syscall_trace_leave()
to report PTRACE_EVENT_FORK, but since it passes syscall_trace_leave()
with TIF_SINGLESTEP set the tracee
On 10/27, Roland McGrath wrote:
This is used only in the UTRACE_SIGNAL_HANDLER case. That means after
tracehook_signal_handler(), which is where a signal handler has just
been set up.
For reference, in old ptrace, tracehook_signal_handler() is:
if (stepping)
On 10/29, Oleg Nesterov wrote:
In this case I confused again. Let's forget about get_user_pages() under
spin_lock(), pretend it works.
Two engines, E1 and E2, the tracee sleeps in utrace_resume()-utrace_stop().
E1 does utrace_control(UTRACE_RESUME), E2 does
utrace_control
On 10/28, Roland McGrath wrote:
Unlike the old code that freaked upstream reviewers all the way out,
this has very simple lifetime rules for struct utrace. Once allocated,
it lives until task_struct is freed. The utrace_task_alloc() logic
covers the only race (at first attach), and that
On 10/27, Roland McGrath wrote:
--- /dev/null 2009-10-25 19:46:00.608018007 +0100
+++ V1/kernel/ptrace-utrace.c 2009-10-26 03:56:46.0 +0100
Generally, needs more comments. That's not news, I'm sure.
But just giving reactions as I would if doing upstream review
without
Btw, why does utrace_set_events() check utrace-stopped?
If a tracee is stopped then -reporting == engine is not possible,
-reporting must be NULL.
To optimize out other checks + mb() in the likely stopped case?
Oleg.
On 10/29, Roland McGrath wrote:
void utrace_finish_jctl(void)
{
struct utrace *utrace = task_utrace_struct(current);
/*
* While in TASK_STOPPED, we can be considered safely stopped by
* utrace_do_stop(). Make sure we can do
On 10/29, Roland McGrath wrote:
The only problem with this change (if we do it now), it is always nice
to have a separate changelog to document the behaviour change. But
hopefully nobody cares, I mean, nobody will notice the difference.
This seems like something we could change upstream
On 10/29, Roland McGrath wrote:
Another example is E1 does UTRACE_BLOCKSTEP and then E2
does UTRACE_SINGLESTEP.
Now single-step will win out, which is right. But E2 gets no notice about
this, so it can't know that the step is for an insn rather than a block.
Yes.
In contrast, say
PTRACE_KILL tweaks + cosmetic cleanups
Oleg.
- Remove the temporary debugging check in ptrace_notify_stop().
- Remove the XXX marker in ptrace_resume(), the recent changes
hopefully fixed the problems with jctl nested stops.
---
kernel/ptrace.c |9 +
1 file changed, 1 insertion(+), 8 deletions(-)
---
No changes in ptrace.o
- s/context/ctx/
- line up ptrace_context-resume decl
- remove kerneldoc bits from ptrace_traceme(). The comment is
not very nice, I'd better remove it completely.
---
kernel/ptrace.c | 192 +++-
1 file changed, 95
On 10/27, Roland McGrath wrote:
I'm skeptical this is the desireable way to move the code around.
Of course, for all such things, I am fine with whatever upstream likes.
But here are my concerns:
I am not sure this is the best choice too.
That is not friendly to git history at all.
Yes, I
On 10/27, Roland McGrath wrote:
[I have no idea why you appended this to that message introducing patches
that are not related to this at all. Please use separate threads for
separate topics, and choose clearly apropos Subject: lines.]
OK.
I am thinking how can we fix
On 10/28, Oleg Nesterov wrote:
As for ptrace. If utrace_control(SINGLESTEP) doesn't set TIF_SINGLESTEP,
then we need more (probably nasty) changes. report_quiesce/interrupt should
somehow figure out whether we need send_sigtrap() if -resume == XXXSTEP.
Or. We can add the hack below for V1
On 10/27, Roland McGrath wrote:
In this case kernelptrace.c becomes
... the context of kernel/ptrace-common.h ...
#ifndef CONFIG_UTRACE
... other code ...
#endif
and we don't need CONFIG_PTRACE_OLD.
Do you agree with approach?
That's what I had in mind.
On 10/27, Roland McGrath wrote:
5/7 belongs first and I've already merged it as prerequisite to utrace.
We can send that upstream without delay. I hope it can get queued quickly
regardless of the review delays for the utrace and ptrace work.
Agreed, I'll send it to Andrew.
All the other
On 10/27, Roland McGrath wrote:
Not sure I understand... This is like utrace-vfork_stop:1, it is
only visible to utrace code.
Show me the change the the utrace_control kerneldoc wording that makes it
match what difference you propose this implementation detail would make.
When you
On 10/27, Ananth N Mavinakayanahalli wrote:
On Mon, Oct 26, 2009 at 04:28:52AM +0100, Oleg Nesterov wrote:
No functional changes, preparation for utrace-ptrace.
Introduce kernel/ptrace.h and move the code which can be shared
with the new implementation into this new header.
Did you
No functional changes, preparation for utrace-ptrace.
ptrace_init_task() looks confusing, as if we always auto-attach when
bool ptrace argument is true, while in fact we attach only if current
is traced.
Make the code more explicit and kill now unused ptrace_link().
Signed-off-by: Oleg Nesterov
is implemented on top of utrace.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/signal.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- V1/kernel/signal.c~4_PTRACE_SIGNAL_CK_PTRACED 2009-09-24
21:38:54.0 +0200
+++ V1/kernel/signal.c 2009-10-26 00:43:05.0 +0100
() always
returns 0.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/signal.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
--- V1/kernel/signal.c~5_DO_SIGNAL_STOP_AFTER_TRACEHOOK 2009-10-26
00:43:05.0 +0100
+++ V1/kernel/signal.c 2009-10-26 01:01:47.0
No functional changes, preparation for utrace-ptrace.
Introduce kernel/ptrace.h and move the code which can be shared
with the new implementation into this new header.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/ptrace-common.h | 278
On 10/26, Oleg Nesterov wrote:
For early review.
Patches 1-5 can be sent upstream right now. The last 2 patches
add the new implementation.
utrace.patch can come before or after, I think after is better.
Forgot to mention, this series is against Linus's tree.
Oleg.
I guess my intent is clear, but just in case... the second patch
is the only change in ptrace.h we need and we can send it upstream
right now.
I am thinking how can we fix utrace_control(SINGLESTEP). I don't
have good ideas so far. But, perhaps we can add
utrace-please_enable_single_step:1 ?
ptrace_init_task() looks confusing, as if we always auto-attach when
bool ptrace argument is true, while in fact we attach only if current
is traced.
Make the code more explicit and kill now unused ptrace_link().
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/ptrace.h | 11
Sorry for late reply.
I delayed it because I hoped I will see how to solve this problem
cleanly during the rewrite.
No. I don't see how we can fix this without some changes in utrace.
Just in case, let me remind you what is the problem. For simplicity,
let's ignore SIGKILL issues, and let's
Move the call to do_signal_stop() down, after tracehook call.
This makes -group_stop_count condition visible to tracers before
do_signal_stop() will participate in this group-stop.
Currently the patch has no effect, tracehook_get_signal() always
returns 0.
Signed-off-by: Oleg Nesterov o
On 10/20, Roland McGrath wrote:
But ptrace_check_attach() needs the tracee to be already stopped.
A bit ugly to ask the tracee to stop via UTRACE_STOP and then resume
it if it was not already stopped. And I don't even understand how to
do this correctly. (but again, I'll try to think
201 - 300 of 551 matches
Mail list logo
