Re: NFS 4.2 "RPC struct is bad" revisited (with much more detail)

On Mon, Dec 2, 2024 at 12:23 PM J David <j.david.lists@gmail.com> wrote:
>
> On Sun, Dec 1, 2024 at 8:03 PM Rick Macklem <rick.macklem@gmail.com> wrote:
> > Well, this indicates the Debian server is broken. A bitmap and associated
> > attribute values are required for a GETATTR reply of NFS4_OK.
> > This clearly says they are not there.
> >
> > That would result in the client saying the RPC is bad.
>
> Even if the response to that isn't "A problem that occurs only with
> FreeBSD clients is a FreeBSD client problem; it shouldn't do the thing
> that causes that to happen," it could take quite some time for any
> change made by the linux-nfs crowd to filter through to reaching a
> production Debian release.
The bug has been isolated by Chuck Lever III and he has proposed a
patch to the Linux NFS project group, of which he is a member.
I have no idea how long it will take for this patch to find its way into
production release kernels.

I have created FreeBSD bugzilla pr#283538 with attachments, including
Chuck Lever's proposed patch and J. David's shell script to test for it.

I'll leave this bugzilla pr Open until the server patch has been widely
distributed, so that others can fairly easily find out what is going on.

Thanks go to J. David for figuring out how to reproduce the problem
and Chuck Lever to figuring out how to fix it.
It does appear to be in most Linux knfsd kernel servers, so it is probably
in any Linux NFSv4 server you run, although the failure is a rare/oddball case.

rick

>
> Is there a reasonable way to apply Postel's law here and modify the
> client to warn on but accept this behavior rather than erroring out in
> a way that renders the file structure unusable indefinitely?
>
> Even refusing to cache this response if it is unusable would probably
> be an improvement.
>
> Thanks!