Sorry I'm so long in following up on this.
I know you've hacked a lot more since.
The vanilla kernel relies on syscall_trace_leave() which does
send_sigtrap(TRAP_BRKPT). But with utrace-ptrace the tracee sleeps
in do_notify_resume() path, syscall_trace_leave() won't be called.
It's even
On top of 4492770dc8d2312da9518e8b85fb0e49dc3da510 in your
utrace-ptrace branch.
I had done an upstream merge since then and also merged some more of
yours. So to get utrace-ptrace back to a state where 53-70 apply cleanly,
I reverted these first:
6752625 introduce context_siginfo() helper
task_struct-ptrace_message is no longer needed.
Woo!
I wonder why compat_ptrace_request() does (compat_ulong_t)ptrace_message,
put_user(x, ptr) uses __typeof__(*ptr).
I think it's just being explicit about the truncation to keep its intent
clear to someone reading the code.
Thanks,
Roland
+static int ptrace_rw_siginfo(struct task_struct *tracee,
+ struct ptrace_context *context,
+ siginfo_t *info, bool write)
+{
+ unsigned long flags;
+ siginfo_t *context_info;
+ int err = -ESRCH;
+
+ if
+ 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!!!
+ info-si_pid =
+ if (context-siginfo)
+ return ptrace_rw_siginfo(tracee, context, info, true);
Superfluous test, just call it unconditionally as with the get case.
Then both helpers have everything in common, and they are static anyway,
so you might as well just call ptrace_rw_siginfo from
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 PTRACE_O_TRACESYSGOOD) ?
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 Wed, 07 Oct 2009 15:33:49 +0200, Oleg Nesterov wrote:
On 10/06, Jan Kratochvil wrote:
It should work also for PTRACE_SINGLESTEP.
Heh. Yes, but with one exception.
- the tracee has a hanlder for, say, SIGHUP
- the tracee deques SIGHUP, reports to the tracer,
and
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
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);
if (PTRACE_O_TRACESYSGOOD)
I don't think this can work. context-siginfo can be cleared and then
set again in between. If we race with SIGKILL, utrace_get_signal()
can dequeue another signal != SIGKILL and start the reporting loop.
That's not supposed to be possible. See sigset_t sigkill_only; et al.
I guess it is
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.
Correct.
Why? Should utrace-ptrace be 100% compatible here?
I think it should, yes. There is a rationale for it that makes
Naive programs expect the first signal after PTRACE_ATTACH will be SIGSTOP.
They should not, this is just wrong.
And I think the proposed change doesn't change the behaviour
in this sense.
It does not in the general sense. But it does change the behavior of
certain 100% predictable
OK. Let's see what Roland thinks.
I think the whole stoppedness vs detach et al discussion is a separate
issue from the basic PTRACE_DETACH,signr behavior, and I think I want to
discuss that in the other thread we have whose subject says it's about
that. I think I've covered the (separate)
In which specific cases SIGNR can get ignored?
There are two fundamental kinds of ptrace stops: real signal stops, and
fake (or ptrace_notify()) stops. In the latter, you are not in the
right place in the kernel for direct signal delivery, so it never works
fully normally. All the optional
after which the full range of
[oops, left that thought unfinished!]
... signal control options works (immediate delivery, SETSIGIFNO obeyed)
I do not know. I'd leave this to Roland. I mean, if he thinks this
should be fixed - I'll try to fix.
But. This all looks unfixeable to me. In my opinion, the kernel is
obviously wrong, and test-case are wrong too. And any fix in this
area is user-visible and can break the current
22 matches
Mail list logo
