Received-SPF: pass (google.com: domain of linux-nfs-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: RE: 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+Fk7AQBWUaw
Date:   Mon, 22 Mar 2021 18:22:28 +0000
Message-ID: <DB6PR0102MB2630FFEE12410EC97457114488659@DB6PR0102MB2630.eurprd01.prod.exchangelabs.com>
References: <DB6PR0102MB2630902B2569060CD5E802EA88999@DB6PR0102MB2630.eurprd01.prod.exchangelabs.com>
In-Reply-To: <DB6PR0102MB2630902B2569060CD5E802EA88999@DB6PR0102MB2630.eurprd01.prod.exchangelabs.com>
Accept-Language: en-GB, fr-CH, fr-FR, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a4b4db7a-0e12-4a49-7281-08d8ed5f73b7
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2021 18:22:29.0664
 (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: NCoUwv/DhOQfWt5CLbu3W32iLaAbx8laElVzCr17JiLpOe1ASNio4GJ4AkkE2WW3W08AcJ5/HAhALP6jUkQhR+UZqjeTBuy91BbZMcUNy2U=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR01MB6838
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org

> -----Original Message-----
> From: Diego Santa Cruz
> Sent: 02 March 2021 10:02
> 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 o=
r
> not
>=20
> Hello,
>=20
> [resending as plain-text, sorry for the noise]
>=20
> 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 resi=
ding 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
> coreutils from version 8.30 to 8.31. This creates problems with ln in cor=
eutils
> in 8.31. I am currently using kernel 5.4.90.
>=20
> What I observe is that sylinkat("name", AT_FDCWD,
> "/path/to/nfs/existing/dir/") returns ENOENT when
> "/path/to/nfs/existing/dir/" is not in the dentry cache but EEXIST when i=
t 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 the newpath argument then i=
t
> returns EEXIST in all cases.
>=20
> Following change
> https://github.com/coreutils/coreutils/commit/571f63f5010b047a8a32503040
> 53f05949faded4 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 this change because ln did a stat of the link name path
> before calling symlinkat, so the entry was in the dentry cache when symli=
nkat
> executes.
>=20

Any feedback on this problem I'm seeing? Or should I report it using Bugzil=
la at https://bugzilla.kernel.org/ instead? Or elsewhere?

> I have created a simple program to reproduce this more easily, which I ha=
ve
> attached.
>=20
> 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)
>=20
> 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 i=
n
> fs/namei.c and the NFS client implementation. The filename_create()
> function will 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
> notice this flag in the nfs_is_exclusive_create() test, optimize away the
> lookup and not fill d_inode in the dentry. When execution returns to
> filename_create() the special casing will notice that is_dir is not set a=
nd
> last.name has a trailing slash and thus returns ENOENT. Looking for
> LOOKUP_EXCL usage in the kernel only NFS does this kind of optimization i=
n
> current kernels, but in 3.5 and older the same optimization was also done=
 by
> CIFS.
>=20
> 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
> link, which is not the case here.
>=20
> What would be the best course of action to address this issue?
>=20
> Thanks,
>=20
> Diego
> --
> Diego Santa Cruz, PhD
> Technology Architect
> spinetix.com

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