> 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 <li...@horizon.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
