Re: [PATCH 3/3] ipc/mqueue: lockless pipelined wakeups

["George Spelvin" <linux@horizon.com>]

> 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>