[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [PATCH 3/4] utrace_reap: do not play with lock/unlock/restart

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.


> 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]