diff options
| author |   Darrick J. Wong <djwong@kernel.org> | 2025-09-15 17:24:48 -0700 |
|---|---|---|
| committer |   Miklos Szeredi <mszeredi@redhat.com> | 2025-09-23 11:32:17 +0200 |
| commit | 0d375a1385ed80d8c84433fb54062a9253ccf7e5 (patch) | |
| tree | ddc78d406c003efa169296b48e47a284595dcf1d /scripts/kernel-doc.py | |
| parent | fuse: fix livelock in synchronous file put from fuseblk workers (diff) | |
| download | wireguard-linux-0d375a1385ed80d8c84433fb54062a9253ccf7e5.tar.xz wireguard-linux-0d375a1385ed80d8c84433fb54062a9253ccf7e5.zip | |
fuse: capture the unique id of fuse commands being sent
The fuse_request_{send,end} tracepoints capture the value of
req->in.h.unique in the trace output. It would be really nice if we
could use this to match a request to its response for debugging and
latency analysis, but the call to trace_fuse_request_send occurs before
the unique id has been set:
fuse_request_send: connection 8388608 req 0 opcode 1 (FUSE_LOOKUP) len 107
fuse_request_end: connection 8388608 req 6 len 16 error -2
(Notice that req moves from 0 to 6)
Move the callsites to trace_fuse_request_send to after the unique id has
been set by introducing a helper to do that for standard fuse_req
requests. FUSE_FORGET requests are not covered by this because they
appear to be synthesized into the event stream without a fuse_req
object and are never replied to.
Requests that are aborted without ever having been submitted to the fuse
server retain the behavior that only the fuse_request_end tracepoint
shows up in the trace record, and with req==0.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Diffstat (limited to 'scripts/kernel-doc.py')
0 files changed, 0 insertions, 0 deletions