On 02/06, Josh Stone wrote:
On 02/06/2012 06:24 PM, Ying, Victor wrote:
I have problem to checkout utrace via git clone
git://git.kernel.org/pub/scm/linux/kernel/git/oleg/misc.git
utrace-3.0, it always reports fatal: the remote end hung up
unexpectedly; I tried both utrace-3.0 and
On 01/25, Josh Boyer wrote:
I'll get this into rawhide this evening.
Thanks Josh.
There is another simple change, I forgout about it. It is purely
internal, has no effect outside of utrace.c.
Oleg.
From: Tony Breeds t...@bakeyournoodle.com
TIF_SYSCALL_EMU is x86 only, add ifdef into ptrace_report_syscall().
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/tracehook.h |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/linux/tracehook.h b
On 08/02, Oleg Nesterov wrote:
utrace patches for 3.1 kernel. Untested, will try to do some tests
tomorrow.
I tried to test it a bit, seems to work. But see the new
[PATCH 31/31] utrace_resume: check irqs_disabled() to shut up lockdep.
The whole series is available in
git
Add the killed tracehook_consider_fatal_signal() back. It has multiple
callers and it is not easy add the necessary checks inline.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
arch/s390/kernel/traps.c |4 ++--
include/linux/tracehook.h | 22 ++
kernel/signal.c
this
magic argument should actually mean anyway.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/utrace.h | 22 ++
kernel/exit.c |4
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/include/linux/utrace.h b/include/linux/utrace.h
(), this is no longer needed and wrong.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/utrace.c | 16 ++--
1 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/kernel/utrace.c b/kernel/utrace.c
index 1e750ad..5d3974e 100644
--- a/kernel/utrace.c
+++ b/kernel/utrace.c
Add the necessary and somewhat special hooks into sig_ignored() and
recalc_sigpending(). Basically this restores _force_sigpending() and
_consider_ignored_signal() tracehook logic.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/utrace.h |2 ++
kernel/signal.c|7
case, change it as well.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/signal.h |2 ++
kernel/ptrace.c|2 +-
kernel/signal.c| 12 ++--
kernel/utrace.c|2 +-
4 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/include/linux
() to call this helper right after schedule(),
otherwise this logic is broken by the upstream changes
- now that utrace doesn't control TASK_TRACED bit, ptrace_stop() must
call this helper too.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/utrace.h | 11 +++
kernel/signal.c
not use task_is_traced() to check if this task was
stopped by utrace, use the new task_is_utraced() helper which
checks __TASK_UTRACED.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/utrace.c | 26 ++
1 files changed, 14 insertions(+), 12 deletions(-)
diff --git
static helper.
- it uses wake_up_quiescent() instead of wake_up_state().
Thereafter every change from STOPPED/TRACED to RUNNING is done via
wake_up_quiescent().
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/ptrace.h |1 +
kernel/ptrace.c| 20
If ptrace_stop() sets TASK_TRACED and then detects we should not stop,
it can race with utrace_do_stop() which can see TASK_TRACED and add
TASK_UTRACED. In this case we should stop for utrace needs.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/signal.c |8
1 files changed
Introduce TASK_UTRACED state, will be used by utrace instead of TASK_TRACED.
Note: this state is reported as t (tracing stop) to the user-space to
avoid the confusion. IOW, it looks like TASK_TRACED in /proc/pid/status.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
fs/proc/array.c
signr again, update struct k_sigaction *ka
in this case.
IOW, roughly, ptrace acts as if it is the last attached engine, it
takes the final decision about the signal.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/utrace.h | 31 +++
kernel/signal.c
JOBCTL_PENDING_MASK instead. This matches the
JOBCTL_STOP_PENDING | JOBCTL_TRAP_MASK code in the caller,
get_signal_to_deliver(). Note that this code won't run if
utrace_get_signal() returns signr 0.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/utrace.c |2 +-
1 files changed, 1 insertions
there is no more quiescent bits in task-state.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/signal.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index a625309..0d1675a 100644
--- a/kernel/signal.c
+++ b/kernel
with
TIF_SYSCALL_TRACE, change ptrace_report_syscall() to check
this flag instead of PT_PTRACED.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/ptrace.h|3 +++
include/linux/tracehook.h |2 +-
kernel/ptrace.c |7 +--
3 files changed, 9 insertions(+), 3
No functional changes. Add the new helper, ptrace_set_syscall_trace(),
which should be used to set/clear TIF_SYSCALL_TRACE in ptrace code.
Currently it does nothing more.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/ptrace.c | 15 ++-
1 files changed, 10 insertions(+), 5
TIF_SYSCALL_TRACE should be cleared only if both ptrace and utrace do
not want it, change utrace_reset() to check PT_SYSCALL_TRACE before
clear_tsk_thread_flag(TIF_SYSCALL_TRACE).
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/utrace.c |1 +
1 files changed, 1 insertions(+), 0
CONFIG_UTRACE, gcc is smart enough to optimize out
the code in free_task().
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/fork.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index e7ceaca..a9891da 100644
--- a/kernel/fork.c
+++ b
task_utrace_unlock(task), it releases the corresponding lock.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/utrace.h |9 +
kernel/utrace.c| 26 ++
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/include/linux/utrace.h b
by the tracee itself. If it is killed we do not care.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/tracehook.h |8
kernel/utrace.c |9 ++---
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/include/linux/tracehook.h b/include/linux
4d16a64 introduce PT_SYSCALL_TRACE flag breaks PTRACE_SYSEMU
which doesn't set PT_SYSCALL_TRACE.
Change ptrace_report_syscall() to check TIF_SYSCALL_EMU as well.
This can't conflict with utrace, this flag can only be set by
ptrace.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux
Hello.
utrace patches for 3.1 kernel. Untested, will try to do some tests
tomorrow.
I do not want to spam you all and the lists, please look at
git://git.kernel.org/pub/scm/linux/kernel/git/oleg/misc.git utrace-3.1
Oleg Nesterov (29):
utrace: add utrace_init_task/utrace_free_task
On 07/01, Oleg Nesterov wrote:
- Perhaps PTRACE_SYSEMU/TIF_SYSCALL_EMU logic was broken,
I need to recheck.
Yes, it was. Fixed by 2/2.
ptrace: shift user_*_step() from ptrace_resume() to ptrace_stop()
forgot to change ptrace_disable(), see 1/2.
Oleg.
4d16a64 introduce PT_SYSCALL_TRACE flag breaks PTRACE_SYSEMU
which doesn't set PT_SYSCALL_TRACE.
Change ptrace_report_syscall() to check TIF_SYSCALL_EMU as well.
This can't conflict with utrace, this flag can only be set by
ptrace.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux
by the tracee itself. If it is killed we do not care.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/tracehook.h |8
kernel/utrace.c |9 ++---
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/include/linux/tracehook.h b/include/linux
user_disable_single_step() while utrace needs the
stepping.
Set TIF_NOTIFY_RESUME after user_disable_single_step() to ensure
the tracee can't return to the user-space without utrace_resume().
Any correct engine which wants the stepping should reassert it.
Signed-off-by: Oleg Nesterov o...@redhat.com
Another attempt. This version tries to decouple utrace and ptrace.
This way it is much simpler to follow the upstream changes, afaics.
TODO:
- The single-stepping updates in ptrace_resume() can race
with utrace_reset()-user_disable_single_step().
This was fixed by
-state = TASK_STOPPED | TASK_TRACED, this can be useful.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/sched.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/sched.c b/kernel/sched.c
index 3f2e502..ade7997 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
case, change it as well.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/signal.h |2 ++
kernel/ptrace.c|2 +-
kernel/signal.c| 12 ++--
kernel/utrace.c|2 +-
4 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/include/linux
it to tracehook_finish_stop(),jctl no longer matches the
reality.
- change do_signal_state() to call this helper right after schedule(),
otherwise this logic is broken by the upstream changes
- now that utrace doesn't control TASK_TRACED bit, ptrace_stop() must
call this helper too.
Signed-off-by: Oleg
there is no more quiescent bits in task-state.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/signal.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index a7979ad..57552e6 100644
--- a/kernel/signal.c
+++ b/kernel
If ptrace_stop() sets TASK_TRACED and then detects we should not stop,
it can race with utrace_do_stop() which can see TASK_TRACED and add
TASK_UTRACED. In this case we should stop for utrace needs.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/signal.c |8
1 files changed
and this is
not utrace-friendly, it can need this flag.
Change ptrace_set_syscall_trace() to take task_utrace_lock(), this is
enough to fix the 1st problem. Check task_utrace_flags() before clearing
TIF_SYSCALL_TRACE, this fixes 2.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/ptrace.c |6 +-
1
and utrace.
TODO: update the !x86 ptrace code which does user_disable_single_step().
Signed-off-by: Oleg Nesterov o...@redhat.com
---
arch/x86/kernel/ptrace.c |1 +
include/linux/ptrace.h|5 -
include/linux/tracehook.h |7 +--
kernel/ptrace.c |3 +++
4 files
-by: Oleg Nesterov o...@redhat.com
---
kernel/signal.c | 24 +++-
1 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index 89e691d..d0e0c67 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2006,9 +2006,6 @@ retry:
static int
On 06/21, Roland McGrath wrote:
OK, so here's my (hacky) idea:
(1) Forget ptrace-via-utrace. Have utrace be a separate thing. This
way the recent ptrace changes won't matter.
This is what V2 does.
(2) But, what about ptrace co-existing well with utrace? Make them
mutually exclusive
Hello.
Utrace patches for 3.0 kernel
0001-ptrace-temporary-revert-the-recent-ptrace-jobctl-re.patch
0002-tracehooks-preparation-for-ptrace-utrace.patch
0003-utrace-core.patch
0004-implement-utrace-ptrace.patch
also available in the following git branch
reported. In the long term we
need another solution.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
fs/exec.c |1 -
include/linux/sched.h | 17 +--
include/linux/tracehook.h | 27
kernel/exit.c | 77 ++-
kernel/ptrace.c | 116
-by: Oleg Nesterov o...@redhat.com
---
include/linux/ptrace.h |3 +
kernel/Makefile|1 +
kernel/ptrace-utrace.c | 1173
kernel/ptrace.c| 638 +-
kernel/utrace.c| 16 +
5 files changed, 1513
On 06/20, Kyle McMartin wrote:
On Mon, Jun 20, 2011 at 06:07:44PM +0200, Oleg Nesterov wrote:
Temporary revert the following patches to keep utrace/utrace-ptrace working:
huge list of patches here
This obviously reverts some user-visible fixes, but the fixed problems
are very old
In short: exit_ptrace()-ptrace_detach_task() is very wrong when it
tries to detach the !stopped tracee, we can not trust get_stop_event()
in this case.
This means that in the case like
ptrace(PTRACE_CONT, ..., SIGXXX);
exit(); // --- calls ptrace_detach_task()
the tracee can
the trivial helper, is_step_resume(), which does the check.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/ptrace-utrace.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
--- kstub/kernel/ptrace-utrace.c~3_resume_step_helper 2010-09-20
03:53:31.0 +0200
-resume
before reporting a signal. This fixes the 2nd problem.
To fix the 1st problem, change !explicit case to check -siginfo != NULL
instead of relying on get_stop_event() which can't work with the running
tracee.
Reported-by: Glen Johnson bugpr...@us.ibm.com
Signed-off-by: Oleg Nesterov o
On 10/22, Oleg Nesterov wrote:
On 10/19, Roland McGrath wrote:
Yes. But, with this patch, in this case
utrace_barrier()-get_utrace_lock(attached = false) returns success
and then we check utrace-reporting == engine.
I guess that's OK if -reporting == engine is always set when any
On 10/22, Roland McGrath wrote:
Hmm. If task is not stopped then it is current (except
utrace_control(DETACH) can play with the dying task).
Right, asynchronous detach was the problematic case I was concerned with.
but asynchronous detach doesn't do utrace_reset(), unless the tracee
is
On 10/19, Roland McGrath wrote:
But that's how it used to be, and then we changed it.
So it merits digging up our old discussion threads that led to doing that
and see what all we had in mind then.
I tried to grep my mail archives and google, but failed to find anything
related.
On 10/14, Roland McGrath wrote:
In short: I no longer understand why utrace-resume can be UTRACE_*STEP
when the tracee is stopped, and in fact I think this is not right.
I think we didn't have that originally.
Yes.
The rationale that I remember is
the idea that you should be able to
On 10/12, Roland McGrath wrote:
If engine is detached (has utrace_detached_ops), utrace_barrier(engine)
spins until engine-ops becomes NULL. This is just wrong.
Yes, this happens because get_utrace_lock returns -ERESTARTSYS and
utrace_barrier checks for this and loops. I agree these
On 10/13, Roland McGrath wrote:
On 09/10, Roland McGrath wrote:
ugdb sets please stop flag and does utrace_control(INTERRUPT).
However,
in unlikely case the tracee can stop before -report_signal() reporting
I don't think this is the right thing to do. When the intent is
(). If it is zero we can just clear
-spurious and return without playing with -reporting and -flags.
No need to worry about ENGINE_STOP, finish_callback() has already
updated engine-flags and report-action correctly.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/utrace.c |8 +++-
1
On 08/18, Oleg Nesterov wrote:
utrace_resume(UTRACE_REPORT) always calls utrace_reset() because
start_callback() obviously can't clear report-spurious when
event == 0.
Change start_callback() to correctly clear -spurious in this case.
Correctly? I am stupid, and this patch is wrong
On 10/08, Oleg Nesterov wrote:
- full vCont support.
Well, this was easy, except even after 3 hours
of debugging I can't understand why this change
breaks the stepping over pthread_create :/
Oh, it doesn't break. I did a lot of mistakes when I was trying
On 10/05, Pedro Alves wrote:
(reordered)
On Tuesday 05 October 2010 18:27:29, Oleg Nesterov wrote:
So, I strongly believe gdb is buggy and should be fixed.
Fix your stub to implement vCont;s/c(/S/C).
First of all, I confirm that when I added the (incomplete right
now) support for vCont;s
On 09/23, Roland McGrath wrote:
OK, finish_callback_report() and utrace_control(DETACH) can set
TIF_NOTIFY_RESUME.
Right. Those utrace_resume has the report.action==UTRACE_RESUME bail-out
case. So either that would change or detach would also do UTRACE_REPORT.
But what if there are no
On 09/22, Frank Ch. Eigler wrote:
oleg wrote:
[...] Honestly, I don't really know how do the right thing here.
Anyway, most probably this code will be changed. Like ptrace, ugdb
uses -report_syscall_exit() to synthesize a trap. Unlike ptrace,
ugdb_report_signal() doesn't send SIGTRAP
On 09/21, Roland McGrath wrote:
OK, so what should we do for now?
If we can't come to a straightforward answer for the general case
fairly quickly, then we can do the simple change to start with.
I think we should start with changing utrace_control(DETACH) anyway,
then try to improve. I'll
On 09/23, Oleg Nesterov wrote:
On 09/21, Roland McGrath wrote:
It's better to have a spurious report (preferably just spurious
TIF_NOTIFY_RESUME with no actual callbacks) following any detach,
or whatever it takes to ensure user_disable_single_step() always
runs if user_enable_*_step
On 09/21, Roland McGrath wrote:
Change utrace_reset() to do user_disable_single_step(). Alternatively
we could change ptrace layer, but I think this is not ptrace specific.
Yes, it's right to fix this in the utrace layer.
But I'm not sure that's the right place in the code to fix it.
The
On 09/21, Roland McGrath wrote:
I was worried about the case when the TIF_SINGLESTEP tracee detaches
itself and escapes finish_resume_report()-user_disable_single_step(),
say, utrace_report_exec(). But probably we can ignore this.
No, I think that is indeed a problem. If no engine is
On 09/22, Oleg Nesterov wrote:
On 09/21, Roland McGrath wrote:
I was worried about the case when the TIF_SINGLESTEP tracee detaches
itself and escapes finish_resume_report()-user_disable_single_step(),
say, utrace_report_exec(). But probably we can ignore this.
No, I think
Changes: syscall stepping + minor cleanups.
Seems to work, more or less, but surely there are some bugs.
Honestly, I don't really know how do the right thing here.
Anyway, most probably this code will be changed. Like ptrace,
ugdb uses -report_syscall_exit() to synthesize a trap. Unlike
ptrace,
.
Change utrace_reset() to do user_disable_single_step(). Alternatively
we could change ptrace layer, but I think this is not ptrace specific.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/utrace.c |1 +
1 file changed, 1 insertion(+)
--- kstub/kernel/utrace.c
Back to ugdb.
Changes: implement stepi, this also means breakpoints work too.
Notes:
- almost untested, probably needs more fixes
- syscall-stepping doesn't work correctly (should be simple)
- don't look at handle_setregs/handle_set_one_reg, I did
this on
On 09/14, Oleg Nesterov wrote:
Oh, please take a look at this (untested) patch.
I tried to test the cleanuped version, seems to work.
But I think I should make another attempt, probably spinlock (-siglock ?)
would be cleaner.
No. I think more locking buys nothing.
I'll split this patch
On 09/14, Oleg Nesterov wrote:
On 09/13, Roland McGrath wrote:
Locks just between the tracer and ptrace_report_signal are not bad.
OK, but let me think a bit more. I'd really like to avoid adding the
new lock to avoid the very unlikely race with the exiting tracer.
Oh, please take a look
On 09/10, Roland McGrath wrote:
Oleg == Oleg Nesterov o...@redhat.com writes:
Oleg (gdb) set var 0
You need: set variable var = 0
The variable can be abbreviated.
I've always just used:
(gdb) set var=0
No, I tried this too, doesn't work.
(gdb) set var=0
On 09/10, Roland McGrath wrote:
But I meant another case, when the stopped tracee doesn't have siginfo.
Currently ugdb just sends this signal to tracee, and then it will be
reported to gdb. Not sure if this is right or not, I can change this.
(or perhap this doesn't matter, I dunno).
On 09/10, Roland McGrath wrote:
I am a bit confused... OK, ugdb is wrong wrt multitracing.
UTRACE_SIGNAL_REPORT case shouldn't return UTRACE_STOP |
UTRACE_SIGNAL_IGN,
it should return UTRACE_STOP | UTRACE_SIGNAL_REPORT to keep
report-result.
No, UTRACE_SIGNAL_REPORT is not meant for
On 09/10, Roland McGrath wrote:
ugdb sets please stop flag and does utrace_control(INTERRUPT). However,
in unlikely case the tracee can stop before -report_signal() reporting
I don't think this is the right thing to do. When the intent is explicitly
to interrupt, there is no reason to
On 09/09, Frank Ch. Eigler wrote:
Oleg Nesterov o...@redhat.com writes:
[...]
But, Jan. Implementing the memory writes does not mean breakpoints
automatically start to work!
It approximately should though.
Yes, gdb writes cc, and yes the tracee reports SIGTRAP. But after
On 09/09, Oleg Nesterov wrote:
the tracee hits this bp and reports SIGTRAP
= vStopped
= OK
= g
= 00064000401f207d007f00...
= P10=ba054000
Changes:
- partly fix the multitracing problems.
ugdb still can't work with ptrace, ptrace-utrace.c needs
changes. But at least multiple udgb tracers can coexist,
more or less.
But of course they can confuse each other anyway, no matter
On 09/06, Frank Ch. Eigler wrote:
Oleg Nesterov o...@redhat.com writes:
[...]
Therefore until you track some ugdb-specific software(*)
breakpoints ugdb does not need to support Z0 IMO. I guess ugdb
will never have to support these: thread-related(?) and tracepoint
ones.
Good! I
On 09/03, Roland McGrath wrote:
So, it is technically kosher enough to use UTRACE_INTERRUPT without
UTRACE_EVENT(QUIESCE) set, if you really know the situation and are sure
about all those caveats above.
How? see below.
I mentioned the examples.
I misunderstood the
On 09/05, Jan Kratochvil wrote:
On Sat, 04 Sep 2010 00:40:47 +0200, Oleg Nesterov wrote:
- implement qXfer:siginfo:read
- implement continue with signal.
OK, thanks, just it was a bit premature to ask for it I see. I miss at least
memory writes
Yes. This is simple.
(also
On 09/06, Jan Kratochvil wrote:
On Mon, 06 Sep 2010 20:18:08 +0200, Oleg Nesterov wrote:
On 09/05, Jan Kratochvil wrote:
(also to put in breakpoints):
And this is not clear to me, I need your help ;)
Sorry, I just meant that by implementing the memory writes breakpoints
Sorry for the delay, I was distracted. Trying to switch back to ugdb.
On 08/31, Jan Kratochvil wrote:
ugdb should support qXfer:siginfo, currently accessible only via $_siginfo
print/set, though.
Still sure this feature should be also implemented one day.
Yes sure. This should be simple,
I was going to ping you ;) This is connected to the problem I hit today.
Despite the fact I already complained about utrace_get_signal() QUIESCE,
I forgot about this and figured out it doesn't work in practice.
On 09/02, Roland McGrath wrote:
If an engine used UTRACE_INTERRUPT without having
Changes:
- report signals. A bit more code changes than I expected.
- implement QPassSignals, trivial.
Note: $CSIG is not supported yet, and I am not sure I understand
how it should work. Next time...
#include linux/module.h
#include linux/proc_fs.h
#include linux/utrace.h
Changes:
- adapt to no more utrace changes. Whatever I think
about utrace I have to agree, it is not practical to
change utrace now
- attach to the thread-group with the dead leader
- fix the double-attaching bug
- do not assume we can trust
On 08/19, Roland McGrath wrote:
On 08/16, Roland McGrath wrote:
Now that you merged c93fecc925ea7567168f0c94414b9021de2708c5
get_utrace_lock() must not succeed if utrace-reap == T, this becomes
a bit off-topic. However, I thought about relaxing the dead check in
get_utrace_lock(),
On 08/19, Roland McGrath wrote:
Wait. It doesn't break this. It only breaks -EALREADY contract. And
I don't understand why this is bad.
The -EALREADY contract lets you have a report_death callback that does all
your cleanup and then returns UTRACE_DETACH.
I think this is possible without
On 08/19, Roland McGrath wrote:
OK, instead of filling utrace_detached_ops{} we can change start_callback()
- if (want UTRACE_EVENT(QUIESCE)) {
+ if ((want UTRACE_EVENT(QUIESCE)) || ops == detached_ops) {
If we're going to have a special-case check for utrace_detached_ops,
On 08/19, Roland McGrath wrote:
I think in the longer term mark_engine_detached() should not change
engine-flags at all but add QUIESCE to -utrace_flags. However, this
breaks utrace_maybe_reap(reap = true) and we should avoid the race
with finish_callback() which clears -reporting after
On 08/23, Oleg Nesterov wrote:
However. I spent all Monday trying to resolve the new bug, and
so far I do not understand what happens. Extremely hard to reproduce,
and the kernel just hangs silently, without any message.
So far I suspect the proble in utrace.c, but this time I am not sure
Just a small report to explain what I am doing...
On 08/20, Oleg Nesterov wrote:
- I forgot to implement the attach to the thread group
with the dead leader. Next time.
Almost done, but we should avoid the races with exec somehow.
But this is minor.
I tried to test this code
On 08/19, Oleg Nesterov wrote:
Next step: handle exit correctly and report W/S. I misunderstood
what gdbserver does when the main thread exits, it is not stupid
as I wrongly thought.
Yes, in non-stop mode gdbserver reports W/X;process:PID when the
last thread exits. This makes sense, so does
On 08/19, Roland McGrath wrote:
Note the second attachment, GDBCAT. It is just the simple perl
script which connects /proc/ugdb to tcp port. It can be used for
remote debugging via tcp, or with (unpatched) gdb which can't do
select() on /proc/ugdb.
bash$ nc -l 2000 /proc/ugdb
Yes,
On 08/17, Oleg Nesterov wrote:
On 08/16, Roland McGrath wrote:
The problem is, utrace_control(DETACH) does nothing and returns
-EALREADY if utrace-death is set, this is not right. We can and
should detach in this case, we only should skip utrace_reset() to
avoid the race
finish_callback() should check
engine-ops == utrace_detached_ops before return. Instead we should
change finish_callback_report() to return the boolean. We shouldn't
return true without setting report-detaches.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/utrace.c |2 +-
1 file changed, 1
utrace_flags UTRACE_EVENT(QUIESCE)
and returns otherwise. This should be fixed somehow. This check is wrong
anyway, but it is not clear how we can fix the race with DETACH.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/utrace.c |2 +-
1 file changed, 1 insertion(+), 1 deletion
On 08/16, Roland McGrath wrote:
- It is possible that both -death and -reap are true. In this
case it is OK to clear UTRACE_EVENT(REAP), but set_events fails.
No, it's not OK to clear it. Once -reap is set, then the engine's
ops-report_reap might or might not have been called
On 08/16, Roland McGrath wrote:
In short: this double check allows to avoid tasklist when utrace_flags
already has these bits while engine-flags doesn't.
But multitracing is unlikely case, in the likely case if we add
_UTRACE_DEATH_EVENTS to engine-flags we set these bits in
On 08/17, Oleg Nesterov wrote:
Suppose that, say, engine-flags == UTRACE_EVENT(EXEC) (no QUIESCE).
1. start_callback() reads want = engine-flags (== EXEC)
2. mark_engine_detached() sets engine-ops = utrace_detached_ops
3. start_callback() gets ops = utrace_detached_ops
in
this case, but it doesn't hurt.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/utrace.c | 49 ++---
1 file changed, 10 insertions(+), 39 deletions(-)
--- kstub/kernel/utrace.c~6_fix_control_dead2010-08-16 11:17:05.0
+0200
Now that get_utrace_lock() can never succeed if utrace-reap is true,
we can kill this check in utrace_set_events(). This also means we can
kill the target-exit_state check, it buys nothing now.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/utrace.c | 13 -
1 file changed
On 08/16, Oleg Nesterov wrote:
Well, I tried to test these changes, seems to work.
But... From 2/3 changelog:
This means that
mark_engine_detached() can race with REPORT_CALLBACKS() but there
is nothing new.
Yes, there is nothing new. But, Roland, this is WRONG
1 - 100 of 551 matches
Mail list logo
