linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH RFC] Btrfs: fix confusing worker helper info
@ 2017-09-08 21:34 Liu Bo
  2017-09-13 15:34 ` David Sterba
  0 siblings, 1 reply; 2+ messages in thread
From: Liu Bo @ 2017-09-08 21:34 UTC (permalink / raw)
  To: linux-btrfs

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.

Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
---
 fs/btrfs/async-thread.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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);		\
-- 
2.9.4


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH RFC] Btrfs: fix confusing worker helper info
  2017-09-08 21:34 [PATCH RFC] Btrfs: fix confusing worker helper info Liu Bo
@ 2017-09-13 15:34 ` David Sterba
  0 siblings, 0 replies; 2+ messages in thread
From: David Sterba @ 2017-09-13 15:34 UTC (permalink / raw)
  To: Liu Bo; +Cc: linux-btrfs

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.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-09-13 15:35 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-09-08 21:34 [PATCH RFC] Btrfs: fix confusing worker helper info Liu Bo
2017-09-13 15:34 ` David Sterba

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).