linux-kernel - Re: [PATCH] ipc/msg: Implement 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]

Message-ID: <20151031185457.GC7947@linux-uzut.site>
Date:	Sat, 31 Oct 2015 11:54:57 -0700
From:	Davidlohr Bueso <dave@...olabs.net>
To:	George Spelvin <linux@...izon.com>
Cc:	bigeasy@...utronix.de, tglx@...utronix.de,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	manfred@...orfullife.com, peterz@...radead.org
Subject: Re: [PATCH] ipc/msg: Implement lockless pipelined wakeups

On Sat, 31 Oct 2015, George Spelvin wrote:

>> Don't we need to keep that NULL init? I might be missing something.
>
>I wondered the same thing, but on reading it, the cleanup is that he's
>gotten rid of the need for the entire thing.  Previously, there was a
>mechanism for detecting "wakeup not quite finished" that used a NULL
>value, but it's no longer needed.
>
>The resultant busy-waiting on the part of the woken-up task was the
>entire problem this patch aims to fix.  So it gets rid of a whole lot
>of code and barriers.  And, as you noticed, the comments explaining them.
>
>As the old code explained, the issue is that a task may exit as
>soon as r_msg is set, so the wakeup procedure has to be:
>- Ensure r_msg is set to NULL (special-case flag)
>- Do the wake up
>- Set r_msg to the final value
>
>The woken-up task has to spin as long as r_msg is NULL.  Ick.

I agree this is a nice cleanup. It is similar to what we did
with posix mqueues, but this one gets rid of even more code afaict.

>However, a wake_q keeps a reference to a task, so exiting is
>not a danger.  As long as wake_q_add precedes setting r_msg,
>all is well.

Yes, and this confirms that we still rely on the implicit barrier
from the cmpxchg as tglx mentioned. As such, we also need to keep
the pairing when reading 'r_msg' in do_msgrcv(), instead of dropping
the comments.

Thanks,
Davidlohr
--
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/