Date: 4 May 2015 20:37:13 -0400
Message-ID: <20150505003713.20276.qmail@ns.horizon.com>
From: "George Spelvin" <linux@horizon.com>
To: dave@stgolabs.net, linux@horizon.com
Subject: Re: [PATCH 3/3] ipc/mqueue: lockless pipelined wakeups
Cc: bigeasy@linutronix.de, clm@fb.com, linux-kernel@vger.kernel.org,
        manfred@colorfullife.com, mingo@redhat.com, peterz@infradead.org,
        rostedt@goodmis.org, tglx@linutronix.de, torvalds@linux-foundation.org
In-Reply-To: <1430526956.1940.8.camel@stgolabs.net>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1957
Lines: 46

> You are not wrong, but I'd rather leave the comment as is, as it will
> vary from user to user. The comments in the sched wake_q bits are
> already pretty clear, and if users cannot see the need for holding
> reference and the task disappearing on their own they have no business
> using wake_q. Furthermore, I think my comment serves better in mqueues
> as the need for it isn't immediately obvious.

Okay, but the comment is still rather awkward and hard-to-follow English.

How about:
	/*
	 * Rely on the implicit cmpxchg barrier from wake_q_add to
	 * ensure that updating receiver->state is the last write
	 * operation.  Once set, the receiver can continue, and if we
	 * hadn't placed it on the wake_q (which takes a reference to
	 * the task), any later use might cause a use-after-free
	 * condition.
	 */

Part of the confusion is that there are two different ordering conditions
that wake_q_add is involved in, and the comment above (even my version)
isn't good about explaining the distinction:

1) It, itself, must come before the receiver->state update, because
   after that, the receiver may run (and possibly exit).
2) It serves as a write barrier for all the other state writes above.

If I wanted to be clearer, I'd have to do more extensive edits:

	/*
	 * wake_q_add must come before updating receiver->state, since
	 * that write lets the receiver continue (and possibly exit).
	 * The reference count from the wake_q prevents use-after-free.
	 *
	 * The cmpxchg inside wake_q_add also serves as a write barrier
	 * for all the other state updates that must be visible before
	 * receiver->state.
	 */

None of this affects the code, which is
Acked-by: George Spelvin <linux@horizon.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/