From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) (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 240B2382F03 for ; Fri, 1 May 2026 14:40:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777646423; cv=none; b=JEDDDC1NwIo8bgIAFRV+CsJR3lelKYfaxddI1xzqywb4G46QZ1R083mTNQwOTHnGKjA2Nm+LXGwThMGdMIBQUCZ3/XMPktkQqF1cA67Bwswx2cpaQq/gvsBaIO4ELPTHiM0mCEdbBbXSOnlz9niyDtD24PRL2+ZOjM+EyJlCh2A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777646423; c=relaxed/simple; bh=hI3sELbh9pZAk1UJ91eIaTfaNqaL0ffPPb6un02NOxE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AYW3AKXEFu4ty82Ieu1FVouAzTklTpV0HeA1NqHM/NnPlt+z/Lx2LIHAXuAPhbHO68nGGh8qPCvWwBLgLfqJb221+cVAyD0uK6rceUtQ7Mv7cPpgMLu5stl3aWwrM02/D75MRrMdbincIu0qD5wI6hFE4x2MC39nRpDTV7WFF+Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=pjZlU87J; arc=none smtp.client-ip=209.85.210.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="pjZlU87J" Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-834da62e52dso999018b3a.3 for ; Fri, 01 May 2026 07:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777646421; x=1778251221; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=e+szxW8rgNgMBzsETrdf0sjEoyYi25PAwC2V8Vep6Dk=; b=pjZlU87JwHu08n9Y2RvzIo235F7C/95P+B4YJOu6V6gkOLmhHzyI6kPEfkvvMH7EYw 2/DtLzAgmbbhlEy0OGsom/dYGFnWMZr6ImyFq/qWSRLOjoe7vjL56x3yhwKxqW4PXiZs wLdE7lN11mF6He4RIqCjSMSo2NbvzYJcXQ36pGCT9i5cw0eYK3G6MDKhlI5vJMz1YlaW 4X5h/1LrF5E+Sbqsv5exqtViafQSWpwdqzVQt+DjgFo6WmkuNth7kf4zVNoZERMGnsQJ 3xaGzLdaUYfFX3Ty1G6CVICGYU79beKvIEsnpsDOS1uXShFUbQhy9nf3Z5EeJxN2Gtoc BofA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777646421; x=1778251221; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=e+szxW8rgNgMBzsETrdf0sjEoyYi25PAwC2V8Vep6Dk=; b=LjIEZbdVmDBJxPWog/FFyIUHFNWNuhoimtPl8xI5I3OQsknQnPduEa813RRGg8P1I0 D3HmAC5K0+4XuDP3hxmo1nS2Go76LA46TIbAk1W44quM+S03RDEUSazld18D9SBEgQcV y3DbbTWAasyKPhSn8JamqJXQwGKlUazrf6dhbT96YC64LnBzfuKKyzPdXjp0s1TXvS7w KQ4aDDOguAgwyeRyLQ0sG8NwRf3vElZtGxoCj9UzEDUKUXlfZlR8Qy3pOzTO8n0SsGio 2WJoh/ojiw8sBafPeMogQ/KymLqaJe2+iz7qCUHQHTHNtu8+nDx3aZetohQnMsyeSXrQ t1AA== X-Forwarded-Encrypted: i=1; AFNElJ9z+np4EQOzYzPWcvYp71PwL+NC2vowcTteRaDsNfSqGDQ9lVSavr2qF7S0ppziVfB+eQ585q1g39vLdJE=@vger.kernel.org X-Gm-Message-State: AOJu0YyIraLtkc87mqNE9l4P5OmH2Uu9fU05t4lof00DYmljytQToBnS PSwuT8p5HBvd+1g8MC++FTflp8zekrojhuGVYLNOJotDmgqUPKceGZCi X-Gm-Gg: AeBDietQozNTRWDIaLkP4hFImTU6NtQwBw2H77qHyLt/lBX/B9mXcXJInbRWyCyQL2E SLI0ZGEAAqL1e4Ac545oQbZAnouD7UgeWfG0fWucxJxY4Syqb4YwOj5QrQje9J/rGocPAH+/rB1 ZFzbmR29r5zICxDB96FVQLiaA0kMCj0fC9HcID60C0a7tq20+P1tsw7hqGQv27EDZmVXYBQkfXB PSAokahN5InVt0q1WwgvVLS/bvQc8NDf6ca3N/wZNSPBVtfKUrgEPgn6q6LL9CB0fQZo36qgdCi i19GU10Qnc78XZ/mZjApk4NFIQWufkGHncsG/M++ThRAwNQH/bLX522znLy07A29OtNCFdQH3+V QgiY/0QR+TS7rXVwzGQeoGD6sao0JvNggU4wvhkNezO2BHef4k1J+Ul0Jpq9l3RyM3zyHTCCL2y f/RqxsUi1AwnMUd2wjaCsoMOCTbGCpCg== X-Received: by 2002:a05:6a00:aa04:b0:81e:ef16:b288 with SMTP id d2e1a72fcca58-834fdb5c13dmr8147514b3a.22.1777646421184; Fri, 01 May 2026 07:40:21 -0700 (PDT) Received: from nova ([134.208.63.146]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-83515b5b921sm3492599b3a.54.2026.05.01.07.40.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 May 2026 07:40:20 -0700 (PDT) Date: Fri, 1 May 2026 22:40:17 +0800 From: Qian-Yu Lin To: Steven Rostedt Cc: mhiramat@kernel.org, david.laight.linux@gmail.com, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org Subject: Re: [PATCH] trace_printk: replace _______STR with __UNIQUE_ID(STR) Message-ID: References: <20260429165707.7020-1-tiffany019230@gmail.com> <20260429134226.49e95e9d@robin> 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=us-ascii Content-Disposition: inline In-Reply-To: <20260429134226.49e95e9d@robin> On Wed, Apr 29, 2026 at 01:42:26PM -0400, Steven Rostedt wrote: > On Thu, 30 Apr 2026 00:57:07 +0800 > Qian-Yu Lin wrote: > > > The macro trace_printk() uses a hardcoded identifier _______STR > > within a statement expression, which can lead to variable name > > shadowing if a caller happens to use the same name in its scope. > > Has this ever been a problem? > No, this has not been a practical problem. However, the long-underscore name ___STR is an indication of a potential shadowing risk. > > > > Following the pattern in commit 24ba53017e18 ("rcu: Replace ________p1 > > and _________p1 with __UNIQUE_ID(rcu)") and commit 589a9785ee3a > > ("min/max: remove sparse warnings when they're nested"), replace the > > hardcoded identifier with __UNIQUE_ID(STR). > > > > Since __UNIQUE_ID() must be expanded once to remain consistent across > > declaration and sizeof() within the statement expression, introduce a > > nested helper macro ___trace_printk. > > Hmm, so we are replacing one name with underscores with another name > with underscores? > > > > > Signed-off-by: Qian-Yu Lin > > --- > > include/linux/trace_printk.h | 10 +++++++--- > > 1 file changed, 7 insertions(+), 3 deletions(-) > > > > diff --git a/include/linux/trace_printk.h b/include/linux/trace_printk.h > > index 2670ec7f4262..060eccb40838 100644 > > --- a/include/linux/trace_printk.h > > +++ b/include/linux/trace_printk.h > > @@ -2,6 +2,7 @@ > > #ifndef _LINUX_TRACE_PRINTK_H > > #define _LINUX_TRACE_PRINTK_H > > > > +#include > > People are already saying that trace_printk.h slows down the compile. > Does this add any overhead to the compile? > > -- Steve Yes. I measured compile time of kernel/trace/ring_buffer_benchmark.o after make clean on an x86_64 machine running Ubuntu 24.04 LTS: - Original _______STR: 49.8s - v1 with __UNIQUE_ID (compiler.h): 53.5s - compound literal (no extra include): 33.2s I propose using a compound literal in v2, which eliminates the local variable entirely and requires no extra include: #define trace_printk(fmt, ...) \ do { \ if (sizeof((char[]) \ {__stringify((__VA_ARGS__))}) > 3) \ do_trace_printk(fmt, ##__VA_ARGS__); \ else \ trace_puts(fmt); \ } while (0) This fully eliminates the shadowing risk without any compile overhead. Qian-Yu > > > > #include > > #include > > #include > > @@ -84,15 +85,18 @@ do { \ > > * let gcc optimize the rest. > > */ > > > > -#define trace_printk(fmt, ...) \ > > +#define ___trace_printk(fmt, str, ...) \ > > do { \ > > - char _______STR[] = __stringify((__VA_ARGS__)); \ > > - if (sizeof(_______STR) > 3) \ > > + char str[] = __stringify((__VA_ARGS__)); \ > > + if (sizeof(str) > 3) \ > > do_trace_printk(fmt, ##__VA_ARGS__); \ > > else \ > > trace_puts(fmt); \ > > } while (0) > > > > +#define trace_printk(fmt, ...) \ > > + ___trace_printk(fmt, __UNIQUE_ID(str), ##__VA_ARGS__) > > + > > #define do_trace_printk(fmt, args...) \ > > do { \ > > static const char *trace_printk_fmt __used \ >