linux-kernel - Re: [uclinux-dist-devel] [PATCH] mutex:SMP:bf561:Run smp memory barrier after take atomic lock in mutex

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] [day] [month] [year] [list]

Message-ID: <CAJaTeTpbeAmTXX_Tf7WnGha9o-3u47Y3GABzkqk11ECk72HLXw@mail.gmail.com>
Date:	Wed, 26 Oct 2011 06:12:29 -0400
From:	Mike Frysinger <vapier@...too.org>
To:	"Zhang, Sonic" <Sonic.Zhang@...log.com>
Cc:	Sonic Zhang <sonic.adi@...il.com>,
	"uclinux-dist-devel@...ckfin.uclinux.org" 
	<uclinux-dist-devel@...ckfin.uclinux.org>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [uclinux-dist-devel] [PATCH] mutex:SMP:bf561:Run smp memory
 barrier after take atomic lock in mutex_fastpath APIs.

On Wed, Oct 26, 2011 at 04:53, Zhang, Sonic wrote:
> Our SMP atomic implementation doesn't include memory barrier. Is it a better way to add barrier there?

i'll have to re-read the thread myself, but i thought the conclusions
of that thread were implemented in the Blackfin tree now

so if the conclusion was we needed barriers in the atomic funcs, and
we don't have them now, then that probably is the way to go instead
... but i'll have to review things in depth later
-mike
--
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/