Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
To:     Trond Myklebust <trond.myklebust@hammerspace.com>,
        "anna.schumaker@netapp.com" <anna.schumaker@netapp.com>
CC:     "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: symlinkat() behavior with NFS depends on dentry being on cache or not
Thread-Topic: symlinkat() behavior with NFS depends on dentry being on cache
 or not
Thread-Index: AdcPQlxlz0o0+PGxRoKy1LGtL+Fk7A==
Date:   Tue, 2 Mar 2021 09:02:16 +0000
Message-ID: <DB6PR0102MB2630902B2569060CD5E802EA88999@DB6PR0102MB2630.eurprd01.prod.exchangelabs.com>
Accept-Language: en-GB, fr-CH, fr-FR, en-US
Content-Language: en-US
Content-Type: multipart/mixed;
        boundary="_002_DB6PR0102MB2630902B2569060CD5E802EA88999DB6PR0102MB2630_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ea96dda-3bab-4f44-e2bc-08d8dd59e0d5
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2021 09:02:16.5987
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5f4034fa-ed2d-4840-a93f-acb1e9633b93
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: h7+HsvxkGDSGCLy4jRKcoAJbZmKK3dnza02fSbH7N9TqLWkVMyOS4ideZCyOlDm3SHUe0BDZDYwdgVR7XWY76rLq/UeONmpwNepKVOOPF3Q=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR01MB6312
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

--_002_DB6PR0102MB2630902B2569060CD5E802EA88999DB6PR0102MB2630_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,

[resending as plain-text, sorry for the noise]

I noticed that the symlinkat() syscall changes behavior when the newpath (i=
.e. link name) has a trailing slash and is the path to a directory residing=
 on NFS depending on this path being in the dentry cache or not. I stumbled=
 upon this in the context of a Yocto / OE-Core system where I updated coreu=
tils from version 8.30 to 8.31. This creates problems with ln in coreutils =
in 8.31. I am currently using kernel 5.4.90.

What I observe is that sylinkat("name", AT_FDCWD, "/path/to/nfs/existing/di=
r/") returns ENOENT when "/path/to/nfs/existing/dir/" is not in the dentry =
cache but EEXIST when it is, but only when "/path/to/nfs/existing/dir/" is =
on NFS (NFSv3 in my case). Note that if I remove the trailing slash from th=
e newpath argument then it returns EEXIST in all cases.

Following change https://github.com/coreutils/coreutils/commit/571f63f5010b=
047a8a3250304053f05949faded4 in coreutils this makes "ln -sf name /path/to/=
nfs/existing/dir/" sometimes fail with a "cannot overwrite directory" error=
 (when the path is not in the dentry cache). There was no problem before th=
is change because ln did a stat of the link name path before calling symlin=
kat, so the entry was in the dentry cache when symlinkat executes.

I have created a simple program to reproduce this more easily, which I have=
 attached.

To reproduce do this.
  - Compile the attached symlinkat.c
  - Mount a NFSv3 filesystem at /mnt
  - mkdir /mnt/test
  - To test the error with no dentry cache and trailing slash:
    sync; echo 3 > /proc/sys/vm/drop_caches; ./symlinkat name /mnt/test/
    symlinkat name /mnt/test/ failed: No such file or directory (2)
  - To test with the dentry cache:
    ls -d /mnt/test/; ./symlinkat name /mnt/test/
    symlinkat name /mnt/test/ failed: File exists (17)
  - To test the error with no dentry cache and no trailing slash:
    sync; echo 3 > /proc/sys/vm/drop_caches; ./symlinkat name /mnt/test
    symlinkat name /mnt/test failed: File exists (17)

Although I'm no kernel expert, from what I've understood of the kernel code=
 this seems to be a bad interaction between the generic fs handling in fs/n=
amei.c and the NFS client implementation. The filename_create() function wi=
ll call __lookup_hash() after setting LOOKUP_EXCL in the flags and if there=
 is no dentry cache for the path then nfs_lookup() will be called, will not=
ice this flag in the nfs_is_exclusive_create() test, optimize away the look=
up and not fill d_inode in the dentry. When execution returns to filename_c=
reate() the special casing will notice that is_dir is not set and last.name=
 has a trailing slash and thus returns ENOENT. Looking for LOOKUP_EXCL usag=
e in the kernel only NFS does this kind of optimization in current kernels,=
 but in 3.5 and older the same optimization was also done by CIFS.

According to the symlink and symlinkat man pages ENOENT is returned when a =
directory component of newpath does not exist or is a dangling symbolic lin=
k, which is not the case here.

What would be the best course of action to address this issue?

Thanks,

Diego
--=20
Diego Santa Cruz, PhD
Technology Architect
spinetix.com


--_002_DB6PR0102MB2630902B2569060CD5E802EA88999DB6PR0102MB2630_
Content-Type: text/plain; name="symlinkat.c"
Content-Description: symlinkat.c
Content-Disposition: attachment; filename="symlinkat.c"; size=497;
	creation-date="Tue, 02 Mar 2021 08:59:00 GMT";
	modification-date="Tue, 02 Mar 2021 08:59:00 GMT"
Content-Transfer-Encoding: base64

I2luY2x1ZGUgPGZjbnRsLmg+CiNpbmNsdWRlIDx1bmlzdGQuaD4KI2luY2x1ZGUgPHN0ZGRlZi5o
PgojaW5jbHVkZSA8c3RkbGliLmg+CiNpbmNsdWRlIDxzdGRpby5oPgojaW5jbHVkZSA8c3RyaW5n
Lmg+CiNpbmNsdWRlIDxlcnJuby5oPgoKaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkK
ewoJaW50IHI7CgoJaWYgKGFyZ2MgIT0gMykgewoJCWZwcmludGYoc3RkZXJyLCAidXNhZ2U6IHN5
bGlua2F0OiA8b2xkcGF0aD4gPG5ld3BhdGg+XG4iKTsKCQlyZXR1cm4gRVhJVF9GQUlMVVJFOwoJ
fQoJciA9IHN5bWxpbmthdChhcmd2WzFdLCBBVF9GRENXRCwgYXJndlsyXSk7CglpZiAociAhPSAw
KSB7CgkJZnByaW50ZihzdGRlcnIsICJzeW1saW5rYXQgJXMgJXMgZmFpbGVkOiAlcyAoJWkpXG4i
LAoJCQlhcmd2WzFdLCBhcmd2WzJdLCBzdHJlcnJvcihlcnJubyksIGVycm5vKTsKCQlyZXR1cm4g
RVhJVF9GQUlMVVJFOwoJfQoJcmV0dXJuIEVYSVRfU1VDQ0VTUzsKfQo=

--_002_DB6PR0102MB2630902B2569060CD5E802EA88999DB6PR0102MB2630_--