Message ID | 20240222122828.3d8d213c@gandalf.local.home |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-76974-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:a81b:b0:108:e6aa:91d0 with SMTP id bq27csp91177dyb; Thu, 22 Feb 2024 09:27:38 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWogZfWSZskLNOpSv1ga9OQ7V1kg+pLvQ03QlVzefR57zSBK3S8tkkvQ0o61Zoop9raLMsyQMbSuj/BcqJutuAXFoYA7A== X-Google-Smtp-Source: AGHT+IFhCcJ7muXAmMMoeLeXhSUJIr3BPCwHAiT/2Rkk0WBOZ6LuS1lZ9hO33PzLPZyaksu0Uz5r X-Received: by 2002:aa7:c2d5:0:b0:565:4ab6:1f1f with SMTP id m21-20020aa7c2d5000000b005654ab61f1fmr1056201edp.3.1708622858034; Thu, 22 Feb 2024 09:27:38 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708622858; cv=pass; d=google.com; s=arc-20160816; b=oy0RFbjsyR//5M4K5dgYNpiMxVGoBu4bf51xo3qPf+UO/JucL1TdCanpNbsYBOmrwy HsF543VQENhHWtnPrmegNv4D8rWT1cAoY5Z31eEXvR8comCS6Xfugy/EBcsDAqGYyCW+ i73CsIydOpMrAUP97na6QaEy4gd0xLtUrk8wiChF4wtPCGYA56dRyGmmyXOXSg5xPcKk T7kHu+Gm5tRexwTmM1YQjlZ9uRgsKqghqE9W9Al/koYz7MDe9NWrYMelHc77jPwOfFEX lwFKDUvFpkjzOL3K7qSPich4V+GVKji9ySCH5o9WG04QxSg1mvNN9j6jq5fuCPCUkHlp h6pw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:subject:cc:to:from :date; bh=JQzbn7xzG9vyIrXjqT8JJu/dSr69psZEimdyab8GYzw=; fh=Q/2QU5q+soC3VXa/rDMcC8Bbnb8VHWr0mNjz0iQ4fvY=; b=z0k0Js0c5zkIBHWz5vi2wmXS20oml3DU96bpkvWLUOytHKi3kaZotym5D9LHMiM3YN PWy1mM+a9nHTImlyPDYuBcUhV/139rnamfXt3WZWeIpj0SC3+kjVkB9Ke7L2aYx94Ykb Bm6WNtX8gKvZ3d0UwBjp5DYgopOra6Pzl6grrTUzvcS1SRxBkhO2ZNHYTjAAJ89FjH34 tZMdDoh/aUlC8yHwx4I1mdjabXAaRNEWRfcw8xWQBXYkn6CpjAZYtH/4Ol6tVmao0sHi wMfbWvl2Iw+6y2WC8PEejcuTsJOtU4lGg5FDLrKY8Tv+WMIfWC6/TaPgjpkPr5bLqNum dy4Q==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-76974-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-76974-ouuuleilei=gmail.com@vger.kernel.org" Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id z17-20020a05640235d100b00563924b58aesi5674308edc.434.2024.02.22.09.27.37 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Feb 2024 09:27:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-76974-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-76974-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-76974-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id ABFC21F24F09 for <ouuuleilei@gmail.com>; Thu, 22 Feb 2024 17:26:56 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 888EE155A55; Thu, 22 Feb 2024 17:26:41 +0000 (UTC) Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 18D891482EA; Thu, 22 Feb 2024 17:26:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708622800; cv=none; b=Kp8EmxvN0lVhsR10hKOvYE98GvOgln+0sIc6UsRGI7G4UzxLD/pgDs5fskObtQZvgHfN2YJcE5/voSn98RxRyF55yLQPlyBYmHoH4m0+YiyuuosD4qbSFlytsKjnlGhrmcUmI2yX+mYbzFl8AVrrG4tJwvNez1/Y/xybVU3DUUU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708622800; c=relaxed/simple; bh=6g0prWZ7Mq8U3GlrMjmMcSvysWHUsBuonuNf4FT0a8Y=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type; b=bFvMRJP38UBKezeFjz5vsHDykBSnOAvmHlEz/JPQ9jvpJYi/hSXyPOsiXcffGUkUK1A67bsvJjBasxmcy3QJ0KGRs+eBGOU5cad+Y22fAXfWO1s8EU7d6kP7OnaJwRiQ8Jw3lz3YTpvXXyqMkdsG0Rf9ZaGSpcu5P4K+kBCve84= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6111C433C7; Thu, 22 Feb 2024 17:26:38 +0000 (UTC) Date: Thu, 22 Feb 2024 12:28:28 -0500 From: Steven Rostedt <rostedt@goodmis.org> To: LKML <linux-kernel@vger.kernel.org>, Linux Trace Kernel <linux-trace-kernel@vger.kernel.org> Cc: linux-nfs@vger.kernel.org, Chuck Lever <chuck.lever@oracle.com>, Jeff Layton <jlayton@kernel.org>, Neil Brown <neilb@suse.de>, Olga Kornievskaia <kolga@netapp.com>, Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com> Subject: [PATCH] NFSD: Fix nfsd_clid_class use of __string_len() macro Message-ID: <20240222122828.3d8d213c@gandalf.local.home> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791620922162352244 X-GMAIL-MSGID: 1791620922162352244 |
Series |
NFSD: Fix nfsd_clid_class use of __string_len() macro
|
|
Commit Message
Steven Rostedt
Feb. 22, 2024, 5:28 p.m. UTC
From: "Steven Rostedt (Google)" <rostedt@goodmis.org> I'm working on restructuring the __string* macros so that it doesn't need to recalculate the string twice. That is, it will save it off when processing __string() and the __assign_str() will not need to do the work again as it currently does. Currently __string_len(item, src, len) doesn't actually use "src", but my changes will require src to be correct as that is where the __assign_str() will get its value from. The event class nfsd_clid_class has: __string_len(name, name, clp->cl_name.len) But the second "name" does not exist and causes my changes to fail to build. That second parameter should be: clp->cl_name.data. Fixes: d27b74a8675ca ("NFSD: Use new __string_len C macros for nfsd_clid_class") Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> --- fs/nfsd/trace.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Thu, Feb 22, 2024 at 12:28:28PM -0500, Steven Rostedt wrote: > From: "Steven Rostedt (Google)" <rostedt@goodmis.org> > > I'm working on restructuring the __string* macros so that it doesn't need > to recalculate the string twice. That is, it will save it off when > processing __string() and the __assign_str() will not need to do the work > again as it currently does. > > Currently __string_len(item, src, len) doesn't actually use "src", but my > changes will require src to be correct as that is where the __assign_str() > will get its value from. > > The event class nfsd_clid_class has: > > __string_len(name, name, clp->cl_name.len) > > But the second "name" does not exist and causes my changes to fail to > build. That second parameter should be: clp->cl_name.data. > > Fixes: d27b74a8675ca ("NFSD: Use new __string_len C macros for nfsd_clid_class") > Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> > --- > fs/nfsd/trace.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/nfsd/trace.h b/fs/nfsd/trace.h > index d1e8cf079b0f..2cd57033791f 100644 > --- a/fs/nfsd/trace.h > +++ b/fs/nfsd/trace.h > @@ -843,7 +843,7 @@ DECLARE_EVENT_CLASS(nfsd_clid_class, > __array(unsigned char, addr, sizeof(struct sockaddr_in6)) > __field(unsigned long, flavor) > __array(unsigned char, verifier, NFS4_VERIFIER_SIZE) > - __string_len(name, name, clp->cl_name.len) > + __string_len(name, clp->cl_name.data, clp->cl_name.len) > ), > TP_fast_assign( > __entry->cl_boot = clp->cl_clientid.cl_boot; > -- > 2.43.0 > Do you want me to take this through the nfsd tree, or would you like an Ack from me so you can handle it as part of your clean up? Just in case: Acked-by: Chuck Lever <chuck.lever@oracle.com>
On Thu, 22 Feb 2024 13:25:34 -0500 Chuck Lever <chuck.lever@oracle.com> wrote: > Do you want me to take this through the nfsd tree, or would you like > an Ack from me so you can handle it as part of your clean up? Just > in case: > > Acked-by: Chuck Lever <chuck.lever@oracle.com> > As my patches depend on this, I can take it with your ack. Thanks! -- Steve
diff --git a/fs/nfsd/trace.h b/fs/nfsd/trace.h index d1e8cf079b0f..2cd57033791f 100644 --- a/fs/nfsd/trace.h +++ b/fs/nfsd/trace.h @@ -843,7 +843,7 @@ DECLARE_EVENT_CLASS(nfsd_clid_class, __array(unsigned char, addr, sizeof(struct sockaddr_in6)) __field(unsigned long, flavor) __array(unsigned char, verifier, NFS4_VERIFIER_SIZE) - __string_len(name, name, clp->cl_name.len) + __string_len(name, clp->cl_name.data, clp->cl_name.len) ), TP_fast_assign( __entry->cl_boot = clp->cl_clientid.cl_boot;