From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (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 F2CC31F5437 for ; Wed, 29 Apr 2026 21:47:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777499254; cv=none; b=e3S+ffDeElYmZNh3kuANBCn68Ifg4I7n9MFTCZtAcnign5iLT3FYC77c8VkenU8qvJ9fM80L1EIOn9EL27vtl/0PQNmPqe04rRs0el/93zZ/LOKzMzz9dwYplfGcvwr83BtsDrNxR9xzj8TM2WjWH39N5VDWRYS2xwG/iKNwDmk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777499254; c=relaxed/simple; bh=rK9c6EtHS68OzgcIJdBQT5oLUKcLN/3nmmxams7EhQo=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=WzPyjFctID8WGlX9vbHWTHjugw/NjFX+LfLpq5V/v3hZ1myGW7MPazf05GEl6s3M1GMEiYJWqBT7eOdviDm/MPq+zjxjwh/DcyxW4WriNNoSdLUHdxiwVxIno8VzGsf/6xy4mr3PD2fy3KohozTK77eP+hWCy8CZfYyKJDYj234= 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=KjTNAzUw; arc=none smtp.client-ip=209.85.221.46 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="KjTNAzUw" Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-445795cf6f1so156943f8f.1 for ; Wed, 29 Apr 2026 14:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777499250; x=1778104050; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=VaLxc2VtdwmOLRiyOYeHaZXfR7Fifyq8Gol0GSWhrxg=; b=KjTNAzUwBjl2zQ1Co5KQJri1KHi29hnhgVTyJsQTSxl3B7ZO5pV9zsdJDTJNE6xf/2 2uvb8nrZvJnOGTCr2eMeI1Ttqxp8tuVRjxL/8WVJ7pDXZbR/7GVhQp3FXVx2IWOwzeZr GsKLVt3j1qtgPmBcXL+a7Vq7PHDqDgH5Vi6/DuMvlWOOedOKwNYbT95/Dvbmx0l49TA+ G8IV45858hWDBRlllgqS0ZC/gMRPKR4vxIKiD1UkoWT8gps2GJDbXl2YeWfczmMLcUre 7Gm5fwfY1pQWRS0v1XPJJkH6mlqad7HN6Sfaoy/Wpicup6+a76GThhynmTth0wv09lDw uIPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777499250; x=1778104050; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=VaLxc2VtdwmOLRiyOYeHaZXfR7Fifyq8Gol0GSWhrxg=; b=AnHFWTXLFcxUpP9rv4D7JzkZvp/kRGChKsx7Yl6UgHMMa/8j4N39MuyPCpRrxTcLUI x0JUP+Mp0OVFPhtm0BI4+9M5tSVOkC7ddEIyeYhLxPGT0Gr8yRgwaJxYS37Zsl2MXHgv 02v/bYPyWd9GuWt/lCo/V4GvqbysfGoTHP4GRbEY4BHZ+ykWljtlm/3WJ9pkntDW2Pa5 fUwyJtohBJgQZKepIqmMps/CwTuFUA9dHQEmbacCvPG2/pMSJFeZkjA6CFAmvpd0q91y EF476A7ouzS/ptCUdJhPSQCsBHDbOS5IejkrpHvaUaRCpCeJmRebZW6wDPx5ojSODdg1 R16A== X-Forwarded-Encrypted: i=1; AFNElJ9HrpVEP+3HO1Iowr2mNhUM9ZYWNdOs/R3jQqDOKoch4vie334uIUpeAbJB5R2eiSXwt+Ty7c7BIMaJmJg=@vger.kernel.org X-Gm-Message-State: AOJu0YzqIFrcrP6cEfyopbDJBghN7SMFNe6t8+i2ntZwxW/Fx/LQHEUj MhEU77L6jSikc/xTX43tiFfsueZltztqiEDEFBjCLULT/Rqcb1/TDNzA X-Gm-Gg: AeBDievmT1MPgXHsT0Pyj2nOskNLBgoHNNEVpQMSXIMMV2bRcxutpZwNGNIszQFCQJ3 y/1u0fecU5+ym/2nYUymmckmeFMVAm/HzJGK+RF4KwCU4Q6G9rbZa46B2pbH4akgsRWopT7emJ1 /MKjplKeaxtDuzfeZKyf3BPDgZ9l3SoCYpBWx4HdPP+23pEoJIyOSxInfo0kis7W08sp5NxTaMU KzBLoQ1WcUyxNSs4S3fDfSnUqhuHQSGyMPXqKUN3vgtthFen5LhUywgWHQh1KPI1QHt2PJHWwFr BdcUhaeSjozCiG9sBY45amBKG681Z0rRRxi1MReJdR3JyFku6VopUJQnW0UicobzLJpqyQM0i1u s7jBRVeZ2Myqi0D3YgE1oBFW67lUye/Muhhox7B3ci2NUXjprwhP+3N6naqb/+z+PJHLIbCu0a8 DynWuf25RRTsqpLz/s+J22pnm9X5imR5B9SrWbZuKL7+zUy4v8IvzuT+nSsdoKkEek4RWP+F5WR iI= X-Received: by 2002:a05:6000:290d:b0:43d:1c7a:8b5b with SMTP id ffacd0b85a97d-4493ffceec2mr85031f8f.40.1777499250051; Wed, 29 Apr 2026 14:47:30 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-447b421721fsm7696371f8f.15.2026.04.29.14.47.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Apr 2026 14:47:29 -0700 (PDT) Date: Wed, 29 Apr 2026 22:47:28 +0100 From: David Laight To: Steven Rostedt Cc: Qian-Yu Lin , mhiramat@kernel.org, mathieu.desnoyers@efficios.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: <20260429224728.339a632c@pumpkin> In-Reply-To: <20260429134226.49e95e9d@robin> References: <20260429165707.7020-1-tiffany019230@gmail.com> <20260429134226.49e95e9d@robin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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-Transfer-Encoding: 7bit On Wed, 29 Apr 2026 13:42:26 -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? > > > > > 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). min and max do get nested - so it is important that the 'local' variables have different names - otherwise you can get invalid expansions. No one is going to have: trace_printk(fmt1, trace_printk(ftm2, ...), ...) it just doesn't make sense. There is a slight problem the ____________________________STR might be used by an entirely different #define. Just using _trace_printk_str[] would make this pretty unlikely. It would also have the advantage of making the .i file a bit easier to read, all the UNIQUE names in min/max output make it really hard to see what the output actually means. > > > > 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? A little - nothing is free. David > > -- Steve > > > > #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 \ > >