[PATCH 0/2] Address minor issues with status codes

[PATCH 0/2] Address minor issues with status codes

[Chuck Lever]

From: Chuck Lever <chuck.lever@oracle.com>

Here are two examples of minor bugs I found when comparing NFSD's
human-generated status code definitions with equivalent xdrgen-
generated headers.

Chuck Lever (2):
  NFSD: Remove NFSERR_EAGAIN
  NFS: NFSERR_INVAL is not defined by NFSv2

 fs/nfs_common/common.c   | 1 -
 fs/nfsd/nfs4proc.c       | 2 +-
 fs/nfsd/nfsd.h           | 1 -
 fs/nfsd/nfsproc.c        | 2 +-
 include/trace/misc/nfs.h | 2 --
 include/uapi/linux/nfs.h | 3 +--
 6 files changed, 3 insertions(+), 8 deletions(-)

-- 
2.52.0

[PATCH 1/2] NFSD: Remove NFSERR_EAGAIN

[Chuck Lever]

From: Chuck Lever <chuck.lever@oracle.com>

I haven't found an NFSERR_EAGAIN in RFCs 1094, 1813, 7530, or 8881.
None of these RFCs have an NFS status code that match the numeric
value "11".

Based on the meaning of the EAGAIN errno, I presume the use of this
status in NFSD means NFS4ERR_DELAY. So replace the one usage of
nfserr_eagain, and remove it from NFSD's NFS status conversion
tables.

