From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A50F63DA7F5 for ; Fri, 29 May 2026 16:22:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780071726; cv=none; b=oecprxwPXEd9xCgQle1bNCiLSoq2RoXAu3TQgucB5OAQQoYqb2f7vTOU9FuKxaWCxOe28NYriJ+8ZHNJ8kqKDsSFnNz2OyE4bhr5JPemNEK4L8uYWi4dZKVPBXCoG0lEGzE8JbHSuWaEXGnGhIHpEG68egVteZ8h+eqHPewbNHQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780071726; c=relaxed/simple; bh=A//8YORdov1M38vppcvtRu1emIm/9LLZtiexYw+Nklg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=mUR4KgJ1jEv1xQPmcfSSdfLdToTOQDCJlE7sXfYeGpmUKEzTw+zd/8o6Jfq+2KnpWp/0/5yB+45NC/YbHHK9WYEn2IhIOShEjRbOBQoW1S/h2ZxtkBJUfc2TKC060Jw4qliOhWieOzdJOKB+cU34o6EeM8fVxPyi9ukzCU/L+Xw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=hammerspace.com; spf=fail smtp.mailfrom=hammerspace.com; dkim=pass (2048-bit key) header.d=hammerspace.com header.i=@hammerspace.com header.b=XYKTBxS6; arc=none smtp.client-ip=209.85.210.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=hammerspace.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=hammerspace.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=hammerspace.com header.i=@hammerspace.com header.b="XYKTBxS6" Received: by mail-ot1-f42.google.com with SMTP id 46e09a7af769-7de4a9cb8eeso12527417a34.0 for ; Fri, 29 May 2026 09:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hammerspace.com; s=google; t=1780071724; x=1780676524; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=x2nqJnI5wzssMpalCg/FWhKkfDIw5nT9JhWq9LM/O78=; b=XYKTBxS6L91m3wZQmRy7o/BNwTevqz2LLbrMZDKCSG5Cg8ZbwND56u0bNMFQVs0SLk TDr14g9KCDuqNSQBxiXKINlK8eyotqqxJKRgsi04tqh4QY/32JZQnEb1HcuaEWg7x3vq ueqpiLBlS2r0I/qGmbw0bQ86F3//f3JUFmAUb+Ch/ZnCsCBRLPMjX7DW/Fj9hZuMjYMq aRUUxGL5uiGZbcdX+xBDZkAnP/O/KViZEaHUhSzaOXD0U7cyc93uGZr3V9Qzgh6qsO0c nQuAYBtkijstQbcf7Loy6osslf1UMr8D4m9TMHiEhzV7m7d7pq8Wn2c9LG1kPM0/r7LG aZgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780071724; x=1780676524; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=x2nqJnI5wzssMpalCg/FWhKkfDIw5nT9JhWq9LM/O78=; b=o5fQJCB/NJMp/PuhGm3vKJZ69ILWaFfr/R5ovI4QafT1EvL4r74wrnXskLqx6onWPi gisI1px6q886r1OwbDQX/Mqv6/BKGAt7zDNHeIcHwOVp0iiv8ofzKsnClpjUErQ6shYL TXtrBLaV0huiB5lqeYua14IPWS9c6ptELuw9T2l/0xyHxz0w1PEeXMB5qCSAyhHQfuEK e4+4f2ZUp+vU9lBT3DIygBgdCpBmjWizE5FGkZksWv5RjLif0RhKacfi8NwVSIiskLgE 3Gv14fgwuoV3LrxohgEqrmgvKuI4UMC6hnIH336TRZPt51BxJQfOXRYUL9/vciy/TyJK 70bQ== X-Forwarded-Encrypted: i=1; AFNElJ8GLs9W2cAvZ5Glwfof9zLpNnNPBbQMVYGyh72NEa9SCGA1SxTIcZqeaxJ/i3j9F2i69w4hpwnxvwdFwig=@vger.kernel.org X-Gm-Message-State: AOJu0Yw6FJjmPsRtWvBnpCtYHUcGKGIRE215Df0am6S8+THFD6BsoYT0 Tl+2t8Z13lLcak3ll4DF2T8W8jZTY9G2/y8qjL6uaqvwLMXi4S+258IMJhodeTAH9qIfNEv+pS0 5z4eB X-Gm-Gg: Acq92OFP+8xiqkBvQTgEcn+QTA1mNd/B1cIOCQgdmJzDC8m8Conk1srgAyVYoMZW+99 eKMr9zNeYENbMSnaWcYbVgpZT9sX4mpP3EUOEnntePmspqnBYVJlCIvXndvp3W3QUEGbVG0vKZK MnqdjC8N1g2VJAtO2lHLKj6YySfBOF76Cn7CY6ZpFUepYJk8VVpy8Oe3FvwySdP/oLWsVrOovLY rF355J+C9VD4HiYt5W2ny63VJYOhTnV0dDMFWZp2IQ8i5NWnC3zK6i7uH05lbt//J8i8zEPe0Zw fBQtffGpdEV7qo2VWXKgJCh/Yt5DNLRNEC0gx5ifX0lR5D9oB5tn01xTWTaGiuGIcTxO87K4iRS ct4krcHbmyOle14jozI8S1mN3fP0sdl5g7Yggeab+zNMT/9Zp4hCujmw2uGyDAKYp+A/NBSeNDm FbQ43bASBXjO73yJ5vD4EPOoRh2BTnhXlgsg/ZDz1V43VhZw2niTftgTDQs4NohDhg X-Received: by 2002:a05:6830:6386:b0:7dc:df37:844b with SMTP id 46e09a7af769-7e6a1c4cf1dmr420459a34.4.1780071724482; Fri, 29 May 2026 09:22:04 -0700 (PDT) Received: from [192.168.254.51] ([66.97.168.37]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7e695d178b6sm1881203a34.15.2026.05.29.09.22.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 May 2026 09:22:04 -0700 (PDT) From: Benjamin Coddington X-Google-Original-From: Benjamin Coddington To: Trond Myklebust Cc: Benjamin Coddington , Anna Schumaker , linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/1] nfs: return a write delegation when a SETATTR drops our write access Date: Fri, 29 May 2026 12:22:02 -0400 X-Mailer: MailMate (2.0r6272) Message-ID: <32A38159-77F7-41CC-9567-2089531D05F1@hammerspace.com> In-Reply-To: <461703b49f85216f6f6b18656e290287b0f701a0.camel@kernel.org> References: <64a9c99c387432399b4c4d9ce6dd4836b0170c15.1779995818.git.bcodding@hammerspace.com> <461703b49f85216f6f6b18656e290287b0f701a0.camel@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 29 May 2026, at 10:00, Trond Myklebust wrote: > > Hmmm... I'd argue that while recalling the delegation in this case is > mandatory for NFSv4.0, that is certainly not true for NFSv4.1. > > Furthermore, I'd argue that if the holder of a write delegation is just > changing the mode, then that should never result in a delegation recall > for a well written NFSv4.1 server. The reason is this does not impact > the client's ability to cache data, metadata or lock state. It only > impacts its ability to rely on previously cached access data when > handling new opens. > > One can argue whether or not it's needed for a uid or gid change by > said holder of the delegation, but there too I'd say the right > behaviour is to err on the side of not recalling. > The exception might be if this is an attribute delegation, and the > result will be that the cred attached to the delegation will no longer > be able to issue a SETATTR to update the atime/mtime on delegation > return. > > So yes to pre-emptive invalidation of the access cache, but I'm very > sceptical to actually pre-emptively returning the delegation or even > the layouts. The latency I was chasing comes from the server electing to recall on these SETATTRs. You're right that for v4.1 the mode change doesn't need to trigger a recall, and that the only client-side exposure is stale cached access on subsequent opens. It's already covered in the SETATTR reply path changing mode/uid/gid where it sets NFS_INO_INVALID_ACCESS in nfs_update_inode(), and a fresh open over the delegation still goes through nfs_may_open() -> nfs_do_access(), so it revalidates with the server rather than trusting the cached result. The server isn't recalling these for cache coherence. When the change removes the holder's write, a later SETATTR(size) under the delegation carries the delegation stateid, not an open stateid (nfs4_copy_delegation_stateid()), and the client can reopen O_WRONLY from the delegation with no OPEN on the wire — so the server can't tell whether the holder still has the file open for write, nor apply the usual "open-for-write overrides current mode" check for the truncate. The recall forces a DELEGRETURN + CLAIM_DELEGATE_CUR reclaim that re-establishes a real (or absent) open stateid, letting the server decide the truncate correctly. For write-retaining SETATTRs none of that applies and the server shouldn't recall — which is where the latency I was chasing actually came from, and the better place to remove it. Thanks for the review. Ben