On Fri, Sep 08, 2017 at 03:34:45PM -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) > => btrfs_freespace_write_helper (ffffffffa03ca98e) > => process_one_work (ffffffff81117b2f) > => worker_thread (ffffffff81118c2a) > => kthread (ffffffff81121de0) > => ret_from_fork (ffffffff81d7087a) > > 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. Isn't it the other way around then? Noninline would make the function object exist separately and then it would appear in the stacktrace. And I think this is desired, so you see the call stack withtou the shortcuts that the inlining can cause. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
