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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/