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 41B49400981; Thu, 16 Jul 2026 14:20:01 +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=1784211602; cv=none; b=ZzA0BvW4BmpaukKu9kZ7Asp1Dw+wJjTj77w8lqzZdYPShba2Xc4pm88ZV+z3BSvMwtd9ADlNggQTADQhJVJ4k1PTdKfQZvINDTefNopT7ewD7+LnV9rceRAPJtxGEMOeNyImFlaDb+tFHJoKuDcSJuPprd8JJIh5UkewoBEOOD4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784211602; c=relaxed/simple; bh=6yQKNjiAlUATAOZ2tTYGGpZE46xFWW7+s0wbWPOukSE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ue73VufqjN9F49sd72WmBzjX2nSTk/OIW/N2tV3A0APq90cmi+j2fNEc28J14uGqB5BVgZ2m6cmSkc+7a6aSTgMxv9BAOtsJ5+fjaFvDbCdNgEOMKs1qUvl4ZYl1r5XXhIUBcgfnH/CTvDmovGZS5XywQK9n7ti5r2q5rhzscwQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=Jnwn17Jn; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="Jnwn17Jn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CEB361F000E9; Thu, 16 Jul 2026 14:20:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1784211601; bh=+M6xgrM/p1TSTdsOLHuQF6GXThRUQAoN7TROa4u4/3E=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Jnwn17JnGZBM5KQyal4MIDoi9mMkDM9IsVInCRw5DDEM2TBx16q9gmvcIUtONp43S 4ACk1u01AMOzWY2ckswpx+5TNO5f0FIL8gaEk1llNcnmE2AUiUJiZeKkHJG+f86JBa 6jrlxgzuooNWhEemkMZd86/C/Q+UBB+OuSTqkraw= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Scott Mayhew , Chuck Lever , Chuck Lever , Sasha Levin Subject: [PATCH 6.12 002/349] nfsd: fix file change detection in CB_GETATTR Date: Thu, 16 Jul 2026 15:28:56 +0200 Message-ID: <20260716133033.343650501@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260716133033.287196923@linuxfoundation.org> References: <20260716133033.287196923@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Scott Mayhew commit 304d81a2fbf2b454def4debcb38ea173911b72cd upstream. RFC 8881, section 10.4.3 doesn't say anything about caching the file size in the delegation record, nor does it say anything about comparing a cached file size with the size reported by the client in the CB_GETATTR reply for the purpose of determining if the client holds modified data for the file. What section 10.4.3 of RFC 8881 does say is that the server should compare the *current* file size with the size reported by the client holding the delegation in the CB_GETATTR reply, and if they differ to treat it as a modification regardless of the change attribute retrieved via the CB_GETATTR. Doing otherwise would cause the server to believe the client holding the delegation has a modified version of the file, even if the client flushed the modifications to the server prior to the CB_GETATTR. This would have the added side effect of subsequent CB_GETATTRs causing updates to the mtime, ctime, and change attribute even if the client holding the delegation makes no further updates to the file. Modify nfsd4_deleg_getattr_conflict() to obtain the current file size via i_size_read(). Retain the ncf_cur_fsize field, since it's a convenient way to return the file size back to nfsd4_encode_fattr4(), but don't use it for the purpose of detecting file changes. Remove the unnecessary initialization of ncf_cur_fsize in nfs4_open_delegation(). Also, if we recall the delegation (because the client didn't respond to the CB_GETATTR), then skip the logic that checks the nfs4_cb_fattr fields. Fixes: c5967721e106 ("NFSD: handle GETATTR conflict with write delegation") Cc: stable@vger.kernel.org Signed-off-by: Scott Mayhew Signed-off-by: Chuck Lever [ cel: no deleg_ts in 6.12.y; dropped the now-dead ncf_cur_fsize init ] Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin --- fs/nfsd/nfs4state.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index 1ce66acc9b6ba0..e18d70adcdb903 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -6086,7 +6086,6 @@ nfs4_open_delegation(struct nfsd4_open *open, struct nfs4_ol_stateid *stp, goto out_no_deleg; } open->op_delegate_type = NFS4_OPEN_DELEGATE_WRITE; - dp->dl_cb_fattr.ncf_cur_fsize = stat.size; dp->dl_cb_fattr.ncf_initial_cinfo = nfsd4_change_attribute(&stat); trace_nfsd_deleg_write(&dp->dl_stid.sc_stateid); } else { @@ -9040,11 +9039,15 @@ nfsd4_deleg_getattr_conflict(struct svc_rqst *rqstp, struct dentry *dentry, if (status != nfserr_jukebox || !nfsd_wait_for_delegreturn(rqstp, inode)) goto out_status; + status = nfs_ok; + goto out_status; + } + if (!ncf->ncf_file_modified) { + if (ncf->ncf_initial_cinfo != ncf->ncf_cb_change) + ncf->ncf_file_modified = true; + else if (i_size_read(inode) != ncf->ncf_cb_fsize) + ncf->ncf_file_modified = true; } - if (!ncf->ncf_file_modified && - (ncf->ncf_initial_cinfo != ncf->ncf_cb_change || - ncf->ncf_cur_fsize != ncf->ncf_cb_fsize)) - ncf->ncf_file_modified = true; if (ncf->ncf_file_modified) { int err; -- 2.53.0