On Mon, Oct 30, 2017 at 11:59:30AM -0700, Linus Torvalds wrote:
> and that location would *almost* make sense in that it's the end of
> the same page that contained a "struct task_struct".
>
> Are you running with VMAP_STACK? Is there perhaps some stale code that
> ends up doing the old "stack pointer is in the same allocation as task
> struct"?
yeah, it's enabled.
> If you have the kernel symbols for that image, can you look up if any
> of those addresses look like any static kernel symbol addresses? Those
> things that have the pattern ffffffff8xxxxxxx might be symbol
> addresses and give us a clue about where the values came from.
it got clobbered by another build, but I managed to rebuild it from the
older config. Modulo modules that were loaded, things should be the same.
> ffffffff81172d1e r15
ffffffff81172d00 t usage_match
ffffffff81172d30 t HARDIRQ_verbose
> ffffffff8426daec r14
ffffffff841cee60 b lock_classes
ffffffff844eed00 B nr_lock_classes
> ffffed008b17e001 r13
> ffffffff811737e2 r12
ffffffff81173540 t __bfs
ffffffff81173970 t check_noncircular
> ffffffff8426dbe0 rbp
ffffffff841cee60 b lock_classes
ffffffff844eed00 B nr_lock_classes
> ffff880458bf0008 rbx
> ffffffff84590d00 r11
ffffffff841cee60 b lock_classes
ffffffff844eed00 B nr_lock_classes
> 5 r10
> ffffffff81172d00 r9
ffffffff81172d00 t usage_match
> 1 r8
> 1ffff1008b17dfed rax
> ffff880458bf00f0 rcx
> ffffed008b17dff9 rdx
> dffffc0000000000 rsi
> 41b58ab3 rdi
> ffffffff82a349a8 orig_eax
ffffffff828a7f40 R inat_primary_table
ffffffff82a42840 r POLY
> ffffffff81173540 rip
ffffffff81173540 t __bfs
> 5a5a5a5a5a5a5a5a
> ffffffff8450f080 flags
ffffffff844eed40 b list_entries
ffffffff846eed60 B nr_list_entries
So a bunch of lockdep stuff, and not much else afaics.
Dave
