On 09/07, Roland McGrath wrote:
>
> Makes sense. In commit ac6e19c the body looks like this:
> {
> struct utrace_engine *engine, *next;
>
> BUG_ON(!utrace->reap);
>
> splice_attaching(utrace);
>
> /*
> * Since we were called with @utrace->reap set, nobody can
> * set/clear UTRACE_EVENT(REAP) in @engine->flags or change
> * @engine->ops, and nobody can change @utrace->attached.
> */
> spin_unlock(&utrace->lock);
>
> list_for_each_entry_safe(engine, next, &utrace->attached, entry) {
> if (engine->flags & UTRACE_EVENT(REAP))
> engine->ops->report_reap(engine, target);
>
> engine->ops = NULL;
> engine->flags = 0;
> list_del_init(&engine->entry);
>
> utrace_engine_put(engine);
Agreed! No need to delay utrace_engine_put().
> I believe this only affects utrace_barrier. See the next reply about that.
OK,
> Can you think of another effect?
No... I think this should be fine.
It looks a bit tidier to me. Because, if we clear ->ops first, this
looks as if we have a reason to clear ->ops before ->report_reap().
That is why I asked "is ot ok?", I was afraid I missed something
subtle.
Oleg.
