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
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.
To optimize out other checks + mb() in the likely stopped case?
Yes.
Thanks,
Roland
Can't comment right now, need to read the code.
Such gentlemanly restraint.
Afaics, we can't just remove utrace_finish_jctl() and the similar code in
utrace_stop(). We need
void utrace_finish_jctl(void)
{
struct utrace *utrace = task_utrace_struct(current);
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
Yes, this is the question ;)
At this point I have an irrational distaste for utrace_struct.h and a
pathological displeasure at having a contentious upstream discussion on
this again. We need to get the right code in upstream, and in the
right state before another lifetime passes. I'm leaving
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
This seems like something we could change upstream first, to clarify and
separate the behavior change. If the arch bits about choosing si_code et
al are resolved, then it is simple to make the old kernel's tracehook calls
post a signal instead of using ptrace_notify.
Ah, yes. I forgot
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
Yes, we can't control the callback order, and this means we have the
same problem even without utrace_control().
Right, but that is the known item on the list to consider for API
refinements. If at least utrace_control doesn't add any new wrinkles to
that issue, then we know that if we later
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
16 matches
Mail list logo
