Re: [PATCH 1/2] nfsd: map the ELOOP to nfserr_symlink to avoid warning

[Chuck Lever <chuck.lever@oracle.com>]

On 1/26/25 4:50 AM, Li Lingfeng wrote:
> We got -ELOOP from ext4, resulting in the following WARNING:
> 
> VFS: Lookup of 'dc' in ext4 sdd would have caused loop
> ------------[ cut here ]------------
> nfsd: non-standard errno: -40
> WARNING: CPU: 1 PID: 297024 at fs/nfsd/vfs.c:113 nfserrno+0xc8/0x128
> Modules linked in:
> CPU: 1 PID: 297024 Comm: nfsd Not tainted 6.6.0-gfa4c2159cd0d-dirty #21
> Hardware name: linux,dummy-virt (DT)
> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : nfserrno+0xc8/0x128
> lr : nfserrno+0xc8/0x128
> sp : ffff8000846475a0
> x29: ffff8000846475a0 x28: 0000000000000130 x27: ffff0000d65a24e8
> x26: ffff0000c7319134 x25: ffff0000d6de4240 x24: 0000000000000002
> x23: ffffcda9eaac3080 x22: 00000000ffffffd8 x21: 0000000000000026
> x20: ffffcda9ee055000 x19: 0000000000000000 x18: 0000000000000000
> x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> x14: 0000000000000000 x13: 0000000000000001 x12: ffff60001b5ca39b
> x11: 1fffe0001b5ca39a x10: ffff60001b5ca39a x9 : dfff800000000000
> x8 : 00009fffe4a35c66 x7 : ffff0000dae51cd3 x6 : 0000000000000001
> x5 : ffff0000dae51cd0 x4 : ffff60001b5ca39b x3 : dfff800000000000
> x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000ca5d8040
> Call trace:
>   nfserrno+0xc8/0x128
>   nfsd4_encode_dirent_fattr+0x358/0x380
>   nfsd4_encode_dirent+0x164/0x3a8
>   nfsd_buffered_readdir+0x1a8/0x3a0
>   nfsd_readdir+0x14c/0x188
>   nfsd4_encode_readdir+0x1d4/0x370
>   nfsd4_encode_operation+0x130/0x518
>   nfsd4_proc_compound+0x394/0xec0
>   nfsd_dispatch+0x264/0x418
>   svc_process_common+0x584/0xc78
>   svc_process+0x1e8/0x2c0
>   svc_recv+0x194/0x2d0
>   nfsd+0x198/0x378
>   kthread+0x1d8/0x1f0
>   ret_from_fork+0x10/0x20
> Kernel panic - not syncing: kernel: panic_on_warn set ...
> 
> The ELOOP error in Linux indicates that too many symbolic links were
> encountered in resolving a path name. Mapping it to nfserr_symlink may be
> fine.
> 
> Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com>
> ---
>   fs/nfsd/vfs.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> index 29cb7b812d71..0f727010b8cb 100644
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -100,6 +100,7 @@ nfserrno (int errno)
>   		{ nfserr_perm, -ENOKEY },
>   		{ nfserr_no_grace, -ENOGRACE},
>   		{ nfserr_io, -EBADMSG },
> +		{ nfserr_symlink, -ELOOP },
>   	};
>   	int	i;
>   

Adding ELOOP -> SYMLINK as a generic mapping could be a problem.

RFC 8881 Section 15.2 does not list NFS4ERR_SYMLINK as a permissible
status code for NFSv4 READDIR. Further, Section 15.4 lists only the
following operations for NFS4ERR_SYMLINK:

COMMIT, LAYOUTCOMMIT, LINK, LOCK, LOCKT, LOOKUP, LOOKUPP, OPEN, READ, WRITE


Which of lookup_positive_unlocked() or nfsd_cross_mnt() returned
ELOOP, and why? What were the export options? What was in the file
system that caused this? Can this scenario be reproduced on v6.13?


-- 
Chuck Lever