Re: client lookup_revalidate bug

[Trond Myklebust <trondmy@hammerspace.com>]

On Wed, 2019-05-29 at 12:39 -0400, Benjamin Coddington wrote:
> On 29 May 2019, at 12:21, Trond Myklebust wrote:
> 
> > On Wed, 2019-05-29 at 11:08 -0400, Benjamin Coddington wrote:
> > > Hey, here's an interesting one, this seems wrong:
> > > 
> > > [root@fedora27_c2_v5 ~]# mkdir /mnt/one
> > > [root@fedora27_c2_v5 ~]# mkdir /mnt/two
> > > [root@fedora27_c2_v5 ~]# mount -t nfs
> > > -ov4,noac,sec=sys,nosharecache
> > > 192.168.122.50:/exports /mnt/one
> > > [root@fedora27_c2_v5 ~]# mount -t nfs
> > > -ov4,noac,sec=sys,nosharecache
> > > 192.168.122.50:/exports /mnt/two
> > > [root@fedora27_c2_v5 ~]# mkdir /mnt/one/A
> > > [root@fedora27_c2_v5 ~]# mkdir /mnt/one/B
> > > [root@fedora27_c2_v5 ~]# touch /mnt/one/A/foo
> > > [root@fedora27_c2_v5 ~]# cat /mnt/two/A/foo
> > > [root@fedora27_c2_v5 ~]# mv /mnt/two/A/foo /mnt/two/B/foo
> > > [root@fedora27_c2_v5 ~]# mv /mnt/one/B/foo /mnt/one/A/foo
> > > [root@fedora27_c2_v5 ~]# cat /mnt/two/A/foo
> > > [root@fedora27_c2_v5 ~]# stat /mnt/two/B/foo
> > >    File: /mnt/two/B/foo
> > >    Size: 0         	Blocks: 0          IO Block: 262144
> > > regular
> > > empty
> > > file
> > > Device: 2fh/47d	Inode: 439603      Links: 1
> > > Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid:
> > > (    0/    root)
> > > Context: system_u:object_r:nfs_t:s0
> > > Access: 2019-05-28 14:00:18.929663705 -0400
> > > Modify: 2019-05-28 14:00:18.929663705 -0400
> > > Change: 2019-05-28 14:00:58.990124573 -0400
> > >   Birth: -
> > > 
> > > 
> > > ^^ that lstat should return -ENOENT.
> > > 
> > > I think we detect a stale directory by comparing the directory's
> > > change_attr with the dentry's d_time.  But, here's a case where
> > > they
> > > are
> > > the same!
> > > 
> > > Am I wrong about this, or any clever ideas to catch this case?
> > > 
> > 
> > When you are mounting using 'nosharecache' then you are making
> > /mnt/one
> > and /mnt/two act as if they are different filesystems. The fact
> > that
> > they are the same on the server, means you are setting up a
> > testcase
> > where the files+directories are acting like the "changing on the
> > server" case as far as the client is concerned.
> > 
> > If you want the above to work in a sane fashion, then just don't
> > use
> > 'nosharecache'.
> 
> That was deliberate to avoid having to show two clients in the
> example..
> sorry, I should have been more explicit.
> 
> I think the client should be able to detect this case, since it can
> see an
> updated change_attr for that particular directory -- that is
> "/mnt/two/B/foo", but maybe it needs to compare the change_attr to
> its
> previous value instead of comparing it to the child's d_time?
> 
> The person who reported it has some workload that flips files between
> directories on separate clients, and doesn't like it when `mv`
> reports
> "source and destination are the same file".

Sorry, but that's not the case, because of the abuse of the
nosharecache flag. You are manipulating the file on the server and
expecting an immediate cache invalidation. That would require
information that the client does not have.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com