rik.theys writes via Kernel.org Bugzilla: (In reply to Chuck Lever from comment #25) > > [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. I've opened Bug #219737 for this. Regards, Rik View: https://bugzilla.kernel.org/show_bug.cgi?id=219710#c27 You can reply to this message to join the discussion. -- Deet-doot-dot, I am a bot. Kernel.org Bugzilla (bugspray 0.1-dev)
