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: Wed, 4 May 2011 13:11:34 +0200 (CEST) From: Thomas Gleixner <tglx@...utronix.de> To: Ingo Molnar <mingo@...e.hu> cc: Linus Torvalds <torvalds@...ux-foundation.org>, Jens Axboe <axboe@...nel.dk>, Andrew Morton <akpm@...ux-foundation.org>, werner <w.landgraf@...ru>, "H. Peter Anvin" <hpa@...or.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: [block IO crash] Re: 2.6.39-rc5-git2 boot crashs On Wed, 4 May 2011, Ingo Molnar wrote: > > * Thomas Gleixner <tglx@...utronix.de> wrote: > > > But I rather suspect, that CONFIG_SLUB=y is the thing we need to look at. The > > lockless fastpath cmpxchg comes to my mind. > > Hm, and CONFIG_X86_ELAN, as Linus noted, has an impact on the cmpxchg > implementation. Exactly. With ELAN CONFIG_X86_CMPXCHG64 is not set. When I disable ELAN it's set. > > Either we generate broken code with that ELAN caused options or that combo > > triggers some hidden problem in SLUB. > > Note that the crash went away with SLUB_DEBUG=y and PAGEALLOC=y and > SLUB_DEBUG=y would certainly narrow any lockless-SLUB race windows. Well, it's pretty simple: CONFIG_X86_CMPXCHG64=y compiles this_cpu_generic_cmpxchg_double() into: 28f7: 89 f9 mov %edi,%ecx 28f9: 8b 3e mov (%esi),%edi 28fb: 89 45 e4 mov %eax,-0x1c(%ebp) 28fe: 89 c3 mov %eax,%ebx 2900: 8b 45 f0 mov -0x10(%ebp),%eax 2903: 64 0f c7 0f cmpxchg8b %fs:(%edi) 2907: 0f 94 c0 sete %al 290a: 84 c0 test %al,%al 290c: 88 45 e4 mov %al,-0x1c(%ebp) 290f: 74 a4 je 28b5 <kmem_cache_alloc+0x29> while CONFIG_X86_CMPXCHG64=n results in: 28b0: 8b 03 mov (%ebx),%eax 28b2: 64 8b 30 mov %fs:(%eax),%esi 28b5: 39 d6 cmp %edx,%esi 28b7: 75 d2 jne 288b <kmem_cache_alloc+0x26> 28b9: 64 8b 50 04 mov %fs:0x4(%eax),%edx 28bd: 39 ca cmp %ecx,%edx 28bf: 75 ca jne 288b <kmem_cache_alloc+0x26> 28c1: 8b 4b 14 mov 0x14(%ebx),%ecx 28c4: 8b 0c 0e mov (%esi,%ecx,1),%ecx 28c7: 64 89 08 mov %ecx,%fs:(%eax) 28ca: 8b 03 mov (%ebx),%eax 28cc: 42 inc %edx 28cd: 64 89 50 04 mov %edx,%fs:0x4(%eax) And that code runs with preemption enabled. So when the task gets preempted _BEFORE_ it has actuallty written back the data, then the race window is wide open. I'm still trying to understand that macro hell which actually generates that code. I always thought that George Anzingers macro maze was horrible, but that's even worse. Thanks, tglx -- 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