linux-kernel - Re: [PATCH] It may not be assumed that wake_up(), finish

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:	Thu, 23 Apr 2009 10:07:04 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Howells <dhowells@...hat.com>
cc:	Ingo Molnar <mingo@...e.hu>, Oleg Nesterov <oleg@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>, serue@...ibm.com,
	viro@...iv.linux.org.uk,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] It may not be assumed that wake_up(), finish_wait() and
 co. imply a memory barrier

On Thu, 23 Apr 2009, David Howells wrote:
>
> I was wondering if wake_up() and friends should in fact imply smp_wmb(), but I
> guess that they're often used in conjunction with spinlocks - and in such a
> situation a barrier is unnecessary overhead.

I think we _have_ to imply a smp_wmb() in the wakup semantics, because 
otherwise sleepers can't do anything sane (no amount of barriers on the 
sleeping side will help). IOW, there basically has to be an implied write 
barrier between the thing that causes an event to become true, and the 
thing that turns 'task->state' back to RUNNING.

This is similar to the issue of doing cross-CPU IPI's: sending an IPI 
_must_ imply a memory barrier with the IPI mechanism, because otherwise 
the receiver could never do anything sane.

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