As far as I can tell, NFSERR_EAGAIN has existed since the pre-git
era, but was not actually used by any code until commit f4e44b393389
("NFSD: delay unmount source's export after inter-server copy
completed."), at which time it become possible for NFSD to return
a status code of 11 (which is not valid NFS protocol).

Fixes: f4e44b393389 ("NFSD: delay unmount source's export after inter-server copy completed.")
X-Cc: stable@vger.kernel.org
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---
 fs/nfs_common/common.c   | 1 -
 fs/nfsd/nfs4proc.c       | 2 +-
 fs/nfsd/nfsd.h           | 1 -
 include/trace/misc/nfs.h | 2 --
 include/uapi/linux/nfs.h | 1 -
 5 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/fs/nfs_common/common.c b/fs/nfs_common/common.c
index af09aed09fd2..0778743ae2c2 100644
--- a/fs/nfs_common/common.c
+++ b/fs/nfs_common/common.c
@@ -17,7 +17,6 @@ static const struct {
 	{ NFSERR_NOENT,		-ENOENT		},
 	{ NFSERR_IO,		-EIO		},
 	{ NFSERR_NXIO,		-ENXIO		},
-/*	{ NFSERR_EAGAIN,	-EAGAIN		}, */
 	{ NFSERR_ACCES,		-EACCES		},
 	{ NFSERR_EXIST,		-EEXIST		},
 	{ NFSERR_XDEV,		-EXDEV		},
diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
index 814d78f23a03..4c708cf02849 100644
--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -1504,7 +1504,7 @@ static __be32 nfsd4_ssc_setup_dul(struct nfsd_net *nn, char *ipaddr,
 					(schedule_timeout(20*HZ) == 0)) {
 				finish_wait(&nn->nfsd_ssc_waitq, &wait);
 				kfree(work);
-				return nfserr_eagain;
+				return nfserr_jukebox;
 			}
 			finish_wait(&nn->nfsd_ssc_waitq, &wait);
 			goto try_again;
diff --git a/fs/nfsd/nfsd.h b/fs/nfsd/nfsd.h
index 50be785f1d2c..b0283213a8f5 100644
--- a/fs/nfsd/nfsd.h
+++ b/fs/nfsd/nfsd.h
@@ -233,7 +233,6 @@ void		nfsd_lockd_shutdown(void);
 #define	nfserr_noent		cpu_to_be32(NFSERR_NOENT)
 #define	nfserr_io		cpu_to_be32(NFSERR_IO)
 #define	nfserr_nxio		cpu_to_be32(NFSERR_NXIO)
-#define	nfserr_eagain		cpu_to_be32(NFSERR_EAGAIN)
 #define	nfserr_acces		cpu_to_be32(NFSERR_ACCES)
 #define	nfserr_exist		cpu_to_be32(NFSERR_EXIST)
 #define	nfserr_xdev		cpu_to_be32(NFSERR_XDEV)
diff --git a/include/trace/misc/nfs.h b/include/trace/misc/nfs.h
index c82233e950ac..a394b4d38e18 100644
--- a/include/trace/misc/nfs.h
+++ b/include/trace/misc/nfs.h
@@ -16,7 +16,6 @@ TRACE_DEFINE_ENUM(NFSERR_PERM);
 TRACE_DEFINE_ENUM(NFSERR_NOENT);
 TRACE_DEFINE_ENUM(NFSERR_IO);
 TRACE_DEFINE_ENUM(NFSERR_NXIO);
-TRACE_DEFINE_ENUM(NFSERR_EAGAIN);
 TRACE_DEFINE_ENUM(NFSERR_ACCES);
 TRACE_DEFINE_ENUM(NFSERR_EXIST);
 TRACE_DEFINE_ENUM(NFSERR_XDEV);
@@ -52,7 +51,6 @@ TRACE_DEFINE_ENUM(NFSERR_JUKEBOX);
 		{ NFSERR_NXIO,			"NXIO" }, \
 		{ ECHILD,			"CHILD" }, \
 		{ ETIMEDOUT,			"TIMEDOUT" }, \
-		{ NFSERR_EAGAIN,		"AGAIN" }, \
 		{ NFSERR_ACCES,			"ACCES" }, \
 		{ NFSERR_EXIST,			"EXIST" }, \
 		{ NFSERR_XDEV,			"XDEV" }, \
diff --git a/include/uapi/linux/nfs.h b/include/uapi/linux/nfs.h
index f356f2ba3814..71c7196d3281 100644
--- a/include/uapi/linux/nfs.h
+++ b/include/uapi/linux/nfs.h
@@ -49,7 +49,6 @@
 	NFSERR_NOENT = 2,		/* v2 v3 v4 */
 	NFSERR_IO = 5,			/* v2 v3 v4 */
 	NFSERR_NXIO = 6,		/* v2 v3 v4 */
-	NFSERR_EAGAIN = 11,		/* v2 v3 */
 	NFSERR_ACCES = 13,		/* v2 v3 v4 */
 	NFSERR_EXIST = 17,		/* v2 v3 v4 */
 	NFSERR_XDEV = 18,		/*    v3 v4 */
-- 
2.52.0

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

[Chuck Lever]

From: Chuck Lever <chuck.lever@oracle.com>

A documenting comment in include/uapi/linux/nfs.h claims incorrectly
that NFSv2 defines NFSERR_INVAL. There is no such definition in either
RFC 1094 or https://pubs.opengroup.org/onlinepubs/9629799/chap7.htm

NFS3ERR_INVAL is introduced in RFC 1813.

NFSD returns NFSERR_INVAL for PROC_GETACL, which has no
specification (yet).

However, nfsd_map_status() maps nfserr_symlink and nfserr_wrong_type
to nfserr_inval, which does not align with RFC 1094. This logic was
introduced only recently by commit 438f81e0e92a ("nfsd: move error
choice for incorrect object types to version-specific code."). Given
that we have no INVAL or SERVERFAULT status in NFSv2, probably the
only choice is NFSERR_IO.

Fixes: 438f81e0e92a ("nfsd: move error choice for incorrect object types to version-specific code.")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---
 fs/nfsd/nfsproc.c        | 2 +-
 include/uapi/linux/nfs.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/nfsd/nfsproc.c b/fs/nfsd/nfsproc.c
index 481e789a7697..8873033d1e82 100644
--- a/fs/nfsd/nfsproc.c
+++ b/fs/nfsd/nfsproc.c
@@ -33,7 +33,7 @@ static __be32 nfsd_map_status(__be32 status)
 		break;
 	case nfserr_symlink:
 	case nfserr_wrong_type:
-		status = nfserr_inval;
+		status = nfserr_io;
 		break;
 	}
 	return status;
diff --git a/include/uapi/linux/nfs.h b/include/uapi/linux/nfs.h
index 71c7196d3281..e629c4953534 100644
--- a/include/uapi/linux/nfs.h
+++ b/include/uapi/linux/nfs.h
@@ -55,7 +55,7 @@
 	NFSERR_NODEV = 19,		/* v2 v3 v4 */
 	NFSERR_NOTDIR = 20,		/* v2 v3 v4 */
 	NFSERR_ISDIR = 21,		/* v2 v3 v4 */
-	NFSERR_INVAL = 22,		/* v2 v3 v4 */
+	NFSERR_INVAL = 22,		/*    v3 v4 */
 	NFSERR_FBIG = 27,		/* v2 v3 v4 */
 	NFSERR_NOSPC = 28,		/* v2 v3 v4 */
 	NFSERR_ROFS = 30,		/* v2 v3 v4 */
-- 
2.52.0

Re: [PATCH 0/2] Address minor issues with status codes

[Jeff Layton]

On Tue, 2025-12-09 at 19:28 -0500, Chuck Lever wrote:
> From: Chuck Lever <chuck.lever@oracle.com>
> 
> Here are two examples of minor bugs I found when comparing NFSD's
> human-generated status code definitions with equivalent xdrgen-
> generated headers.
> 
> Chuck Lever (2):
>   NFSD: Remove NFSERR_EAGAIN
>   NFS: NFSERR_INVAL is not defined by NFSv2
> 
>  fs/nfs_common/common.c   | 1 -
>  fs/nfsd/nfs4proc.c       | 2 +-
>  fs/nfsd/nfsd.h           | 1 -
>  fs/nfsd/nfsproc.c        | 2 +-
>  include/trace/misc/nfs.h | 2 --
>  include/uapi/linux/nfs.h | 3 +--
>  6 files changed, 3 insertions(+), 8 deletions(-)

These both look fine to me.

Reviewed-by: Jeff Layton <jlayton@kernel.org>

Re: [PATCH 0/2] Address minor issues with status codes

[NeilBrown]

On Wed, 10 Dec 2025, Jeff Layton wrote:
> On Tue, 2025-12-09 at 19:28 -0500, Chuck Lever wrote:
> > From: Chuck Lever <chuck.lever@oracle.com>
> > 
> > Here are two examples of minor bugs I found when comparing NFSD's
> > human-generated status code definitions with equivalent xdrgen-
> > generated headers.
> > 
> > Chuck Lever (2):
> >   NFSD: Remove NFSERR_EAGAIN
> >   NFS: NFSERR_INVAL is not defined by NFSv2
> > 
> >  fs/nfs_common/common.c   | 1 -
> >  fs/nfsd/nfs4proc.c       | 2 +-
> >  fs/nfsd/nfsd.h           | 1 -
> >  fs/nfsd/nfsproc.c        | 2 +-
> >  include/trace/misc/nfs.h | 2 --
> >  include/uapi/linux/nfs.h | 3 +--
> >  6 files changed, 3 insertions(+), 8 deletions(-)
> 
> These both look fine to me.
> 
> Reviewed-by: Jeff Layton <jlayton@kernel.org>
> 
Agreed.

Reviewed-by: NeilBrown <neil@brown.name>

I cannot easily find a path that would lead to NFSv2 being presented
with nfserr_symlink or nfserr_wrong_type, so that change probably isn't
visible.  I might have missed something though.

Thanks,
NeilBrown
 

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

[Jörg Sommer]

[-- Attachment #1: Type: text/plain, Size: 4070 bytes --]

Chuck Lever schrieb am Di 09. Dez, 19:28 (-0500):
> From: Chuck Lever <chuck.lever@oracle.com>
> 
> A documenting comment in include/uapi/linux/nfs.h claims incorrectly
> that NFSv2 defines NFSERR_INVAL. There is no such definition in either
> RFC 1094 or https://pubs.opengroup.org/onlinepubs/9629799/chap7.htm
> 
> NFS3ERR_INVAL is introduced in RFC 1813.

Hello,

since this commit 0ac903d1bfdce8ff40657c2b7d996947b72b6645 was added, U-Boot
2022.04 (I don't know about newer versions) can no longer access symlinks in
NFS shares. When I revert this commit, U-Boot can load the file behind the
symlink. Real files are no problem.

The file I want to load is a symlink at the server:

```
% ls -l /srv/nfs/boot/Image.gz*
lrwxrwxrwx 1 root root      41  7. Jul 16:29 /srv/nfs-con/boot/Image.gz -> Image.gz-5.15.213-imx8mm+gfffa4b6d4aea+p1
-rw-r--r-- 1 root root 5279373  7. Jul 16:29 /srv/nfs-con/boot/Image.gz-5.15.213-imx8mm+gfffa4b6d4aea+p1
```

Without this commit:

```
u-boot=> nfs 0x42000000 /srv/nfs/boot/Image.gz
Filename '/srv/nfs-con/boot/Image.gz'.
Load address: 0x42000000
Loading: #################################################################
done
Bytes transferred = 5279373 (508e8d hex)
```

But with this commit:

```
u-boot=> nfs 0x42000000 /srv/nfs/boot/Image.gz
Filename '/srv/nfs-con/boot/Image.gz'.
Load address: 0x42000000
Loading:
done
```

This is the network traffic:

```
No.	Time	Protocol	Length	Info
3	0.000370	Portmap	98	V2 GETPORT Call (Reply In 4) MOUNT(100005) V:1 UDP
4	0.000607	Portmap	70	V2 GETPORT Reply (Call In 3) Port:60340
5	0.000949	Portmap	98	V2 GETPORT Call (Reply In 6) NFS(100003) V:2 UDP
6	0.001046	Portmap	70	V2 GETPORT Reply (Call In 5) Port:2049
7	0.001368	MOUNT	126	V2 MNT Call (Reply In 8) /srv/nfs-con/boot
8	0.008026	MOUNT	102	V2 MNT Reply (Call In 7)
9	0.008389	NFS	146	V2 LOOKUP Call (Reply In 10), DH: 0x8c279135/Image.gz
10	0.008754	NFS	170	V2 LOOKUP Reply (Call In 9), FH: 0xcdddf154
11	0.009095	NFS	146	V2 READ Call (Reply In 12), FH: 0xcdddf154 Offset: 0 Count: 1024 TotalCount: 0
12	0.009189	NFS	70	V2 READ Reply (Call In 11) Error: NFS2ERR_IO
13	0.009511	MOUNT	102	V2 UMNTALL Call (Reply In 14)
14	0.010301	MOUNT	66	V2 UMNTALL Reply (Call In 13)
```

From packet 11 V2 READ Call

```
Remote Procedure Call, Type:Call XID:0x000050e1
    XID: 0x000050e1 (20705)
    Message Type: Call (0)
    RPC Version: 2
    Program: NFS (100003)
    Program Version: 2
    Procedure: READ (6)
    [The reply to this request is in frame 12]
    Credentials
        Flavor: AUTH_UNIX (1)
        Length: 20
        Stamp: 0x00000000
        Machine Name: <EMPTY>
        UID: 0
        GID: 0
        Auxiliary GIDs (0)
    Verifier
        Flavor: AUTH_NULL (0)
        Length: 0
Network File System, READ Call FH: 0xcdddf154 Offset: 0 Count: 1024 TotalCount: 0
    [Program Version: 2]
    [V2 Procedure: READ (6)]
    file
        [hash (CRC-32): 0xcdddf154]
        FileHandle: 010004010100540020bb3809040054002f2edde4000000000000000000000000
    Offset: 0
    Count: 1024
    Total Count: 0
```

From packet 12 V2 READ Reply

```
Remote Procedure Call, Type:Reply XID:0x000050e1
    XID: 0x000050e1 (20705)
    Message Type: Reply (1)
    [Program: NFS (100003)]
    [Program Version: 2]
    [Procedure: READ (6)]
    Reply State: accepted (0)
    [This is a reply to a request in frame 11]
    [Time from request: 94.000 microseconds]
    Verifier
        Flavor: AUTH_NULL (0)
        Length: 0
    Accept State: RPC executed successfully (0)
Network File System, READ Reply  Error: NFS2ERR_IO
    [Program Version: 2]
    [V2 Procedure: READ (6)]
    Status: NFS2ERR_IO (5)
```


I can locally revert this commit in our kernel, but is there any other way
to get it working again?


Thanks in advance.

Best regards Jörg

-- 
Optimisten haben gar keine Ahnung von den freudigen Überraschungen, die
Pessimisten erleben.
                                                (Peter Bramm)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[NeilBrown]

On Fri, 28 Aug 2026, Jörg Sommer wrote:
> Chuck Lever schrieb am Di 09. Dez, 19:28 (-0500):
> > From: Chuck Lever <chuck.lever@oracle.com>
> > 
> > A documenting comment in include/uapi/linux/nfs.h claims incorrectly
> > that NFSv2 defines NFSERR_INVAL. There is no such definition in either
> > RFC 1094 or https://pubs.opengroup.org/onlinepubs/9629799/chap7.htm
> > 
> > NFS3ERR_INVAL is introduced in RFC 1813.
> 
> Hello,
> 
> since this commit 0ac903d1bfdce8ff40657c2b7d996947b72b6645 was added, U-Boot
> 2022.04 (I don't know about newer versions) can no longer access symlinks in
> NFS shares. When I revert this commit, U-Boot can load the file behind the
> symlink. Real files are no problem.
> 
> The file I want to load is a symlink at the server:
> 
> ```
> % ls -l /srv/nfs/boot/Image.gz*
> lrwxrwxrwx 1 root root      41  7. Jul 16:29 /srv/nfs-con/boot/Image.gz -> Image.gz-5.15.213-imx8mm+gfffa4b6d4aea+p1
> -rw-r--r-- 1 root root 5279373  7. Jul 16:29 /srv/nfs-con/boot/Image.gz-5.15.213-imx8mm+gfffa4b6d4aea+p1
> ```
> 
> Without this commit:
> 
> ```
> u-boot=> nfs 0x42000000 /srv/nfs/boot/Image.gz
> Filename '/srv/nfs-con/boot/Image.gz'.
> Load address: 0x42000000
> Loading: #################################################################
> done
> Bytes transferred = 5279373 (508e8d hex)
> ```
> 
> But with this commit:
> 
> ```
> u-boot=> nfs 0x42000000 /srv/nfs/boot/Image.gz
> Filename '/srv/nfs-con/boot/Image.gz'.
> Load address: 0x42000000
> Loading:
> done
> ```
> 
> This is the network traffic:
> 
> ```
> No.	Time	Protocol	Length	Info
> 3	0.000370	Portmap	98	V2 GETPORT Call (Reply In 4) MOUNT(100005) V:1 UDP
> 4	0.000607	Portmap	70	V2 GETPORT Reply (Call In 3) Port:60340
> 5	0.000949	Portmap	98	V2 GETPORT Call (Reply In 6) NFS(100003) V:2 UDP
> 6	0.001046	Portmap	70	V2 GETPORT Reply (Call In 5) Port:2049
> 7	0.001368	MOUNT	126	V2 MNT Call (Reply In 8) /srv/nfs-con/boot
> 8	0.008026	MOUNT	102	V2 MNT Reply (Call In 7)
> 9	0.008389	NFS	146	V2 LOOKUP Call (Reply In 10), DH: 0x8c279135/Image.gz
> 10	0.008754	NFS	170	V2 LOOKUP Reply (Call In 9), FH: 0xcdddf154
> 11	0.009095	NFS	146	V2 READ Call (Reply In 12), FH: 0xcdddf154 Offset: 0 Count: 1024 TotalCount: 0
> 12	0.009189	NFS	70	V2 READ Reply (Call In 11) Error: NFS2ERR_IO
> 13	0.009511	MOUNT	102	V2 UMNTALL Call (Reply In 14)
> 14	0.010301	MOUNT	66	V2 UMNTALL Reply (Call In 13)
> ```
> 
> From packet 11 V2 READ Call
> 
> ```
> Remote Procedure Call, Type:Call XID:0x000050e1
>     XID: 0x000050e1 (20705)
>     Message Type: Call (0)
>     RPC Version: 2
>     Program: NFS (100003)
>     Program Version: 2
>     Procedure: READ (6)
>     [The reply to this request is in frame 12]
>     Credentials
>         Flavor: AUTH_UNIX (1)
>         Length: 20
>         Stamp: 0x00000000
>         Machine Name: <EMPTY>
>         UID: 0
>         GID: 0
>         Auxiliary GIDs (0)
>     Verifier
>         Flavor: AUTH_NULL (0)
>         Length: 0
> Network File System, READ Call FH: 0xcdddf154 Offset: 0 Count: 1024 TotalCount: 0
>     [Program Version: 2]
>     [V2 Procedure: READ (6)]
>     file
>         [hash (CRC-32): 0xcdddf154]
>         FileHandle: 010004010100540020bb3809040054002f2edde4000000000000000000000000
>     Offset: 0
>     Count: 1024
>     Total Count: 0
> ```
> 
> From packet 12 V2 READ Reply
> 
> ```
> Remote Procedure Call, Type:Reply XID:0x000050e1
>     XID: 0x000050e1 (20705)
>     Message Type: Reply (1)
>     [Program: NFS (100003)]
>     [Program Version: 2]
>     [Procedure: READ (6)]
>     Reply State: accepted (0)
>     [This is a reply to a request in frame 11]
>     [Time from request: 94.000 microseconds]
>     Verifier
>         Flavor: AUTH_NULL (0)
>         Length: 0
>     Accept State: RPC executed successfully (0)
> Network File System, READ Reply  Error: NFS2ERR_IO
>     [Program Version: 2]
>     [V2 Procedure: READ (6)]
>     Status: NFS2ERR_IO (5)
> ```
> 
> 
> I can locally revert this commit in our kernel, but is there any other way
> to get it working again?

This is unfortunate.
U-boot has

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

so we either need nfsdv2 to return NFSERR_ISDIR (for something that
isn't a directory) or NFSERR_INVAL (which is not a valid v2 error code),
or change u-boot to also check for NFSERR_IO (which is 5).

There is no "good" option.
I suspect we should revert this change and document that we violate the
RFC for historical compatibility with u-boot.

NeilBrown


> 
> 
> Thanks in advance.
> 
> Best regards Jörg
> 
> -- 
> Optimisten haben gar keine Ahnung von den freudigen Überraschungen, die
> Pessimisten erleben.
>                                                 (Peter Bramm)
> 

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

[Jörg Sommer]

[-- Attachment #1: Type: text/plain, Size: 5581 bytes --]

NeilBrown schrieb am Fr 28. Aug, 21:33 (+1000):
> On Fri, 28 Aug 2026, Jörg Sommer wrote:
> > Chuck Lever schrieb am Di 09. Dez, 19:28 (-0500):
> > > From: Chuck Lever <chuck.lever@oracle.com>
> > > 
> > > A documenting comment in include/uapi/linux/nfs.h claims incorrectly
> > > that NFSv2 defines NFSERR_INVAL. There is no such definition in either
> > > RFC 1094 or https://pubs.opengroup.org/onlinepubs/9629799/chap7.htm
> > > 
> > > NFS3ERR_INVAL is introduced in RFC 1813.
> > 
> > Hello,
> > 
> > since this commit 0ac903d1bfdce8ff40657c2b7d996947b72b6645 was added, U-Boot
> > 2022.04 (I don't know about newer versions) can no longer access symlinks in
> > NFS shares. When I revert this commit, U-Boot can load the file behind the
> > symlink. Real files are no problem.
> > 
> > The file I want to load is a symlink at the server:
> > 
> > ```
> > % ls -l /srv/nfs/boot/Image.gz*
> > lrwxrwxrwx 1 root root      41  7. Jul 16:29 /srv/nfs-con/boot/Image.gz -> Image.gz-5.15.213-imx8mm+gfffa4b6d4aea+p1
> > -rw-r--r-- 1 root root 5279373  7. Jul 16:29 /srv/nfs-con/boot/Image.gz-5.15.213-imx8mm+gfffa4b6d4aea+p1
> > ```
> > 
> > Without this commit:
> > 
> > ```
> > u-boot=> nfs 0x42000000 /srv/nfs/boot/Image.gz
> > Filename '/srv/nfs-con/boot/Image.gz'.
> > Load address: 0x42000000
> > Loading: #################################################################
> > done
> > Bytes transferred = 5279373 (508e8d hex)
> > ```
> > 
> > But with this commit:
> > 
> > ```
> > u-boot=> nfs 0x42000000 /srv/nfs/boot/Image.gz
> > Filename '/srv/nfs-con/boot/Image.gz'.
> > Load address: 0x42000000
> > Loading:
> > done
> > ```
> > 
> > This is the network traffic:
> > 
> > ```
> > No.	Time	Protocol	Length	Info
> > 3	0.000370	Portmap	98	V2 GETPORT Call (Reply In 4) MOUNT(100005) V:1 UDP
> > 4	0.000607	Portmap	70	V2 GETPORT Reply (Call In 3) Port:60340
> > 5	0.000949	Portmap	98	V2 GETPORT Call (Reply In 6) NFS(100003) V:2 UDP
> > 6	0.001046	Portmap	70	V2 GETPORT Reply (Call In 5) Port:2049
> > 7	0.001368	MOUNT	126	V2 MNT Call (Reply In 8) /srv/nfs-con/boot
> > 8	0.008026	MOUNT	102	V2 MNT Reply (Call In 7)
> > 9	0.008389	NFS	146	V2 LOOKUP Call (Reply In 10), DH: 0x8c279135/Image.gz
> > 10	0.008754	NFS	170	V2 LOOKUP Reply (Call In 9), FH: 0xcdddf154
> > 11	0.009095	NFS	146	V2 READ Call (Reply In 12), FH: 0xcdddf154 Offset: 0 Count: 1024 TotalCount: 0
> > 12	0.009189	NFS	70	V2 READ Reply (Call In 11) Error: NFS2ERR_IO
> > 13	0.009511	MOUNT	102	V2 UMNTALL Call (Reply In 14)
> > 14	0.010301	MOUNT	66	V2 UMNTALL Reply (Call In 13)
> > ```
> > 
> > From packet 11 V2 READ Call
> > 
> > ```
> > Remote Procedure Call, Type:Call XID:0x000050e1
> >     XID: 0x000050e1 (20705)
> >     Message Type: Call (0)
> >     RPC Version: 2
> >     Program: NFS (100003)
> >     Program Version: 2
> >     Procedure: READ (6)
> >     [The reply to this request is in frame 12]
> >     Credentials
> >         Flavor: AUTH_UNIX (1)
> >         Length: 20
> >         Stamp: 0x00000000
> >         Machine Name: <EMPTY>
> >         UID: 0
> >         GID: 0
> >         Auxiliary GIDs (0)
> >     Verifier
> >         Flavor: AUTH_NULL (0)
> >         Length: 0
> > Network File System, READ Call FH: 0xcdddf154 Offset: 0 Count: 1024 TotalCount: 0
> >     [Program Version: 2]
> >     [V2 Procedure: READ (6)]
> >     file
> >         [hash (CRC-32): 0xcdddf154]
> >         FileHandle: 010004010100540020bb3809040054002f2edde4000000000000000000000000
> >     Offset: 0
> >     Count: 1024
> >     Total Count: 0
> > ```
> > 
> > From packet 12 V2 READ Reply
> > 
> > ```
> > Remote Procedure Call, Type:Reply XID:0x000050e1
> >     XID: 0x000050e1 (20705)
> >     Message Type: Reply (1)
> >     [Program: NFS (100003)]
> >     [Program Version: 2]
> >     [Procedure: READ (6)]
> >     Reply State: accepted (0)
> >     [This is a reply to a request in frame 11]
> >     [Time from request: 94.000 microseconds]
> >     Verifier
> >         Flavor: AUTH_NULL (0)
> >         Length: 0
> >     Accept State: RPC executed successfully (0)
> > Network File System, READ Reply  Error: NFS2ERR_IO
> >     [Program Version: 2]
> >     [V2 Procedure: READ (6)]
> >     Status: NFS2ERR_IO (5)
> > ```
> > 
> > 
> > I can locally revert this commit in our kernel, but is there any other way
> > to get it working again?
> 
> This is unfortunate.
> U-boot has
> 
> 		} else if ((rlen == -NFSERR_ISDIR) || (rlen == -NFSERR_INVAL)) {
> 			/* symbolic link */
> 			nfs_state = STATE_READLINK_REQ;
> 			nfs_send();
> 
> so we either need nfsdv2 to return NFSERR_ISDIR (for something that
> isn't a directory) or NFSERR_INVAL (which is not a valid v2 error code),
> or change u-boot to also check for NFSERR_IO (which is 5).
> 
> There is no "good" option.
> I suspect we should revert this change and document that we violate the
> RFC for historical compatibility with u-boot.

Maybe not revert the whole change, but add an exception for symlinks.

+++ fs/nfsd/nfsproc.c
@@ -33,7 +33,7 @@ static __be32 nfsd_map_status(__be32 status)
           break;
   case nfserr_symlink:
+          /* this is invalid, but U-Boot ... */
+          status = nfserr_inval;
+          break;

   case nfserr_wrong_type:
-          status = nfserr_inval;
+          status = nfserr_io;


-- 
Es liegt in der Natur des Menschen, vernünftig zu denken und
unlogisch zu handeln! Das Gesagte ist nicht das Gemeinte und das Gehörte
nicht das Verstandene!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Chuck Lever]

On Fri, Aug 28, 2026, at 7:33 AM, NeilBrown wrote:
> On Fri, 28 Aug 2026, Jörg Sommer wrote:
>> Chuck Lever schrieb am Di 09. Dez, 19:28 (-0500):
>> > From: Chuck Lever <chuck.lever@oracle.com>
>> > 
>> > A documenting comment in include/uapi/linux/nfs.h claims incorrectly
>> > that NFSv2 defines NFSERR_INVAL. There is no such definition in either
>> > RFC 1094 or https://pubs.opengroup.org/onlinepubs/9629799/chap7.htm
>> > 
>> > NFS3ERR_INVAL is introduced in RFC 1813.
>> 
>> Hello,
>> 
>> since this commit 0ac903d1bfdce8ff40657c2b7d996947b72b6645 was added, U-Boot
>> 2022.04 (I don't know about newer versions) can no longer access symlinks in
>> NFS shares. When I revert this commit, U-Boot can load the file behind the
>> symlink. Real files are no problem.
>> 
>> The file I want to load is a symlink at the server:
>> 
>> ```
>> % ls -l /srv/nfs/boot/Image.gz*
>> lrwxrwxrwx 1 root root      41  7. Jul 16:29 /srv/nfs-con/boot/Image.gz -> Image.gz-5.15.213-imx8mm+gfffa4b6d4aea+p1
>> -rw-r--r-- 1 root root 5279373  7. Jul 16:29 /srv/nfs-con/boot/Image.gz-5.15.213-imx8mm+gfffa4b6d4aea+p1
>> ```
>> 
>> Without this commit:
>> 
>> ```
>> u-boot=> nfs 0x42000000 /srv/nfs/boot/Image.gz
>> Filename '/srv/nfs-con/boot/Image.gz'.
>> Load address: 0x42000000
>> Loading: #################################################################
>> done
>> Bytes transferred = 5279373 (508e8d hex)
>> ```
>> 
>> But with this commit:
>> 
>> ```
>> u-boot=> nfs 0x42000000 /srv/nfs/boot/Image.gz
>> Filename '/srv/nfs-con/boot/Image.gz'.
>> Load address: 0x42000000
>> Loading:
>> done
>> ```
>> 
>> This is the network traffic:
>> 
>> ```
>> No.	Time	Protocol	Length	Info
>> 3	0.000370	Portmap	98	V2 GETPORT Call (Reply In 4) MOUNT(100005) V:1 UDP
>> 4	0.000607	Portmap	70	V2 GETPORT Reply (Call In 3) Port:60340
>> 5	0.000949	Portmap	98	V2 GETPORT Call (Reply In 6) NFS(100003) V:2 UDP
>> 6	0.001046	Portmap	70	V2 GETPORT Reply (Call In 5) Port:2049
>> 7	0.001368	MOUNT	126	V2 MNT Call (Reply In 8) /srv/nfs-con/boot
>> 8	0.008026	MOUNT	102	V2 MNT Reply (Call In 7)
>> 9	0.008389	NFS	146	V2 LOOKUP Call (Reply In 10), DH: 0x8c279135/Image.gz
>> 10	0.008754	NFS	170	V2 LOOKUP Reply (Call In 9), FH: 0xcdddf154
>> 11	0.009095	NFS	146	V2 READ Call (Reply In 12), FH: 0xcdddf154 Offset: 0 Count: 1024 TotalCount: 0
>> 12	0.009189	NFS	70	V2 READ Reply (Call In 11) Error: NFS2ERR_IO
>> 13	0.009511	MOUNT	102	V2 UMNTALL Call (Reply In 14)
>> 14	0.010301	MOUNT	66	V2 UMNTALL Reply (Call In 13)
>> ```
>> 
>> From packet 11 V2 READ Call
>> 
>> ```
>> Remote Procedure Call, Type:Call XID:0x000050e1
>>     XID: 0x000050e1 (20705)
>>     Message Type: Call (0)
>>     RPC Version: 2
>>     Program: NFS (100003)
>>     Program Version: 2
>>     Procedure: READ (6)
>>     [The reply to this request is in frame 12]
>>     Credentials
>>         Flavor: AUTH_UNIX (1)
>>         Length: 20
>>         Stamp: 0x00000000
>>         Machine Name: <EMPTY>
>>         UID: 0
>>         GID: 0
>>         Auxiliary GIDs (0)
>>     Verifier
>>         Flavor: AUTH_NULL (0)
>>         Length: 0
>> Network File System, READ Call FH: 0xcdddf154 Offset: 0 Count: 1024 TotalCount: 0
>>     [Program Version: 2]
>>     [V2 Procedure: READ (6)]
>>     file
>>         [hash (CRC-32): 0xcdddf154]
>>         FileHandle: 010004010100540020bb3809040054002f2edde4000000000000000000000000
>>     Offset: 0
>>     Count: 1024
>>     Total Count: 0
>> ```
>> 
>> From packet 12 V2 READ Reply
>> 
>> ```
>> Remote Procedure Call, Type:Reply XID:0x000050e1
>>     XID: 0x000050e1 (20705)
>>     Message Type: Reply (1)
>>     [Program: NFS (100003)]
>>     [Program Version: 2]
>>     [Procedure: READ (6)]
>>     Reply State: accepted (0)
>>     [This is a reply to a request in frame 11]
>>     [Time from request: 94.000 microseconds]
>>     Verifier
>>         Flavor: AUTH_NULL (0)
>>         Length: 0
>>     Accept State: RPC executed successfully (0)
>> Network File System, READ Reply  Error: NFS2ERR_IO
>>     [Program Version: 2]
>>     [V2 Procedure: READ (6)]
>>     Status: NFS2ERR_IO (5)
>> ```
>> 
>> 
>> I can locally revert this commit in our kernel, but is there any other way
>> to get it working again?
>
> This is unfortunate.
> U-boot has
>
> 		} else if ((rlen == -NFSERR_ISDIR) || (rlen == -NFSERR_INVAL)) {
> 			/* symbolic link */
> 			nfs_state = STATE_READLINK_REQ;
> 			nfs_send();
>
> so we either need nfsdv2 to return NFSERR_ISDIR (for something that
> isn't a directory) or NFSERR_INVAL (which is not a valid v2 error code),
> or change u-boot to also check for NFSERR_IO (which is 5).

U-Boot's NFSERR_ISDIR check (quoted above) is the Sun-compatible
path. The NFSERR_INVAL arm was presumably added for Linux NFSD?

So the pre-0ac903d1bfdc code is not something I want to go back to.
Returning NFSERR_INVAL is incompatible with the reference NFSv2
implementation, and so is NFSERR_IO.

Mapping nfserr_symlink to NFSERR_ISDIR affects the READ, WRITE, and
SETATTR procedures. The Solaris NFS server returns NFSERR_ISDIR for
READ and WRITE of a non-REG object, which suggests to me that is
the behavior clients will expect.

IMO we should leave nfserr_wrong_type alone until we have a specific
real-world complaint to address.


-- 
Chuck Lever

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

[Tom Rini]

On Fri, Aug 28, 2026 at 09:27:41AM -0400, Chuck Lever wrote:
> 
> 
> On Fri, Aug 28, 2026, at 7:33 AM, NeilBrown wrote:
> > On Fri, 28 Aug 2026, Jörg Sommer wrote:
> >> Chuck Lever schrieb am Di 09. Dez, 19:28 (-0500):
> >> > From: Chuck Lever <chuck.lever@oracle.com>
> >> > 
> >> > A documenting comment in include/uapi/linux/nfs.h claims incorrectly
> >> > that NFSv2 defines NFSERR_INVAL. There is no such definition in either
> >> > RFC 1094 or https://pubs.opengroup.org/onlinepubs/9629799/chap7.htm
> >> > 
> >> > NFS3ERR_INVAL is introduced in RFC 1813.
> >> 
> >> Hello,
> >> 
> >> since this commit 0ac903d1bfdce8ff40657c2b7d996947b72b6645 was added, U-Boot
> >> 2022.04 (I don't know about newer versions) can no longer access symlinks in
> >> NFS shares. When I revert this commit, U-Boot can load the file behind the
> >> symlink. Real files are no problem.
> >> 
> >> The file I want to load is a symlink at the server:
> >> 
> >> ```
> >> % ls -l /srv/nfs/boot/Image.gz*
> >> lrwxrwxrwx 1 root root      41  7. Jul 16:29 /srv/nfs-con/boot/Image.gz -> Image.gz-5.15.213-imx8mm+gfffa4b6d4aea+p1
> >> -rw-r--r-- 1 root root 5279373  7. Jul 16:29 /srv/nfs-con/boot/Image.gz-5.15.213-imx8mm+gfffa4b6d4aea+p1
> >> ```
> >> 
> >> Without this commit:
> >> 
> >> ```
> >> u-boot=> nfs 0x42000000 /srv/nfs/boot/Image.gz
> >> Filename '/srv/nfs-con/boot/Image.gz'.
> >> Load address: 0x42000000
> >> Loading: #################################################################
> >> done
> >> Bytes transferred = 5279373 (508e8d hex)
> >> ```
> >> 
> >> But with this commit:
> >> 
> >> ```
> >> u-boot=> nfs 0x42000000 /srv/nfs/boot/Image.gz
> >> Filename '/srv/nfs-con/boot/Image.gz'.
> >> Load address: 0x42000000
> >> Loading:
> >> done
> >> ```
> >> 
> >> This is the network traffic:
> >> 
> >> ```
> >> No.	Time	Protocol	Length	Info
> >> 3	0.000370	Portmap	98	V2 GETPORT Call (Reply In 4) MOUNT(100005) V:1 UDP
> >> 4	0.000607	Portmap	70	V2 GETPORT Reply (Call In 3) Port:60340
> >> 5	0.000949	Portmap	98	V2 GETPORT Call (Reply In 6) NFS(100003) V:2 UDP
> >> 6	0.001046	Portmap	70	V2 GETPORT Reply (Call In 5) Port:2049
> >> 7	0.001368	MOUNT	126	V2 MNT Call (Reply In 8) /srv/nfs-con/boot
> >> 8	0.008026	MOUNT	102	V2 MNT Reply (Call In 7)
> >> 9	0.008389	NFS	146	V2 LOOKUP Call (Reply In 10), DH: 0x8c279135/Image.gz
> >> 10	0.008754	NFS	170	V2 LOOKUP Reply (Call In 9), FH: 0xcdddf154
> >> 11	0.009095	NFS	146	V2 READ Call (Reply In 12), FH: 0xcdddf154 Offset: 0 Count: 1024 TotalCount: 0
> >> 12	0.009189	NFS	70	V2 READ Reply (Call In 11) Error: NFS2ERR_IO
> >> 13	0.009511	MOUNT	102	V2 UMNTALL Call (Reply In 14)
> >> 14	0.010301	MOUNT	66	V2 UMNTALL Reply (Call In 13)
> >> ```
> >> 
> >> From packet 11 V2 READ Call
> >> 
> >> ```
> >> Remote Procedure Call, Type:Call XID:0x000050e1
> >>     XID: 0x000050e1 (20705)
> >>     Message Type: Call (0)
> >>     RPC Version: 2
> >>     Program: NFS (100003)
> >>     Program Version: 2
> >>     Procedure: READ (6)
> >>     [The reply to this request is in frame 12]
> >>     Credentials
> >>         Flavor: AUTH_UNIX (1)
> >>         Length: 20
> >>         Stamp: 0x00000000
> >>         Machine Name: <EMPTY>
> >>         UID: 0
> >>         GID: 0
> >>         Auxiliary GIDs (0)
> >>     Verifier
> >>         Flavor: AUTH_NULL (0)
> >>         Length: 0
> >> Network File System, READ Call FH: 0xcdddf154 Offset: 0 Count: 1024 TotalCount: 0
> >>     [Program Version: 2]
> >>     [V2 Procedure: READ (6)]
> >>     file
> >>         [hash (CRC-32): 0xcdddf154]
> >>         FileHandle: 010004010100540020bb3809040054002f2edde4000000000000000000000000
> >>     Offset: 0
> >>     Count: 1024
> >>     Total Count: 0
> >> ```
> >> 
> >> From packet 12 V2 READ Reply
> >> 
> >> ```
> >> Remote Procedure Call, Type:Reply XID:0x000050e1
> >>     XID: 0x000050e1 (20705)
> >>     Message Type: Reply (1)
> >>     [Program: NFS (100003)]
> >>     [Program Version: 2]
> >>     [Procedure: READ (6)]
> >>     Reply State: accepted (0)
> >>     [This is a reply to a request in frame 11]
> >>     [Time from request: 94.000 microseconds]
> >>     Verifier
> >>         Flavor: AUTH_NULL (0)
> >>         Length: 0
> >>     Accept State: RPC executed successfully (0)
> >> Network File System, READ Reply  Error: NFS2ERR_IO
> >>     [Program Version: 2]
> >>     [V2 Procedure: READ (6)]
> >>     Status: NFS2ERR_IO (5)
> >> ```
> >> 
> >> 
> >> I can locally revert this commit in our kernel, but is there any other way
> >> to get it working again?
> >
> > This is unfortunate.
> > U-boot has
> >
> > 		} else if ((rlen == -NFSERR_ISDIR) || (rlen == -NFSERR_INVAL)) {
> > 			/* symbolic link */
> > 			nfs_state = STATE_READLINK_REQ;
> > 			nfs_send();
> >
> > so we either need nfsdv2 to return NFSERR_ISDIR (for something that
> > isn't a directory) or NFSERR_INVAL (which is not a valid v2 error code),
> > or change u-boot to also check for NFSERR_IO (which is 5).
> 
> U-Boot's NFSERR_ISDIR check (quoted above) is the Sun-compatible
> path. The NFSERR_INVAL arm was presumably added for Linux NFSD?
> 
> So the pre-0ac903d1bfdc code is not something I want to go back to.
> Returning NFSERR_INVAL is incompatible with the reference NFSv2
> implementation, and so is NFSERR_IO.
> 
> Mapping nfserr_symlink to NFSERR_ISDIR affects the READ, WRITE, and
> SETATTR procedures. The Solaris NFS server returns NFSERR_ISDIR for
> READ and WRITE of a non-REG object, which suggests to me that is
> the behavior clients will expect.
> 
> IMO we should leave nfserr_wrong_type alone until we have a specific
> real-world complaint to address.

On the U-Boot side of things, the code in question dates back to when
NFS support was originally added in 2004. The history here says that
someone added the symlink support on top of what was borrowed from
NetBSD, so yes, we're likely the originator of the incorrect behavior.
But also, this means that everything U-Boot that's ever been using this
feature now fails. And given the lag between the kernel change and the
bug report, it's not something that's in rapidly changing areas and
probably also in deployments that can't be updated. So perhaps things do
need to go back to the way it was.

-- 
Tom

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

[Chuck Lever]

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:
>> > On Fri, 28 Aug 2026, Jörg Sommer wrote:
>> >> Chuck Lever schrieb am Di 09. Dez, 19:28 (-0500):
>> >> > From: Chuck Lever <chuck.lever@oracle.com>
>> >> > 
>> >> > A documenting comment in include/uapi/linux/nfs.h claims incorrectly
>> >> > that NFSv2 defines NFSERR_INVAL. There is no such definition in either
>> >> > RFC 1094 or https://pubs.opengroup.org/onlinepubs/9629799/chap7.htm
>> >> > 
>> >> > NFS3ERR_INVAL is introduced in RFC 1813.
>> >> 
>> >> Hello,
>> >> 
>> >> since this commit 0ac903d1bfdce8ff40657c2b7d996947b72b6645 was added, U-Boot
>> >> 2022.04 (I don't know about newer versions) can no longer access symlinks in
>> >> NFS shares. When I revert this commit, U-Boot can load the file behind the
>> >> symlink. Real files are no problem.
>> >> 
>> >> The file I want to load is a symlink at the server:
>> >> 
>> >> ```
>> >> % ls -l /srv/nfs/boot/Image.gz*
>> >> lrwxrwxrwx 1 root root      41  7. Jul 16:29 /srv/nfs-con/boot/Image.gz -> Image.gz-5.15.213-imx8mm+gfffa4b6d4aea+p1
>> >> -rw-r--r-- 1 root root 5279373  7. Jul 16:29 /srv/nfs-con/boot/Image.gz-5.15.213-imx8mm+gfffa4b6d4aea+p1
>> >> ```
>> >> 
>> >> Without this commit:
>> >> 
>> >> ```
>> >> u-boot=> nfs 0x42000000 /srv/nfs/boot/Image.gz
>> >> Filename '/srv/nfs-con/boot/Image.gz'.
>> >> Load address: 0x42000000
>> >> Loading: #################################################################
>> >> done
>> >> Bytes transferred = 5279373 (508e8d hex)
>> >> ```
>> >> 
>> >> But with this commit:
>> >> 
>> >> ```
>> >> u-boot=> nfs 0x42000000 /srv/nfs/boot/Image.gz
>> >> Filename '/srv/nfs-con/boot/Image.gz'.
>> >> Load address: 0x42000000
>> >> Loading:
>> >> done
>> >> ```
>> >> 
>> >> This is the network traffic:
>> >> 
>> >> ```
>> >> No.	Time	Protocol	Length	Info
>> >> 3	0.000370	Portmap	98	V2 GETPORT Call (Reply In 4) MOUNT(100005) V:1 UDP
>> >> 4	0.000607	Portmap	70	V2 GETPORT Reply (Call In 3) Port:60340
>> >> 5	0.000949	Portmap	98	V2 GETPORT Call (Reply In 6) NFS(100003) V:2 UDP
>> >> 6	0.001046	Portmap	70	V2 GETPORT Reply (Call In 5) Port:2049
>> >> 7	0.001368	MOUNT	126	V2 MNT Call (Reply In 8) /srv/nfs-con/boot
>> >> 8	0.008026	MOUNT	102	V2 MNT Reply (Call In 7)
>> >> 9	0.008389	NFS	146	V2 LOOKUP Call (Reply In 10), DH: 0x8c279135/Image.gz
>> >> 10	0.008754	NFS	170	V2 LOOKUP Reply (Call In 9), FH: 0xcdddf154
>> >> 11	0.009095	NFS	146	V2 READ Call (Reply In 12), FH: 0xcdddf154 Offset: 0 Count: 1024 TotalCount: 0
>> >> 12	0.009189	NFS	70	V2 READ Reply (Call In 11) Error: NFS2ERR_IO
>> >> 13	0.009511	MOUNT	102	V2 UMNTALL Call (Reply In 14)
>> >> 14	0.010301	MOUNT	66	V2 UMNTALL Reply (Call In 13)
>> >> ```
>> >> 
>> >> From packet 11 V2 READ Call
>> >> 
>> >> ```
>> >> Remote Procedure Call, Type:Call XID:0x000050e1
>> >>     XID: 0x000050e1 (20705)
>> >>     Message Type: Call (0)
>> >>     RPC Version: 2
>> >>     Program: NFS (100003)
>> >>     Program Version: 2
>> >>     Procedure: READ (6)
>> >>     [The reply to this request is in frame 12]
>> >>     Credentials
>> >>         Flavor: AUTH_UNIX (1)
>> >>         Length: 20
>> >>         Stamp: 0x00000000
>> >>         Machine Name: <EMPTY>
>> >>         UID: 0
>> >>         GID: 0
>> >>         Auxiliary GIDs (0)
>> >>     Verifier
>> >>         Flavor: AUTH_NULL (0)
>> >>         Length: 0
>> >> Network File System, READ Call FH: 0xcdddf154 Offset: 0 Count: 1024 TotalCount: 0
>> >>     [Program Version: 2]
>> >>     [V2 Procedure: READ (6)]
>> >>     file
>> >>         [hash (CRC-32): 0xcdddf154]
>> >>         FileHandle: 010004010100540020bb3809040054002f2edde4000000000000000000000000
>> >>     Offset: 0
>> >>     Count: 1024
>> >>     Total Count: 0
>> >> ```
>> >> 
>> >> From packet 12 V2 READ Reply
>> >> 
>> >> ```
>> >> Remote Procedure Call, Type:Reply XID:0x000050e1
>> >>     XID: 0x000050e1 (20705)
>> >>     Message Type: Reply (1)
>> >>     [Program: NFS (100003)]
>> >>     [Program Version: 2]
>> >>     [Procedure: READ (6)]
>> >>     Reply State: accepted (0)
>> >>     [This is a reply to a request in frame 11]
>> >>     [Time from request: 94.000 microseconds]
>> >>     Verifier
>> >>         Flavor: AUTH_NULL (0)
>> >>         Length: 0
>> >>     Accept State: RPC executed successfully (0)
>> >> Network File System, READ Reply  Error: NFS2ERR_IO
>> >>     [Program Version: 2]
>> >>     [V2 Procedure: READ (6)]
>> >>     Status: NFS2ERR_IO (5)
>> >> ```
>> >> 
>> >> 
>> >> I can locally revert this commit in our kernel, but is there any other way
>> >> to get it working again?
>> >
>> > This is unfortunate.
>> > U-boot has
>> >
>> > 		} else if ((rlen == -NFSERR_ISDIR) || (rlen == -NFSERR_INVAL)) {
>> > 			/* symbolic link */
>> > 			nfs_state = STATE_READLINK_REQ;
>> > 			nfs_send();
>> >
>> > so we either need nfsdv2 to return NFSERR_ISDIR (for something that
>> > isn't a directory) or NFSERR_INVAL (which is not a valid v2 error code),
>> > or change u-boot to also check for NFSERR_IO (which is 5).
>> 
>> U-Boot's NFSERR_ISDIR check (quoted above) is the Sun-compatible
>> path. The NFSERR_INVAL arm was presumably added for Linux NFSD?
>> 
>> So the pre-0ac903d1bfdc code is not something I want to go back to.
>> Returning NFSERR_INVAL is incompatible with the reference NFSv2
>> implementation, and so is NFSERR_IO.
>> 
>> Mapping nfserr_symlink to NFSERR_ISDIR affects the READ, WRITE, and
>> SETATTR procedures. The Solaris NFS server returns NFSERR_ISDIR for
>> READ and WRITE of a non-REG object, which suggests to me that is
>> the behavior clients will expect.
>> 
>> IMO we should leave nfserr_wrong_type alone until we have a specific
>> real-world complaint to address.
>
> On the U-Boot side of things, the code in question dates back to when
> NFS support was originally added in 2004. The history here says that
> someone added the symlink support on top of what was borrowed from
> NetBSD, so yes, we're likely the originator of the incorrect behavior.
> But also, this means that everything U-Boot that's ever been using this
> feature now fails. And given the lag between the kernel change and the
> bug report, it's not something that's in rapidly changing areas and
> probably also in deployments that can't be updated. So perhaps things do
> need to go back to the way it was.

That argument doesn't make sense to me, and moves NFSD backwards
instead of forward.

Reverting the commit is fine for stable kernels, but getting the
revert into mainline will take just as long as fixing it correctly.

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.

I'm not convinced.


-- 
Chuck Lever

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

[Tom Rini]

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:
> >> > On Fri, 28 Aug 2026, Jörg Sommer wrote:
> >> >> Chuck Lever schrieb am Di 09. Dez, 19:28 (-0500):
> >> >> > From: Chuck Lever <chuck.lever@oracle.com>
> >> >> > 
> >> >> > A documenting comment in include/uapi/linux/nfs.h claims incorrectly
> >> >> > that NFSv2 defines NFSERR_INVAL. There is no such definition in either
> >> >> > RFC 1094 or https://pubs.opengroup.org/onlinepubs/9629799/chap7.htm
> >> >> > 
> >> >> > NFS3ERR_INVAL is introduced in RFC 1813.
> >> >> 
> >> >> Hello,
> >> >> 
> >> >> since this commit 0ac903d1bfdce8ff40657c2b7d996947b72b6645 was added, U-Boot
> >> >> 2022.04 (I don't know about newer versions) can no longer access symlinks in
> >> >> NFS shares. When I revert this commit, U-Boot can load the file behind the
> >> >> symlink. Real files are no problem.
> >> >> 
> >> >> The file I want to load is a symlink at the server:
> >> >> 
> >> >> ```
> >> >> % ls -l /srv/nfs/boot/Image.gz*
> >> >> lrwxrwxrwx 1 root root      41  7. Jul 16:29 /srv/nfs-con/boot/Image.gz -> Image.gz-5.15.213-imx8mm+gfffa4b6d4aea+p1
> >> >> -rw-r--r-- 1 root root 5279373  7. Jul 16:29 /srv/nfs-con/boot/Image.gz-5.15.213-imx8mm+gfffa4b6d4aea+p1
> >> >> ```
> >> >> 
> >> >> Without this commit:
> >> >> 
> >> >> ```
> >> >> u-boot=> nfs 0x42000000 /srv/nfs/boot/Image.gz
> >> >> Filename '/srv/nfs-con/boot/Image.gz'.
> >> >> Load address: 0x42000000
> >> >> Loading: #################################################################
> >> >> done
> >> >> Bytes transferred = 5279373 (508e8d hex)
> >> >> ```
> >> >> 
> >> >> But with this commit:
> >> >> 
> >> >> ```
> >> >> u-boot=> nfs 0x42000000 /srv/nfs/boot/Image.gz
> >> >> Filename '/srv/nfs-con/boot/Image.gz'.
> >> >> Load address: 0x42000000
> >> >> Loading:
> >> >> done
> >> >> ```
> >> >> 
> >> >> This is the network traffic:
> >> >> 
> >> >> ```
> >> >> No.	Time	Protocol	Length	Info
> >> >> 3	0.000370	Portmap	98	V2 GETPORT Call (Reply In 4) MOUNT(100005) V:1 UDP
> >> >> 4	0.000607	Portmap	70	V2 GETPORT Reply (Call In 3) Port:60340
> >> >> 5	0.000949	Portmap	98	V2 GETPORT Call (Reply In 6) NFS(100003) V:2 UDP
> >> >> 6	0.001046	Portmap	70	V2 GETPORT Reply (Call In 5) Port:2049
> >> >> 7	0.001368	MOUNT	126	V2 MNT Call (Reply In 8) /srv/nfs-con/boot
> >> >> 8	0.008026	MOUNT	102	V2 MNT Reply (Call In 7)
> >> >> 9	0.008389	NFS	146	V2 LOOKUP Call (Reply In 10), DH: 0x8c279135/Image.gz
> >> >> 10	0.008754	NFS	170	V2 LOOKUP Reply (Call In 9), FH: 0xcdddf154
> >> >> 11	0.009095	NFS	146	V2 READ Call (Reply In 12), FH: 0xcdddf154 Offset: 0 Count: 1024 TotalCount: 0
> >> >> 12	0.009189	NFS	70	V2 READ Reply (Call In 11) Error: NFS2ERR_IO
> >> >> 13	0.009511	MOUNT	102	V2 UMNTALL Call (Reply In 14)
> >> >> 14	0.010301	MOUNT	66	V2 UMNTALL Reply (Call In 13)
> >> >> ```
> >> >> 
> >> >> From packet 11 V2 READ Call
> >> >> 
> >> >> ```
> >> >> Remote Procedure Call, Type:Call XID:0x000050e1
> >> >>     XID: 0x000050e1 (20705)
> >> >>     Message Type: Call (0)
> >> >>     RPC Version: 2
> >> >>     Program: NFS (100003)
> >> >>     Program Version: 2
> >> >>     Procedure: READ (6)
> >> >>     [The reply to this request is in frame 12]
> >> >>     Credentials
> >> >>         Flavor: AUTH_UNIX (1)
> >> >>         Length: 20
> >> >>         Stamp: 0x00000000
> >> >>         Machine Name: <EMPTY>
> >> >>         UID: 0
> >> >>         GID: 0
> >> >>         Auxiliary GIDs (0)
> >> >>     Verifier
> >> >>         Flavor: AUTH_NULL (0)
> >> >>         Length: 0
> >> >> Network File System, READ Call FH: 0xcdddf154 Offset: 0 Count: 1024 TotalCount: 0
> >> >>     [Program Version: 2]
> >> >>     [V2 Procedure: READ (6)]
> >> >>     file
> >> >>         [hash (CRC-32): 0xcdddf154]
> >> >>         FileHandle: 010004010100540020bb3809040054002f2edde4000000000000000000000000
> >> >>     Offset: 0
> >> >>     Count: 1024
> >> >>     Total Count: 0
> >> >> ```
> >> >> 
> >> >> From packet 12 V2 READ Reply
> >> >> 
> >> >> ```
> >> >> Remote Procedure Call, Type:Reply XID:0x000050e1
> >> >>     XID: 0x000050e1 (20705)
> >> >>     Message Type: Reply (1)
> >> >>     [Program: NFS (100003)]
> >> >>     [Program Version: 2]
> >> >>     [Procedure: READ (6)]
> >> >>     Reply State: accepted (0)
> >> >>     [This is a reply to a request in frame 11]
> >> >>     [Time from request: 94.000 microseconds]
> >> >>     Verifier
> >> >>         Flavor: AUTH_NULL (0)
> >> >>         Length: 0
> >> >>     Accept State: RPC executed successfully (0)
> >> >> Network File System, READ Reply  Error: NFS2ERR_IO
> >> >>     [Program Version: 2]
> >> >>     [V2 Procedure: READ (6)]
> >> >>     Status: NFS2ERR_IO (5)
> >> >> ```
> >> >> 
> >> >> 
> >> >> I can locally revert this commit in our kernel, but is there any other way
> >> >> to get it working again?
> >> >
> >> > This is unfortunate.
> >> > U-boot has
> >> >
> >> > 		} else if ((rlen == -NFSERR_ISDIR) || (rlen == -NFSERR_INVAL)) {
> >> > 			/* symbolic link */
> >> > 			nfs_state = STATE_READLINK_REQ;
> >> > 			nfs_send();
> >> >
> >> > so we either need nfsdv2 to return NFSERR_ISDIR (for something that
> >> > isn't a directory) or NFSERR_INVAL (which is not a valid v2 error code),
> >> > or change u-boot to also check for NFSERR_IO (which is 5).
> >> 
> >> U-Boot's NFSERR_ISDIR check (quoted above) is the Sun-compatible
> >> path. The NFSERR_INVAL arm was presumably added for Linux NFSD?
> >> 
> >> So the pre-0ac903d1bfdc code is not something I want to go back to.
> >> Returning NFSERR_INVAL is incompatible with the reference NFSv2
> >> implementation, and so is NFSERR_IO.
> >> 
> >> Mapping nfserr_symlink to NFSERR_ISDIR affects the READ, WRITE, and
> >> SETATTR procedures. The Solaris NFS server returns NFSERR_ISDIR for
> >> READ and WRITE of a non-REG object, which suggests to me that is
> >> the behavior clients will expect.
> >> 
> >> IMO we should leave nfserr_wrong_type alone until we have a specific
> >> real-world complaint to address.
> >
> > On the U-Boot side of things, the code in question dates back to when
> > NFS support was originally added in 2004. The history here says that
> > someone added the symlink support on top of what was borrowed from
> > NetBSD, so yes, we're likely the originator of the incorrect behavior.
> > But also, this means that everything U-Boot that's ever been using this
> > feature now fails. And given the lag between the kernel change and the
> > bug report, it's not something that's in rapidly changing areas and
> > probably also in deployments that can't be updated. So perhaps things do
> > need to go back to the way it was.
> 
> That argument doesn't make sense to me, and moves NFSD backwards
> instead of forward.

I don't quite follow. The series here talks about correctness changes
that were found by comparison with the relevant documentation and not
about behavior with production / deployed systems. And it's not about
something new, it's about v2 support. On the U-Boot side I was ready to
drop it, except it turns out there's people still actively using it
today.

But also, doesn't this fall under the "you can't break ABI" side of
things? Especially since people have been using it for decades and
there's (seemingly) not some sort of security implication to the fix
(and we're talking about NFSv2, so...).

> Reverting the commit is fine for stable kernels, but getting the
> revert into mainline will take just as long as fixing it correctly.

I disagree about the speed of fixing it (being U-Boot) correctly. I have
a fix from Jörg today, and it could be in our October release, yes. When
will that actually be seen by people using U-Boot? Well, maybe newer
products based on... Fedora will pick up v2027.04, some semis will base
on v2027.01, but most places? Probably never.

> 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.

-- 
Tom

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

[Chuck Lever]

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.

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

[Tom Rini]

On Fri, Aug 28, 2026 at 06:04:39PM -0400, Chuck Lever wrote:
> 
> 
> 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.

Ah, thanks for explaining more, I hadn't quite followed. Yes, something
that doesn't require changing U-Boot is good, thanks.

-- 
Tom

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

[NeilBrown]

On Sat, 29 Aug 2026, Chuck Lever wrote:
> 
> 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.

Good idea.
That matches what OpenSolaris does, which is the closest thing to a real
standard for NFSv2.

https://web.archive.org/web/20090216190827/http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/nfs/nfs_srv.c

lines 619-624.

Thanks,
NeilBrown


> 
> 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.
> 

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

[Chuck Lever]

On Fri, Aug 28, 2026, at 6:36 PM, NeilBrown wrote:
> On Sat, 29 Aug 2026, Chuck Lever wrote:

>> 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.
>
> Good idea.
> That matches what OpenSolaris does, which is the closest thing to a real
> standard for NFSv2.
>
> https://web.archive.org/web/20090216190827/http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/nfs/nfs_srv.c
>
> lines 619-624.

Exactly. Patch coming soon.


-- 
Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)