Re: [4.14-rc7] task struct corruption after fork

[Dave Jones <davej@codemonkey.org.uk>]

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