Re: [PATCH] Btrfs: fix confusing worker helper info

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
> cc: David Sterba <dsterba@xxxxxxx>

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@xxxxxxxx>
--
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




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux