From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ABCB633D4F8; Wed, 10 Jun 2026 14:28:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781101715; cv=none; b=XHsTJ0XJk62m+B++fzV7sQMoua/n0NSw6+iY2QbrcfbN+b9LBkHnIgzcvCiBWInDQhFo/mhmpaTTX9f40waBK/T9kIQjjlo8GcfTa/4LRcZMJWXPXRKclbRYDrNzMOmkNd6qGoDF2RHEXJdXnOkLf1ZKhP/CixfZ7jwQNqBQdyE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781101715; c=relaxed/simple; bh=+bmwZAtHHEshgOQRjN5qxE4tw/GFszAT5/dc2pPV7X4=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=BW1ajHpeEI61t7AUCi6q2znLCIMF6KiMA4Z4tfSd3G+QjZV8vnNPgxIo8XdusA0q9wBv48y9wgsiD4KW0UGsr/8Ipx2+AMM1XnCJJBJhNArvn8+QuYAV2QKy6huVvj5BVY7TPBxI/1ulaPGNnWCIGtqoqgQrnkUeMT09L57+oFU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cBahSpXs; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cBahSpXs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0C6111F00898; Wed, 10 Jun 2026 14:28:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781101713; bh=usz09gXUhRAO92R6pHZAh8vlZ5c7zZWYbZMrAGM/zYA=; h=Date:From:To:Cc:In-Reply-To:References:Subject; b=cBahSpXs+rj+EGmSTxpFTUCH8GDXFZCSj4IZSZ/gCSFI73GFQ7SGh9/+6WRIbFUZs 6BE9hAU4zELw1P7OGX5s3lDw0HmUFnKgiIJCEPdVaBlwG+Go8cC9svNjeuDSMAQ2Lp MADs5BUjctJCHIDvyjjhPIXHHXPk8RKiKAMicLUStNmnz5Eoq9l7QbWeKmPEprS3jc 4pCD9Q2sYeD6Cw1eq9h4pDldHsbcsm/rfX2QaM3CBmiegeqJZZARz9DvKR1uUdV2/E 1NsOY3NUgCr96zj/8L9WqnHX4L4B+Eq41X0jpRqO9L0cVH8MF+ddeLe5GdXFVPXhD4 xAsPG9TzeKNCg== Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfauth.phl.internal (Postfix) with ESMTP id 68381F40097; Wed, 10 Jun 2026 10:28:32 -0400 (EDT) Received: from phl-imap-04 ([10.202.2.82]) by phl-compute-02.internal (MEProxy); Wed, 10 Jun 2026 10:28:32 -0400 X-ME-Sender: X-ME-Proxy-Cause: dmFkZTFug49oVC+lYOXXANZTytnInRE9GA76nwoLHANdW1h4FSdQOMVIi2Dymb/z1aE5No xZKQIbjnzTYfq7ejRHdCJF1jIUuB9IlOof13D10/4NF0R9QciAC0asuUdWaJjK131BpGn3 i5hm55tRIiyCZrr8R0ZeikhrVD5KwusATQgwuOPAUwtxiPtDZmvcVKm1rDgwYn76oZhUNh qg5JwsFejSx41++L/9ehtHuJQD2uA3Cm/XhJ8XBAPpagAgytpUMmGr6r/48tyXkq+A3PCA MNCvHFNMTbbP6GqTQFQSQTQkK4sh7+SGWp9bV7ca0yDDaYrZ/8Uvj45ugsCoX1v1IaEpVU SobUmEuTZj0qtx6DleyDOjNnsXea8OlWtt7cCva6LacDDgbBA//YiZq3mXW2y6mR0j8mvI hlX8iV3D4Yayabg1tLXhwRuvANRpsqJf0U1CR2/5n3s8xVK+spzL9uP8k49GATLCSnv9Ow yLLVPoWhdHBCEsruCPk/TfNeGAL7dswDyWd4jXg7ErIN27+1OP9tf3vIJ6N6Cg94SbRx4Z yRuJEIl4GGJDqSeEPpIotC3NdWRTTv42HNQvHbJvMH6K+ji8wAE5hI8BngVNOb+Mo6H2jI SmQQLSOKxKwfhLAxKQPML3JvCs4kzJZCSbVc7/bq3V+6MPTEi1knp7C1eQOA X-ME-Proxy: Feedback-ID: i20964851:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 408D4B60070; Wed, 10 Jun 2026 10:28:32 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: A7DWBoyFEMmk Date: Wed, 10 Jun 2026 10:28:10 -0400 From: "Anna Schumaker" To: "Thorsten Leemhuis" , "Trond Myklebust" , NeilBrown , "Igor Raits" Cc: =?UTF-8?Q?Jan_=C4=8C=C3=ADpa?= , linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, "Linux kernel regressions list" Message-Id: In-Reply-To: <5cbf8431-e3c4-41d9-afcd-fb121dc12395@leemhuis.info> References: <177745671692.1474915.5018486129724109553@noble.neil.brown.name> <20260429104938.1776671-1-igor.raits@gmail.com> <971ecb6c-2687-429f-af86-fc980c2d04f9@leemhuis.info> <5cbf8431-e3c4-41d9-afcd-fb121dc12395@leemhuis.info> Subject: Re: [PATCH] NFSv4: clear exception state on successful mkdir retry Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Thorsten, On Tue, Jun 9, 2026, at 6:05 AM, Thorsten Leemhuis wrote: > On 5/13/26 09:18, Thorsten Leemhuis wrote: >> [top-posting to facilitate processing] >>=20 >> @NFSv4 maintainers, just wondering, did this patch maybe fall through >> the cracks? It fixes a regression, that's why it's on my radar. Or was >> there some progress and I missed it? The patch is in my linux-next branch here: https://git.linux-nfs.org/?p=3D= anna/linux-nfs.git;a=3Dcommit;h=3D238e9b51aa29f48b6243212a3b75c8e48d6b96= fd It'll be included when the merge window opens this weekend. Anna > > Still no progress afaics. Feels like I'm missing something obvious or > like I'm totally of track. > > Igor, Neil, is that the case? Or are you also waiting for the fix to > make progress? > > Ciao, Thorsten > >> On 4/29/26 12:49, Igor Raits wrote: >>> After a server returns NFS4ERR_DELAY for an NFSv4 CREATE issued by >>> mkdir(2), the client correctly waits and retries. When the retry >>> succeeds, however, mkdir(2) can still surface -EEXIST to userspace >>> even though the directory was just created on the server. >>> >>> Reproducer (random 16-hex names so collisions are not the cause) >>> against an in-kernel Linux nfsd; reproduces under both NFSv4.0 and >>> NFSv4.2: >>> >>> N=3D2000000; base=3D/var/gdc/export >>> for ((i=3D1; i<=3DN; i++)); do >>> d=3D$base/$(openssl rand -hex 8) >>> mkdir "$d" 2>/dev/null || echo "$(date +%T) failed loop=3D$i $= d" >>> rmdir "$d" 2>/dev/null >>> done >>> >>> Failures cluster at the cadence at which the server-side auth/export >>> cache refresh path causes nfsd to return NFS4ERR_DELAY for CREATE. >>> >>> A wire trace of one failure (the three CREATE RPCs all come from a >>> single mkdir(2), generated by the do-while in nfs4_proc_mkdir()): >>> >>> client -> server CREATE name=3D... -> NFS4ERR_DELAY >>> ~100 ms later >>> client -> server CREATE name=3D... -> NFS4_OK (dir creat= ed) >>> ~80 us later >>> client -> server CREATE name=3D... -> NFS4ERR_EXIST (correct) >>> >>> Since commit dd862da61e91 ("nfs: fix incorrect handling of large-num= ber >>> NFS errors in nfs4_do_mkdir()"), nfs4_handle_exception() is called o= nly >>> when _nfs4_proc_mkdir() returned an error. That gate breaks retry-s= tate >>> hygiene: nfs4_do_handle_exception() resets exception.{delay,recoveri= ng, >>> retry} to 0 on entry, so calling it on success is what previously >>> cleared the retry flag set by the preceding NFS4ERR_DELAY iteration. >>> With the gate in place, exception.retry stays at 1 after the success= ful >>> retry, the loop runs once more, and the resulting CREATE for an >>> already-created name yields NFS4ERR_EXIST -> -EEXIST to userspace. >>> >>> Drop the conditional and call nfs4_handle_exception() unconditionall= y, >>> matching every other do-while in fs/nfs/nfs4proc.c (nfs4_proc_symlin= k(), >>> nfs4_proc_link(), etc.). The dentry/status separation introduced by >>> that commit is preserved. >>> >>> Fixes: dd862da61e91 ("nfs: fix incorrect handling of large-number NF= S errors in nfs4_do_mkdir()") >>> Reported-and-tested-by: Jan =C4=8C=C3=ADpa >>> Closes: https://lore.kernel.org/linux-nfs/CA+9S74hSp_tJu2Ffe2BPNC2T2= 5gfkhgjjDkdgSsF5c2rnJq_wA@mail.gmail.com/ >>> Reviewed-by: NeilBrown >>> Cc: stable@vger.kernel.org >>> Signed-off-by: Igor Raits >>> --- >>> fs/nfs/nfs4proc.c | 5 ++--- >>> 1 file changed, 2 insertions(+), 3 deletions(-) >>> >>> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c >>> index a0885ae55abc..ffd14141ea1d 100644 >>> --- a/fs/nfs/nfs4proc.c >>> +++ b/fs/nfs/nfs4proc.c >>> @@ -5393,10 +5393,9 @@ static struct dentry *nfs4_proc_mkdir(struct = inode *dir, struct dentry *dentry, >>> do { >>> alias =3D _nfs4_proc_mkdir(dir, dentry, sattr, label, &err); >>> trace_nfs4_mkdir(dir, &dentry->d_name, err); >>> + err =3D nfs4_handle_exception(NFS_SERVER(dir), err, &exception); >>> if (err) >>> - alias =3D ERR_PTR(nfs4_handle_exception(NFS_SERVER(dir), >>> - err, >>> - &exception)); >>> + alias =3D ERR_PTR(err); >>> } while (exception.retry); >>> nfs4_label_release_security(label); >>> =20 >>