linux-kernel - Re: [PATCH -tip 2/3] sched/wake

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20150915194945.GI19736@linux-q0g1.site>
Date:	Tue, 15 Sep 2015 12:49:46 -0700
From:	Davidlohr Bueso <dave@...olabs.net>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org, Davidlohr Bueso <dbueso@...e.de>
Subject: Re: [PATCH -tip 2/3] sched/wake_q: Relax to acquire semantics

On Tue, 15 Sep 2015, Peter Zijlstra wrote:

>> Secondly, the wake queues are not concurrent, they're in context, so I
>> don't see ordering matter at all. The only reason its a cmpxchg() is
>> because there is the (small) possibility of two contexts wanting to wake
>> the same task, and we use task_struct storage for the queue.
>
>I don't think we need _any_ barriers here, unless we have concurrent
>users of the wake queues (or want to allow any, do we?).

Exactly, the queues are not concurent and do not need barriers, but some of
our callers do expect them.
--
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/