On 11/16, Roland McGrath wrote:
But this smp_rmb() in task_utrace_struct() is only needed when the
caller does something like
if (task_utrace_flags(tsk))
do_something(task_utrace_struct());
If you look at where task_utrace_struct() is used, it's basically always
like
Now, if we race with another task doing utrace_task_alloc() and see
-utrace != NULL, why should we see the correctly initialized *utrace?
utrace_task_alloc() needs wmb(), and the code like above
read_barrier_depends().
Ok. Please review what I put in (esp. commit c575558) and send patches
On 11/16, Roland McGrath wrote:
Now, if we race with another task doing utrace_task_alloc() and see
-utrace != NULL, why should we see the correctly initialized *utrace?
utrace_task_alloc() needs wmb(), and the code like above
read_barrier_depends().
Ok. Please review what I put in
Just in case fyi, I cooked the almost identical patch yesterday, but
it didn't help: make xcheck crashes. Not that I really expected it can
help on x86.
Right.
Not sure I understand exactly... Yes, sometimes we know we don't need
read_barrier_depends(). For example,
@@ -302,7
On 11/16, Roland McGrath wrote:
But read_barrier_depends() does nothig except on alpha, why should we
care?
I thought this was the barrier you were talking about. Anyway, we should
be pedantically correct about these. (People do even still build
Linux/Alpha.)
Yes, sure. I meant, we
Yes, sure. I meant, we shouldn't worry that this barrier adds too much
overhead to task_utrace_struct().
Ah! Sorry, I misread you. Yes, good point.
We don't have the explicit barrier, but I think it is not needed.
In this case utrace_attach_task() does unlock+lock at least once
before
On 11/16, Oleg Nesterov wrote:
UPD: tested the kernel with this patch, now late-ptrace-may-attach-check
crashes the kernel silently (no output under kvm).
Repeated this test. Got several oopses, bad spinlock magic in utrace-lock.
The stack trace varies, often from utrace_get_signal().
Oh,
