Re: [RFC PATCH 1/1] mount.nfs: Fix mounting on tmpfs

["J . Bruce Fields" <bfields@fieldses.org>]

On Fri, Apr 23, 2021 at 04:17:52AM +0200, Petr Vorel wrote:
> Hi,
> 
> > On Thu, Apr 22, 2021 at 09:18:03PM +0200, Petr Vorel wrote:
> > > LTP NFS tests (which use netns) fails on tmpfs since d4066486:
> 
> > > mount -t nfs -o proto=tcp,vers=4.2 10.0.0.2:/tmp/ltp.nfs01.nfs-4.2/LTP_nfs01.UF6gRZCy3O/4.2/tcp /tmp/ltp.nfs01.nfs-4.2/LTP_nfs01.UF6gRZCy3O/4.2/0
> > > mount.nfs: mounting 10.0.0.2:/tmp/ltp.nfs01.nfs-4.2/LTP_nfs01.UF6gRZCy3O/4.2/tcp failed, reason given by server: No such file or directory
> 
> > We should figure out the reason for the failure.  A network trace might
> > help.
> 
> Anything specific you're looking for?

Actually I was thinking of capturing the network traffic, something
like:
	tcpdump -s0 -wtmp.pcap -i<interface>

then try the mount, then kill tcpdump and look at tmp.pcap.

First, though, what's the output of "exportfs -v" on the server?

Note you need an "fsid=" option on tmpfs exports.

--b.

> 
> Doing full debug
> rpcdebug -m nfs -s all
> rpcdebug -m nfsd -s all
> rpcdebug -m rpc -s all
> 
> I see
> [13890.993127] nfsd_inet6addr_event: removed fd00:0001:0001:0001:0000:0000:0000:0002
> [13890.995428] nfsd_inet6addr_event: removed fe80:0000:0000:0000:1463:9fff:fea6:01b1
> [13891.002920] nfsd_inetaddr_event: removed 10.0.0.2
> [13891.007501] IPv6: ADDRCONF(NETDEV_CHANGE): ltp_ns_veth2: link becomes ready
> [13891.223432] NFS:   parsing nfs mount option 'source'
> [13891.225347] NFS:   parsing nfs mount option 'proto'
> [13891.227216] NFS:   parsing nfs mount option 'vers'
> [13891.228684] NFS:   parsing nfs mount option 'addr'
> [13891.229994] NFS:   parsing nfs mount option 'clientaddr'
> [13891.231326] NFS: MNTPATH: '/tmp/LTP_nfs01.lQghifD6NF/4.1/tcp'
> [13891.232923] --> nfs4_try_get_tree()
> [13891.235025] NFS: get client cookie (0x0000000013cf211e/0x0000000014b6df5b)
> [13891.237466] RPC:       set up xprt to 10.0.0.2 (port 2049) via tcp
> [13891.239618] RPC:       Couldn't create auth handle (flavor 390004)
> [13891.241556] nfs_create_rpc_client: cannot create RPC client. Error = -22
> [13891.243306] RPC:        destroy backchannel transport
> [13891.244017] RPC:       set up xprt to 10.0.0.2 (port 2049) via tcp
> [13891.244610] RPC:        backchannel list empty= true
> [13891.246232] RPC:       xs_connect scheduled xprt 000000005ddf4c3d
> [13891.247547] RPC:       xs_destroy xprt 00000000aeaed403
> [13891.250574] RPC:       xs_bind 0.0.0.0:873: ok (0)
> [13891.252225] RPC:       worker connecting xprt 000000005ddf4c3d via tcp to 10.0.0.2 (port 2049)
> [13891.254253] RPC:       xs_tcp_state_change client 000000005ddf4c3d...
> [13891.255693] RPC:       state 1 conn 0 dead 0 zapped 1 sk_shutdown 0
> [13891.257195] svc: server 000000007f0b7417, pool 0, transport 00000000f97f22bc, inuse=2
> [13891.258946] RPC:       000000005ddf4c3d connect status 115 connected 1 sock state 1
> [13891.260685] RPC:       xs_close xprt 00000000aeaed403
> [13891.260794] RPC:       xs_tcp_send_request(40) = 0
> [13891.263161] svc: server 000000007f0b7417, pool 0, transport 00000000f97f22bc, inuse=2
> [13891.264876] svc: svc_authenticate (0)
> [13891.264981] svc: server 00000000b4f0c1f0, pool 0, transport 00000000f97f22bc, inuse=3
> [13891.267954] svc: calling dispatcher
> [13891.270971] RPC:       xs_data_ready...
> [13891.273229] RPC:       setup backchannel transport
> [13891.274481] RPC:       adding req= 000000002ea0e13e
> [13891.275823] RPC:       setup backchannel transport done
> [13891.278253] svc: initialising pool 0 for NFSv4 callback
> [13891.279811] nfs_callback_create_svc: service created
> [13891.281138] NFS: create per-net callback data; net=f0000304
> 
> FYI tests are being done on network namespaces, thus there should be no real
> network issue. But I'll retest it on a real network. I admit that netns + tmpfs
> might be unrealistic scenario in practice.
> 
> Kind regards,
> Petr
> 
> > --b.