On Sun, Oct 29, 2017 at 4:48 PM, Fengguang Wu <fengguang.wu@xxxxxxxxx> wrote:
>
> Here are 3 dmesgs related to wireless and 1 from ethernet.
Fengguang, these would be lovelier still _if_ you have DEBUG_INFO
enabled on the kernel, and your script were to find things like
"symbol+0xhex/0xhex", and run "./scripts/faddr2line" on them.
So
> [ 235.425464] BUG: unable to handle kernel paging request at 0000000000010007
> [ 235.425470] IP: run_timer_softirq+0x13a/0x470
would also then have
run_timer_softirq at timer.c:XYZ
which would make it easier to see exactly _what_ it is that faults. As
it is, I think there's a fair number of inlining that makes it hard to
see the cause, but that faddrtoline would make very obvious.
Finding that "symbol+xyz/abc" pattern should be fairly easy to
automate, and should fit the 0day model fairly well. No?
In this case, the trapping instruction ends up decoding to
0: 4c 8d 6c c5 90 lea -0x70(%rbp,%rax,8),%r13
5: 49 8b 45 00 mov 0x0(%r13),%rax
9: 48 85 c0 test %rax,%rax
c: 74 de je 0xffffffffffffffec
e: 4d 8b 7d 00 mov 0x0(%r13),%r15
12: 4d 89 7c 24 08 mov %r15,0x8(%r12)
17: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
1c: 49 8b 07 mov (%r15),%rax
1f: 49 8b 57 08 mov 0x8(%r15),%rdx
23: 48 85 c0 test %rax,%rax
26: 48 89 02 mov %rax,(%rdx)
29: 74 04 je 0x2f
2b:* 48 89 50 08 mov %rdx,0x8(%rax) <-- trapping instruction
2f: 41 f6 47 2a 20 testb $0x20,0x2a(%r15)
34: 49 c7 47 08 00 00 00 movq $0x0,0x8(%r15)
and %rax has the value 0xffff, so yes, it will trap at 0x10007.
It's not trivial to see just *wjhat* access it is.
I *think* that "testb $32" is checking for TIMER_IRQSAFE in
expire_timers(), and that the oops is due to the list operations in
detach_timer() (inlined).
Which doesn't really help: it looks like the timer lists are corrupt.
With some luck, some register state could have the timer function
pointer in it, and we'd get a hint of *which* timer this is, but that
doesn't look to be the case here either.
I'm not seeing anything to really help debug this here.
Linus
