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-resethand-on-cont-signal hangs and clone-multi-ptrace silently
> > crashes the kernel.
> >
> > The quick investigation didn't help, utrace.c has too much changes,
> > I will read the code tomorrow from the very beginning.
>
> Ooooooooooooohhhhhhhhh.
>
> In short, the code in utrace.c was broken even before utrace-cleanup
> was merged
And your current tree has the same problem: utrace_attach_task() sets
->pending_attach, but utrace_get_signal() can miss it and dequeue/report
a signal without splice_attaching().
Change utrace_get_signal() to check ->pending_attach.
I do not understand the new code yet, I am not sure this patch is optimal.
But it helps, the kernel doesn't crash/hang any longer.
We still have problems, 5 tests fail. Some failures are expected, we know
that the changes in utrace-cleanup must break the stepping logic in ptrace
(to remind you just in case, utrace_control(STEP) doesn't call enable_step()
synchronously). Some are not, ptrace_event_clone for example.
Signed-off-by: Oleg Nesterov <o...@redhat.com>
---
kernel/utrace.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- UTRACE-PTRACE/kernel/utrace.c~UTRACE_ATTACH_SIGNAL_RACE 2009-11-13
18:00:06.000000000 +0100
+++ UTRACE-PTRACE/kernel/utrace.c 2009-11-15 19:52:29.000000000 +0100
@@ -1955,7 +1955,8 @@ int utrace_get_signal(struct task_struct
int signr;
utrace = task_utrace_struct(task);
- if (utrace->resume < UTRACE_RESUME || utrace->signal_handler) {
+ if (utrace->resume < UTRACE_RESUME ||
+ utrace->pending_attach || utrace->signal_handler) {
enum utrace_resume_action resume;
/*
