[PATCH 0/3] UTRACE_DETACH fixes

[Oleg Nesterov]

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.