Re: [PATCH 2/2] NFS: NFSERR_INVAL is not defined by NFSv2

["Chuck Lever" <cel@kernel.org>]

On Fri, Aug 28, 2026, at 5:18 PM, Tom Rini wrote:
> On Fri, Aug 28, 2026 at 05:06:14PM -0400, Chuck Lever wrote:
>> 
>> 
>> On Fri, Aug 28, 2026, at 4:51 PM, Tom Rini wrote:
>> > On Fri, Aug 28, 2026 at 09:27:41AM -0400, Chuck Lever wrote:
>> >> 
>> >> 
>> >> On Fri, Aug 28, 2026, at 7:33 AM, NeilBrown wrote:

>> >> > U-boot has
>> >> >
>> >> > 		} else if ((rlen == -NFSERR_ISDIR) || (rlen == -NFSERR_INVAL)) {
>> >> > 			/* symbolic link */
>> >> > 			nfs_state = STATE_READLINK_REQ;
>> >> > 			nfs_send();
>> >> >

>> The "deployments can't be updated" also doesn't make sense: if
>> they can't be updated, they won't be able to get the revert
>> either.
>
> By deployments I mean U-Boot deployments. It's notoriously hard to
> update firmwares most of the time. Some testing labs refuse to because
> of the value in testing the firmware most people likely have deployed
> rather than the latest and greatest. So most of the time, it's never
> updated. Can newer systems take advantage of good and specification
> following update mechanisms? Sure. In practice? Only maybe.

I'm talking about changing NFSD to return NFSERR_ISDIR, which would
be picked up by the first "if" check above, which already exists
in U-Boot.

That addresses the regression and can be backported into the LTS
Linux kernels that have commit 0ac903d1bfdc [*]. It does not depend
on making changes to U-Boot.

Since the problem was reported on linux-nfs and refers to a
specific Linux kernel commit hash, I assumed the only thing on
the table is a code change in NFSD.


-- 
Chuck Lever

[*] AFAICT, the only two LTS kernels that are affected are v6.12
    and v6.18. The stable kernels (v7.1 and v7.2) would also be
    impacted.