On Tue, 01 Dec 2009 20:39:40 +0100, Roland McGrath wrote:
I think the best bet is to link with -Wl,-z,now and then minimize the
library code you rely on.
Checked-in the fix of at least Fedora 12 x86_64 below.
getppid() does not look to be needed there - PTRACE_SYSCALL does stop
(WIFSTOPPED) on
On Tue, 01 Dec 2009 18:38:27 +0100, Veaceslav Falico wrote:
Instead of using fork(), call syscall(__NR_fork) in step-fork.c
to avoid looping on powerpc arch in libc.
Checked-in. (Not seen any problems with syscall and using glibc afterwards as
in the clone-multi-ptrace.c case so left it as
On Wed, 09 Dec 2009 19:12:41 +0100, Oleg Nesterov wrote:
while the '.func_name' is the text address.
tried to change the code to
REGS_ACCESS (regs, nip) = (unsigned long) .raise_sigusr2
but gcc doesn't like this ;)
...
Yes, I verified the patch below fixes step-jump-cont.c on
On Wed, 09 Dec 2009 19:31:52 +0100, Oleg Nesterov wrote:
Hmm. it is obvioulsy racy, static volatile unsigned started
is not atomic and thus the main thread can hang doing
while (started THREADS);
not that I think this explains the failure though.
Thanks, fixed (but the problem is
On Sun, 2009-12-13 at 16:25 -0800, Roland McGrath wrote:
I'm sorry for the delay. I'm picking up with responding to the parts of
your review that I did not include in my first reply. I appreciate very
much the discussion you've had with Oleg about the issues that I did not
address myself. I
On 12/13, Roland McGrath wrote:
Its not entirely clear why we can check pending_attach outside of the
utrace-lock and not be racy.
I think it can be racy sometimes but that does not matter.
Maybe Oleg can verify my logic here. If it's right, he can
add some comments to make it more
TRADING PEÇAS AUTO USADAS
A R F
TRADING PEÇAS AUTO USADAS
A R F
A ARF- Tranding Peças Auto Usadas é a empresa líder no comércio e distribuição de PEÇAS AUTO USADAS, Existindo há 7 anos no Mercado, fomos a 1ª empresa em Portugal a fazer entregas de
On 12/14, Peter Zijlstra wrote:
Quite gross this.. can't we key off the
tracehoook_report_clone_complete() and use a wakeup there?
Yes, we intended to clean this up at some point later. But doing that
is just a distraction and complication right now so we put it off. For
this
On 12/14, Oleg Nesterov wrote:
IOW, we must ensure that if ever clear TIF_NOTIFY_RESUME we must not
miss -pending_attach, correct? and for this case we have mb() after
clear_thread_flag(). Perhaps instead we should add mb__after_clear_bit()
into arch/ hooks, but this needs a lot of
On 12/14, Oleg Nesterov wrote:
IOW, we must ensure that if ever clear TIF_NOTIFY_RESUME we must not
miss -pending_attach, correct? and for this case we have mb() after
clear_thread_flag(). Perhaps instead we should add mb__after_clear_bit()
into arch/ hooks, but this needs a lot of
Yes, I think this is correct. It is fine to miss -pending_attach == T,
and in any case the new attacher can come right after the check, even
if it was checked under utrace-lock.
Right.
It is important that the tracee can't miss, say, UTRACE_REPORT request
(as you already explained), and
On 12/14, Roland McGrath wrote:
In the stopped cases, there are lots of locks and barriers and things
after resuming. (Oleg?)
Every time the tracee resumes after TASK_TRACED it uses utrace-lock
to synchronize with utrace_control/etc, it must see any changes.
And TASK_STOPPED?
12 matches
Mail list logo
