summaryrefslogtreecommitdiff
path: root/net/unix/af_unix.c
diff options
context:
space:
mode:
authorDarrick J. Wong <djwong@kernel.org>2025-09-15 17:24:48 -0700
committerMiklos Szeredi <mszeredi@redhat.com>2025-09-23 11:32:17 +0200
commit0d375a1385ed80d8c84433fb54062a9253ccf7e5 (patch)
treeddc78d406c003efa169296b48e47a284595dcf1d /net/unix/af_unix.c
parent26e5c67deb2e1f42a951f022fdf5b9f7eb747b01 (diff)
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 'net/unix/af_unix.c')
0 files changed, 0 insertions, 0 deletions