On 2016-12-21 08:33:03 [+0800], Qu Wenruo wrote:
The trace point only uses the pointer, and this helps us to pair with
btrfs_work_queued/sched.
| /* For situiations that the work is freed */
| DECLARE_EVENT_CLASS(btrfs__work__done,
|
| TP_PROTO(struct btrfs_work *work),
|
| TP_ARGS(work),
|
| TP_STRUCT__entry_btrfs(
| __field( void *, work )
| ),
|
| TP_fast_assign_btrfs(btrfs_work_owner(work),
| __entry->work = work;
| ),
|
| TP_printk_btrfs("work->%p", __entry->work)
| );
and btrfs_work_owner exapnds to:
| struct btrfs_fs_info *
| btrfs_work_owner(struct btrfs_work *work)
| {
| return work->wq->fs_info;
| }
voilÃ
But I still don't understand why backtrace is triggered.
Since we're just recording a pointer, not touching it.
Would you please explain the problem with more details on how it trigger the
problem?
enabled all events played with the fs which was just an upgrade and git
tree sync + checkout so nothing special.
So I think we should either remove the tracepoint completely or change
the arguments to take something else than a potentially freed 'work'.
I'm mostly OK to remove the tracepoint, but such all_workd_done() trace
should still help to determine if it's a workqueue stalled.
Thanks,
Qu
Sebastian
--
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