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

From: Dave Jones
Date: Mon Oct 30 2017 - 16:35:24 EST


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