Chuck Lever writes via Kernel.org Bugzilla: > [Wed Jan 29 10:11:17 2025] cb_status=-521 tk_status=-10036 -521 = -EBADHANDLE (NFS4ERR_BADHANDLE) -10036 = -NFS4ERR_BAD_XDR I see several similar events in the trace.dat report. My guess is the client is generating BADHANDLE (nfs4_callback_getattr) but the server is having some trouble decoding that result. My first impression is that XDR result decoders are supposed to return -EIO in this case. NFS4ERR_BAD_XDR is supposed to mean the /remote side/ was not able to decode a Call, not the local side couldn't decode the Reply. RFC 8881 Section 20.1.3 states: "If the filehandle specified is not one for which the client holds an OPEN_DELEGATE_WRITE delegation, an NFS4ERR_BADHANDLE error is returned." This appears to be a bug in the new CB_GETATTR implementation. It might or might not cause the callback workqueue to stall, but it should probably be filed as a separate bug. View: https://bugzilla.kernel.org/show_bug.cgi?id=219710#c25 You can reply to this message to join the discussion. -- Deet-doot-dot, I am a bot. Kernel.org Bugzilla (bugspray 0.1-dev)
