lkml.org 
[lkml]   [2014]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Another preempt folding issue?
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).


[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2014-02-14 18:41    [W:0.681 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site