On 14.02.2014 15:47, Borislav Petkov wrote: > On Fri, Feb 14, 2014 at 03:24:09PM +0100, Stefan Bader wrote: >> Actually, this code just makes so much more sense if I let objdump do >> relocation info... > > Ok, we're pretty sure you have an MFENCE there in resched_task but can > you confirm it please. > > First, does /proc/cpuinfo have the "sse2" string? It should but nowadays > I don't trust anything. > > Then, can you boot that kernel in qemu with the -gdb flag so that it > starts the gdb stub, here's the manpage about it: > > -gdb dev > Wait for gdb connection on device dev. Typical connections will > likely be > TCP-based, but also UDP, pseudo TTY, or even stdio are reasonable > use case. > The latter is allowing to start QEMU from within gdb and establish > the > connection via a pipe: > > (gdb) target remote | exec qemu-system-i386 -gdb stdio ... > > -s Shorthand for -gdb tcp::1234, i.e. open a gdbserver on TCP port > 1234. > > then boot the guest and when it is up, do > > $ gdb ./vmlinux > $ target remote localhost:1234 > > and type in the prompt > > $ (gdb) x/50i resched_task > > It gives here: > > (gdb) x/50i resched_task > 0xffffffff810836f0 <resched_task>: data32 data32 data32 xchg %ax,%ax > 0xffffffff810836f5 <resched_task+5>: push %rbp > 0xffffffff810836f6 <resched_task+6>: mov 0x85e123(%rip),%r10d # > 0xffffffff818e1820 <debug_locks> > 0xffffffff810836fd <resched_task+13>: mov %rsp,%rbp > 0xffffffff81083700 <resched_task+16>: push %r12 > 0xffffffff81083702 <resched_task+18>: test %r10d,%r10d > 0xffffffff81083705 <resched_task+21>: push %rbx > 0xffffffff81083706 <resched_task+22>: mov %rdi,%rbx > 0xffffffff81083709 <resched_task+25>: jne 0xffffffff81083760 > <resched_task+112> > 0xffffffff8108370b <resched_task+27>: mov 0x8(%rbx),%rax > 0xffffffff8108370f <resched_task+31>: mov 0x10(%rax),%rdx > 0xffffffff81083713 <resched_task+35>: and $0x8,%edx > 0xffffffff81083716 <resched_task+38>: jne 0xffffffff8108373c > <resched_task+76> > 0xffffffff81083718 <resched_task+40>: lock orb $0x8,0x10(%rax) > 0xffffffff8108371d <resched_task+45>: mov 0x8(%rbx),%rax > 0xffffffff81083721 <resched_task+49>: mov 0x18(%rax),%r12d > 0xffffffff81083725 <resched_task+53>: callq 0xffffffff812d8fc0 > <debug_smp_processor_id> > 0xffffffff8108372a <resched_task+58>: cmp %r12d,%eax > 0xffffffff8108372d <resched_task+61>: je 0xffffffff810837a0 > <resched_task+176> > 0xffffffff8108372f <resched_task+63>: mfence > ^^^^^^ > I want to make sure the smp_mb() is really replaced with an MFENCE there. > > Thanks! > Okaaay, I think I did what you asked. So yes, there is sse2 in the cpu info. And there is a mfence in the disassembly:
0xc107dcb0 <resched_task>: push %ebp 0xc107dcb1 <resched_task+1>: mov %esp,%ebp 0xc107dcb3 <resched_task+3>: lea %ds:0x0(%esi,%eiz,1),%esi 0xc107dcb8 <resched_task+8>: mov 0x4(%eax),%edx 0xc107dcbb <resched_task+11>: mov 0x8(%edx),%ecx 0xc107dcbe <resched_task+14>: and $0x8,%ecx 0xc107dcc1 <resched_task+17>: jne 0xc107dce7 <resched_task+55> 0xc107dcc3 <resched_task+19>: orb $0x8,%ds:0x8(%edx) 0xc107dcc8 <resched_task+24>: mov 0x4(%eax),%edx 0xc107dccb <resched_task+27>: mov %fs:0xc1a71010,%ecx 0xc107dcd2 <resched_task+34>: mov 0x10(%edx),%edx 0xc107dcd5 <resched_task+37>: cmp %ecx,%edx 0xc107dcd7 <resched_task+39>: je 0xc107dd00 <resched_task+80> 0xc107dcd9 <resched_task+41>: mfence 0xc107dcdc <resched_task+44>: mov %esi,%esi 0xc107dcde <resched_task+46>: mov 0x4(%eax),%eax 0xc107dce1 <resched_task+49>: testb $0x4,0xc(%eax) 0xc107dce5 <resched_task+53>: je 0xc107dcf0 <resched_task+64> 0xc107dce7 <resched_task+55>: pop %ebp 0xc107dce8 <resched_task+56>: ret 0xc107dce9 <resched_task+57>: lea 0x0(%esi,%eiz,1),%esi 0xc107dcf0 <resched_task+64>: mov %edx,%eax 0xc107dcf2 <resched_task+66>: call *0xc1917950 0xc107dcf8 <resched_task+72>: pop %ebp Thinking about it, I guess Peter is quite right saying that I likely will end on the patch that converted preempt_count to percpu. One thing I likely should do is to reinstall the exact same laptop with 64bit kernel and userspace... maybe only 64bit kernel first... and make sure on my side that this does not show up on 64bit, too. I took the word of reporters for that (and the impression that otherwise many more people would have complained).
signature.asc
Description: OpenPGP digital signature
