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
| ||
|
Date: Mon, 02 Jul 2007 17:06:31 +1000 From: Nick Piggin <nickpiggin@...oo.com.au> To: Linus Torvalds <torvalds@...ux-foundation.org> CC: Eric Dumazet <dada1@...mosbay.com>, Chuck Ebbert <cebbert@...hat.com>, Ingo Molnar <mingo@...e.hu>, Jarek Poplawski <jarkao2@...pl>, Miklos Szeredi <miklos@...redi.hu>, chris@...ee.ca, linux-kernel@...r.kernel.org, tglx@...utronix.de, akpm@...ux-foundation.org Subject: Re: [BUG] long freezes on thinkpad t60 Linus Torvalds wrote: > Nick, > call me a worry-wart, but I slept on this, and started worrying.. > > On Tue, 26 Jun 2007, Linus Torvalds wrote: > >>So try it with just a byte counter, and test some stupid micro-benchmark >>on both a P4 and a Core 2 Duo, and if it's in the noise, maybe we can make >>it the normal spinlock sequence just because it isn't noticeably slower. > > > So I thought about this a bit more, and I like your sequence counter > approach, but it still worried me. > > In the current spinlock code, we have a very simple setup for a > successful grab of the spinlock: > > CPU#0 CPU#1 ... Yeah, thanks. > Now, I have good reason to believe that all Intel and AMD CPU's have a > stricter-than-documented memory ordering, and that your spinlock may > actually work perfectly well. But it still worries me. As far as I can > tell, there's a theoretical problem with your spinlock implementation. > > So I'd like you to ask around some CPU people, and get people from both > Intel and AMD to sign off on your spinlocks as safe. I suspect you already > have the required contacts, but if you don't, I can send things off to the > appropriate people at least inside Intel. Haven't made too much progress on this, but I have asked someone@amd who might be able to at least know the right person to ask :P (might be faster to ask Andi to ask :)) If you know someone at Intel then that would be appreciated. It would be nice if it is safe (and can be guaranteed to be safe in future). However OTOH, the fastpath may be even faster if we do it in a "definitely safe" way. That is, do the xaddw against 16-bits with the head in 8 of those and the tail in the other 8. Then compare the byte registers of the register returned by xaddw for the test. Although the xaddw is going to be slower than an xaddb, this way we subsequently avoid the extra load completely, while avoiding ordering issues. In the slowpath we would have to have a token locked op in there (like the current spinlocks do), but this could be taken out iff our inquiries come back positive. Anyway, I'll try redoing the patch and getting some numbers. -- SUSE Labs, Novell Inc. - 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/
Powered by blists - more mailing lists