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!
>
> With or without these fixes utrace_control()->mark_engine_detached()
> was always wrong if it races with REPORT/REPORT_CALLBACKS. Not sure
> what we were thinking about :/
>
> Look. Suppose that utrace_control(DETACH) is called right after
> start_callback() returns ops != NULL. After that
> finish_callback(..., ops->callback(...)) can hit ->callback == NULL!
Cough. I guess I spent too much time with utrace and testing today ;)
Let me try again. mark_engine_detached() does
engine->ops = &utrace_detached_ops;
smp_wmb();
engine->flags = UTRACE_EVENT(QUIESCE);
Whatever we do, start_callback() can see the old engine->flags but
the new ->ops = &utrace_detached_ops. Just suppose that the caller
of UTRACE_DETACH is interrupted right after setting engine->ops.
> The obvious and simplest solution: utrace_detached_ops{} should
> have the dummy handler for every callback. But I'd like to think
> a bit more.
Yes. Perhaps (unlikely) we can reverse the order, but I can no longer
think properly today.
Or do you think I miss something and this is false alarm?
Oleg.
