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 3EA89395AEB; Fri, 19 Jun 2026 20:42:09 +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=1781901731; cv=none; b=HIOZw8NfSFZFjEHmxJbpMQ6KwKfy4gyMMDXgFnKFLyqJIrSkHxbUD8jWfmSNd8pvaX9R9VK0/XxEodHDGsaKzBql9tebVjIDf8KOMZ56ve2p+TPMj00FazoIzW42ujzBOfl3ehTgakbwzzcA8kNQM+Jke+zRBc2KTE+ceCp3lyU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781901731; c=relaxed/simple; bh=757UIhZ7qu/lnWz8fcUhlso4FQ5q2+jRJh/hJ9bWavw=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=GmkFG5jx5slFQ53QRE3I0BPC44+3sGXKP3v7ywAHmKDcMR1VnRip/3fijYzx4eGR6osVYquDZo3Oigjq58MQWeRF3YX9b6V30kxunUGlAR/5pEDohvpd8XQ6oyZyoo4HdTzo719fvvB2xCwp7cijOiqgIvV8kaSqBXdrrqcEJ2I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LwACz3N5; 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="LwACz3N5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 99B561F00A3A; Fri, 19 Jun 2026 20:42:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781901729; bh=uYgEO0J5chhFwK20KEaELoCZrvXaLd37tAuHxYG7vFA=; h=Date:From:To:Cc:In-Reply-To:References:Subject; b=LwACz3N5PqTJEwzzmqEcIWIEzqeR9bQ1QU0I5jrwFTAv5//Bi4R5zcyiDAPwylOM/ 5pldCrMf/pLFsv8o4NEgBiaAUrjTdMo4tah9ZbBACS1Da1MJe330z9bgaU7J5g8Yye 6fRkPD74ft+7JX/bUtBc6gkEgGvQO3lT/INvnUsRNjJoVe4IQIFgh3IoK1MgIE4Jbs b8AMz/6JVcvC9VNwPYgS7uoRCKX1+aBncnzTOUfLPgFafbRBnnx1BsV9cAvLExxbK6 nQJWSCaL5AggIUGSMp6zOD5u64c22k4dyqXZODOymcEqze2TLRQp6M3ZwlFsQDF0Xx bXNh1VEdtqzww== Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfauth.phl.internal (Postfix) with ESMTP id DED23F4006A; Fri, 19 Jun 2026 16:42:08 -0400 (EDT) Received: from phl-imap-15 ([10.202.2.104]) by phl-compute-10.internal (MEProxy); Fri, 19 Jun 2026 16:42:08 -0400 X-ME-Sender: X-ME-Proxy-Cause: dmFkZTGd7Uv7s6hSToPo7vVLQmqA99Fg9s0uAkDgstU+Th9BvirHjm0hFNhaK1Twwl6P3U SHRH7L5Rv3LaB0UMu1A5sKpVMJUfT+ROHVcQNrw4rrRIKVWuMgGnqDBFh1cBErbbGbcDHI aL+CJOxBGvrSBpZI/nJnGiIlnzBp+PKfJrG2dZG7s+ToWZIs7/U7nvnIXlKtlOSXSw+VZB r+WY6j6DYqblu2er5HN8ObOmjEiSP//0rJ8sGRzLBZaI4iE8+llJYMOvLsbY96UxNt16jR DuXeTVDaxeUOjPNeU+NtDyUpCc8OOlnNw8gQf11eJOV2o0KC0dKsu65SslRQss56nUexZ3 OiW4kU8OUIrQEge8f9/i43dn1UNjGP9o6WNCczVTy1g4v9geXhSDrNqQvboir77XyFL9F7 EGN2DN754itu/KHPm57OH8Ev0Qgxglhc3mjlYLZfYshQzjBEeyAv90B5C/3gQMjKcA8lx6 G2EVOTPV9KK87AZtQGCTNPe9l73dupuQfktzofoOdaPyoxsrQVRXBU0fDxixMJFFP+IL9I 7Qc03i/p2H1c/D9tYAkU0xLV0HMrNQmHFXTKyNKdSchNIw9+TMeyLLkLWXJtFGvHqB1XEu i1cH+bIABMcl6yTGhBDZOlD7P6A1a7wevMK040vH3QDO7PleeyC7UXFUweHw X-ME-Proxy: Feedback-ID: ifa6e4810:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id BEEAD780AB5; Fri, 19 Jun 2026 16:42:08 -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: AvxUbqeuyocJ Date: Fri, 19 Jun 2026 16:41:47 -0400 From: "Chuck Lever" To: "Jeff Layton" , NeilBrown , "Olga Kornievskaia" , "Dai Ngo" , "Tom Talpey" Cc: "Trond Myklebust" , "Anna Schumaker" , "Steve Dickson" , linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org Message-Id: In-Reply-To: <20260619-exportd-netlink-v6-5-ddef3499793c@kernel.org> References: <20260619-exportd-netlink-v6-0-ddef3499793c@kernel.org> <20260619-exportd-netlink-v6-5-ddef3499793c@kernel.org> Subject: Re: [PATCH v6 5/6] nfsd: count NFSv4 callback operations per netns Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, Jun 19, 2026, at 11:26 AM, Jeff Layton wrote: > The NFS server tracks per-operation call counts for the forward channel > (proc4ops) but keeps no statistics for the NFSv4 backchannel (callback) > operations it sends to clients. > > Add a per-netns array of percpu counters for callback operations, indexed > by RFC 8881 callback opcode (OP_CB_GETATTR..OP_CB_OFFLOAD), and bump the > relevant counter in nfsd4_run_cb(), which is hit exactly once per callback > that is actually queued. > diff --git a/fs/nfsd/nfs4callback.c b/fs/nfsd/nfs4callback.c > index 71dcb448fa0a..b171257da6ba 100644 > --- a/fs/nfsd/nfs4callback.c > +++ b/fs/nfsd/nfs4callback.c > @@ -1921,12 +1921,32 @@ void nfsd4_init_cb(struct nfsd4_callback *cb, struct nfs4_client *clp, > bool nfsd4_run_cb(struct nfsd4_callback *cb) > { > struct nfs4_client *clp = cb->cb_clp; > + struct nfsd_net *nn = net_generic(clp->net, nfsd_net_id); > + const struct nfsd4_callback_ops *ops = cb->cb_ops; > + u32 minorversion = clp->cl_minorversion; > bool queued; > > + /* > + * Snapshot the opcode, minorversion, and the per-net pointer before > + * queuing: once nfsd4_queue_cb() has queued the work, the callback (and > + * the object that embeds it) may be processed and freed concurrently, so > + * neither cb nor clp can be dereferenced afterward. > + */ The comment says the opcode is snapshotted before queuing, but the code captures the cb_ops pointer and reads ops->opcode after nfsd4_queue_cb() returns: if (ops) nfsd_stats_cb_op_inc(nn, ops->opcode); That read is safe because every cb_ops points at a file-scope static const nfsd4_callback_ops (nfsd4_cb_recall_ops, nfsd4_cb_getattr_ops, and so on), which outlives cb, unlike cb and clp themselves. Would the comment read more accurately as snapshotting the cb_ops pointer rather than the opcode, perhaps noting that ops stays valid afterward because it points at static data? > nfsd41_cb_inflight_begin(clp); > queued = nfsd4_queue_cb(cb); > - if (!queued) > + if (queued) { > + if (ops) > + nfsd_stats_cb_op_inc(nn, ops->opcode); > + /* > + * Minorversion > 0 callbacks prepend a CB_SEQUENCE op (see > + * encode_cb_sequence4args()); count it like the forechannel > + * counts SEQUENCE, so it isn't perpetually reported as zero. > + */ > + if (minorversion > 0) > + nfsd_stats_cb_op_inc(nn, OP_CB_SEQUENCE); Can this inflate the OP_CB_SEQUENCE count for callbacks that never send a CB_SEQUENCE? The increment fires whenever minorversion > 0, including the ops == NULL case. The only callback with cb_ops == NULL is the null probe: nfsd4_init_cb(&clp->cl_cb_null, clp, NULL, NFSPROC4_CLNT_CB_NULL); which nfsd4_probe_callback() and nfsd4_shutdown_callback() queue via nfsd4_run_cb(&clp->cl_cb_null). For a 4.1+ client, nfsd4_run_cb_work() drops that work item without sending any RPC: /* * Don't send probe messages for 4.1 or later. */ if (!cb->cb_ops && clp->cl_minorversion) { nfsd4_mark_cb_state(clp, NFSD4_CB_UP); nfsd41_destroy_cb(cb); return; } So callback-channel probes, backchannel changes, and client teardown each bump OP_CB_SEQUENCE for a minorversion > 0 client even though no CB_SEQUENCE (and no callback at all) goes on the wire. Would moving the CB_SEQUENCE increment inside the if (ops) block avoid this? A real callback on a 4.1+ client always prepends CB_SEQUENCE, and the null probe carries cb_ops == NULL, so: if (queued) { if (ops) { nfsd_stats_cb_op_inc(nn, ops->opcode); if (minorversion > 0) nfsd_stats_cb_op_inc(nn, OP_CB_SEQUENCE); } } else { nfsd41_cb_inflight_end(clp); } > + } else { > nfsd41_cb_inflight_end(clp); > + } > return queued; > } -- Chuck Lever