linux-kernel - Re: [Uclinux-dist-devel] [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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 13 Feb 2009 23:58:35 -0500
From:	Robin Getz <rgetz@...ckfin.uclinux.org>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:	uclinux-dist-devel@...ckfin.uclinux.org,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	"Mathieu Desnoyers" <compudj@...stal.dyndns.org>,
	ltt-dev@...ts.casi.polymtl.ca, linux-kernel@...r.kernel.org
Subject: Re: [Uclinux-dist-devel] [ltt-dev] [RFC git tree] Userspace RCU (urcu) for Linux (repost)

On Thu 12 Feb 2009 15:13, Linus Torvalds pondered:
> On Thu, 12 Feb 2009, Paul E. McKenney wrote:
> > And, now that you mention it, I have heard rumors that other CPU 
> > families can violate cache coherence in some circumstances.
> 
> I personally suspect that the BF pseudo-SMP code is just broken, and
> that it likely has tons of subtle bugs and races - because we _do_ depend
> on cache coherency at least for accessing objects next to each other.

I felt similarly, however after using it, testing it, beating the crap out of 
it for while, and only finding a few niggly bugs which were corrected - it 
appears to be as stable as any other Linux kernel I have used on embedded 
hardware (which means rock solid).

There are a few people shipping it in their products today - so at least the 
stablily was also good enough for them.

If you have any other test suggestions which might expose the corner cases 
that normal use / LTP /  would not - I'm happy to try it out. The problem 
is - as Mike stated - since we do limit applications to one core at a time - 
multi-threading userspace isn't really interesting a problem.

As for the claim of "broken" hardware - I don't think that is true -- the 
hardware works as designed, as advertised. It was just never architected to 
run a SMP operating system. While you could claim that we are trying to force 
fit (SMP) something where it doesn't belong (non-cache coherence system), it 
is us that are "broken" - not the hardware :)

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