Message ID | 20170913180928.22498-1-bo.li.liu@oracle.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Wed, Sep 13, 2017 at 12:09:28PM -0600, Liu Bo wrote: > 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> > cc: David Sterba <dsterba@suse.cz> Ok, understood now, thanks. I suggest to use noinline_for_stack, that is made exactly for this situation (I'll change it so you don't need to resend). Reviewed-by: David Sterba <dsterba@suse.com> -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/btrfs/async-thread.c b/fs/btrfs/async-thread.c index ff0b0be..593709a 100644 --- a/fs/btrfs/async-thread.c +++ b/fs/btrfs/async-thread.c @@ -67,7 +67,7 @@ struct btrfs_workqueue { static void normal_work_helper(struct btrfs_work *work); #define BTRFS_WORK_HELPER(name) \ -void btrfs_##name(struct work_struct *arg) \ +noinline void btrfs_##name(struct work_struct *arg) \ { \ struct btrfs_work *work = container_of(arg, struct btrfs_work, \ normal_work); \
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> cc: David Sterba <dsterba@suse.cz> --- fs/btrfs/async-thread.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)