[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150505003713.20276.qmail@ns.horizon.com>
Date: 4 May 2015 20:37:13 -0400
From: "George Spelvin" <linux@...izon.com>
To: dave@...olabs.net, linux@...izon.com
Cc: bigeasy@...utronix.de, clm@...com, linux-kernel@...r.kernel.org,
manfred@...orfullife.com, mingo@...hat.com, peterz@...radead.org,
rostedt@...dmis.org, tglx@...utronix.de,
torvalds@...ux-foundation.org
Subject: Re: [PATCH 3/3] ipc/mqueue: lockless pipelined wakeups
> 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@...izon.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists