linux-kernel - Re: [ltt-dev] [RFC git tree] Userspace RCU (urcu) for Linux (repost)

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]

Date:	Sat, 14 Feb 2009 00:50:43 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	paulmck@...ux.vnet.ibm.com
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	ltt-dev@...ts.casi.polymtl.ca, linux-kernel@...r.kernel.org,
	Bryan Wu <cooloney@...nel.org>,
	uclinux-dist-devel@...ckfin.uclinux.org
Subject: Re: [ltt-dev] [RFC git tree] Userspace RCU (urcu) for Linux (repost)

On Friday 13 February 2009 08:59:59 Paul E. McKenney wrote:
> On Thu, Feb 12, 2009 at 01:15:08PM -0800, Linus Torvalds wrote:
> > On Thu, 12 Feb 2009, Paul E. McKenney wrote:
> > > In other words, you are arguing for using ACCESS_ONCE() in the loops,
> > > but keeping the old ACCESS_ONCE() definition, and declaring BF hardware
> > > broken?
> >
> > Well, I _also_ argue that if you have a busy loop, you'd better have a
> > cpu_relax() in there somewhere anyway. If you don't, you have a bug.
> >
> > So I think the BF approach is "borderline broken", but I think it should
> > work, if BF just has whatever appropriate cache flush in its cpu_relax.
>
> OK, got it.  Keep ACCESS_ONCE() as is, make sure any busy-wait
> loops contain a cpu_relax().  A given busy loop might or might not
> need ACCESS_ONCE(), but that decision is independent of hardware
> considerations.
>
> Ah, and blackfin's cpu_relax() does seem to have migrated from barrier()
> to smp_mb() recently, so sounds good to me!!!


Interesting. I don't know if you would say it is not cache coherent.
Does anything in cache coherency definition require timeliness? Only
causality I think.

However I think "infinite write buffering delay", or requiring "cache
barriers" is insane to teach any generic code about. BF would be free
to optimise arch functions, but for correctness surely it must also
have a periodic interrupt that will expose stores to other CPUs.

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