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
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 kind of
callback might be in progress.
(Hmm. Probably utrace-reap = T case
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
Please feel free to ignore this if it's no longer relevant to your work.
I'm trying to catch up on the backlog of replies I owe you. I chose
this one as the arbitrary cut-off before which I think I have already
neglected things too long to still matter.
If engine is detached (has