Btrfs: fix confusing worker helper info in stacktrace
authorLiu Bo <bo.li.liu@oracle.com>
Wed, 13 Sep 2017 18:09:28 +0000 (12:09 -0600)
committerDavid Sterba <dsterba@suse.com>
Mon, 30 Oct 2017 11:27:57 +0000 (12:27 +0100)
commit6939f667247ed792535c0697a99f600d6770f127
tree388c1a6bd0c8f24adff2ce5c1c482c6275e684be
parent18fdc67900c5bfd1eeb41cfa50ea6f2eb7266f73
Btrfs: fix confusing worker helper info in stacktrace

We've seen the following backtrace stack in ftrace or dmesg log,

  kworker/u16:10-4244  [000] 241942.480955: function:             btrfs_put_ordered_extent
  kworker/u16:10-4244  [000] 241942.480956: kernel_stack:         <stack trace>
=> finish_ordered_fn (ffffffffa0384475)
=> btrfs_scrubparity_helper (ffffffffa03ca577)        <-----"incorrect"
=> btrfs_freespace_write_helper (ffffffffa03ca98e)    <-----"correct"
=> process_one_work (ffffffff81117b2f)
=> worker_thread (ffffffff81118c2a)
=> kthread (ffffffff81121de0)
=> ret_from_fork (ffffffff81d7087a)

btrfs_freespace_write_helper is actually calling normal_worker_helper
instead of btrfs_scrubparity_helper, so somehow kernel has parsed the
incorrect function address while unwinding the stack,
btrfs_scrubparity_helper really shouldn't be shown up.

It's caused by compiler doing inline for our helper function, adding a
noinline tag can fix that.

Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: David Sterba <dsterba@suse.com>
[ use noinline_for_stack ]
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/async-thread.c