From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (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 7A78948097B for ; Wed, 3 Jun 2026 13:03:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780491841; cv=none; b=FuJDbI/hwZByB6b/v6121G6Dgaz26xxz4qSy5UFpEpKhDBJELN28HgxboYvrDVI8b6iPe/hKEkue4CdVdaEQMMGMSbwx6EboDAtx19Cw9/gouMdDEiWpJ8k7TDtFpqOuZrjDf/9AhOBo7RQvAclMlzEegSoukJ1tpN5KQF+O3OA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780491841; c=relaxed/simple; bh=MBU7CS7WVwYwMOdcet6ICEOaUIj+8mKXQIBdEMW6F8k=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=N6gmYEjy2oKnq210nFmSnbPphWb7a05w6lM6MpZEFw4knbndg4Abx+kY1WTgzK5BFyFeE4m/i3Oc480tDPmgci0NVBh6xfkZ99hWa9W2o2FnET2UzI/V1yof1uksQ4d/mDAqM1fpojJqG+k4YJ08jAsXIA1OAiTAX8gLo7bL3FY= 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=RT49zpA8; arc=none smtp.client-ip=209.85.221.45 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="RT49zpA8" Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-45ef1198766so428154f8f.0 for ; Wed, 03 Jun 2026 06:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780491838; x=1781096638; darn=lists.linux.dev; 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=npACNw5GZ77miqur21FanA4v5+vTppUVJOnuElrt9AM=; b=RT49zpA82jPuPznWFl8S7ldRh9EeU2yUfCkRXvcWsaqxtv9cxIIC5lIIgUVHir01RX B6lJV1kjf2Z6DlSDDxENNQ3CO+lRN+CgH4hrnBKC3wRqzzvSRSly41SMEchRtvJ7QS8i Bp51b8H9M/JiKIfhKUjKbyUjWoN0oe42iaJ5hO70Jg/BR5vPuSvma/rnsBpk60JZGHV7 myC/Yw122cMxSIkhXafWPEXJwaABaaEkFvnaYhW6YC6PtW86Uy+gabkv8jEldf96pAbQ QdhX3QaezQTDpMJTeUwvIbApFXK0pT7WzXpz8i7aOg793O73Jjn3Cf+iWRcHLaFBRuDh y6JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780491838; x=1781096638; 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=npACNw5GZ77miqur21FanA4v5+vTppUVJOnuElrt9AM=; b=Cx3IpRSlNvsP4bvTD385Ysw4DRBTnGLkO7YHAOcmDOAF75wVTIs4QAMNjt+08HfWFd /stAadcj5tyGMcWFrDp+wa1QBdCmSEMKrnoNS9zBfpKkGqWrnWCcfc37Chu9E+X6lVas fJV3gLd8Y+YWOcYnq85WUQ72UjwSVcjefh9bEo7B/bQ3IisHu3VXqTeOfdCugs/8r37r r76m9Ob2hDg0Xvawet/a9RHduM+IbIQb68e3ddax7bNtSuvDEs1qaNLEfN51cS/zOkur sC9sAqhAXHnTfoDD9pwmwULIN+fwCRb4aIa8deWqqAnCKk3t60ndlAuSrT/2AQ6IRDIl FatQ== X-Forwarded-Encrypted: i=1; AFNElJ+pgqNfy+nufG07iSLHV1Gam8F46h19C1WfRLU5xyB/3M99uw3UKoC/7+eTNx6jQ9lFDYwTrNYycK0=@lists.linux.dev X-Gm-Message-State: AOJu0Yy/5ctRHaAg99ucXb3el/bTi4vOP/JsGya5y6/5YvN7IM77A0Xd MGv3FrNstaJi3lkRleqcpagueKnm7yIoj9jU8VMN5Pm3JVAukHf/lsu1 X-Gm-Gg: Acq92OExX48UTnh9KchxLDm2Ecv34GU+cibkfQEm59in0Iy0aXui/y42r1shSX7tRVi IdcoMVo9qgZ+MfmK1Jg0BpnTntd9SOkV0BlKTmGwMAwY7J6xAPs0x7OPYSLLfpa8DuXRY2Ub9tP wzvDg4DYXJlw8kY3KbCA+ycnEyY73oJLkQvdLDrKQQOqkt7AS46ryHTiVBB+hki1LFrTFr3Vu+l kZzv0eaeRtLHRNQzUwACICgBkic+Iob8OWjG/g7qgpfIoy0ucnsvzMZjVCoIN853J0zItTzQGCs GLWGJ8IdU3Gj+e+d4kR38LuG2WihNrkvEcFi72C+PtOiONFQPq/bS9ywRpYHc2OXloaBDXKQBGY DC1EIAVVLT5QZjqfuTCpKF8ujvdlzu/8KRibnNyEuYI1upK/xVingZMZnpjWBdOBapnco+20UyN Or6NLwPLj1TYn+1dR+i0cB7z0Zy2qTdwXptOHa8+Z7ctfSeZMmUyebSdIZ+pyhIzeanjCoqlE= X-Received: by 2002:a5d:5f8c:0:b0:460:133f:2a4e with SMTP id ffacd0b85a97d-460212df7e6mr4465185f8f.13.1780491837758; Wed, 03 Jun 2026 06:03:57 -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-4601f368e9fsm7576265f8f.37.2026.06.03.06.03.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2026 06:03:56 -0700 (PDT) Date: Wed, 3 Jun 2026 14:03:54 +0100 From: David Laight To: "Arnd Bergmann" Cc: "Rasmus Villemoes" , "Andy Shevchenko" , "Arnd Bergmann" , "Steven Rostedt" , "Masami Hiramatsu" , "Andrew Morton" , "Petr Mladek" , "Nathan Chancellor" , "Dennis Dalessandro" , "Jason Gunthorpe" , "Leon Romanovsky" , "Arend van Spriel" , "Miri Korenblit" , "Mathieu Desnoyers" , "Sergey Senozhatsky" , "Nick Desaulniers" , "Bill Wendling" , "Justin Stitt" , "Vlastimil Babka (SUSE)" , linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org, brcm80211@lists.linux.dev, brcm80211-dev-list.pdl@broadcom.com, linux-trace-kernel@vger.kernel.org, llvm@lists.linux.dev Subject: Re: [PATCH 1/2] tracing: work around -Wmissing-format-attribute warning Message-ID: <20260603140354.6744499b@pumpkin> In-Reply-To: References: <20260602150904.2258624-1-arnd@kernel.org> <35c1ba62-e74d-4abc-aa73-ccd35968ff89@app.fastmail.com> <875x40hz7k.fsf@prevas.dk> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: brcm80211@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 03 Jun 2026 10:41:18 +0200 "Arnd Bergmann" wrote: > On Wed, Jun 3, 2026, at 09:15, Rasmus Villemoes wrote: > > On Tue, Jun 02 2026, "Arnd Bergmann" wrote: > >> On Tue, Jun 2, 2026, at 20:59, Andy Shevchenko wrote: > >>> On Tue, Jun 02, 2026 at 05:07:05PM +0200, Arnd Bergmann wrote: > > > > May I suggest a different approach, that avoids having that extra > > function emitted (which presumably compiles to a single jump > > instruction, but still, with retpoline and CFI and all that it all adds > > up): Keep the declaration of __vsnprintf() in the header without the > > __print() attribute, but then do > > > > int __vsnprintf(char *buf, size_t size, const char *fmt_str, va_list args) > > __alias(vsnprintf); > > > > in vsprintf.c. Aside from reusing the same entry point, I could well > > imagine a compiler some day complaining about seeing the printf > > attribute applied in a local extra declaration but not having it in the > > header file. > > > > Presumably it will need its own EXPORT_SYMBOL if any of the intended > > users are modular, and it certainly still needs a comment. > > I had tried that earlier but given up because the attributes have to > match exactly. > > This definition works with all currently supported versions of gcc, > but may have to change when the there is a new version that adds > even more attributes: > > int > __printf(3, 0) > __attribute__((nothrow)) > __attribute__((nonnull(1))) > __vsnprintf(char *__restrict buf, size_t size, > const char * __restrict fmt_str, va_list args) > __alias(vsnprintf); > > We'd probably want to also add __nothrow and __nonnull macros > in linux/compiler-attributes.h if we do this. > > For reference, see below for the alternative idea I had > that avoids adding the __vsnprintf() alias altogether by > passing down the va_format using "%pV". > > I don't think I actually got this one right in the end > since I only build-tested it, but I expect it could be done > if someone is able to test and fix all the corner cases > properly. > > Arnd > > diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h > index 4715330c7b6b..8e44fc3e60b0 100644 > --- a/include/linux/trace_events.h > +++ b/include/linux/trace_events.h > @@ -956,14 +956,11 @@ perf_trace_buf_submit(void *raw_data, int size, int rctx, u16 type, > * gcc warns that you can not use a va_list in an inlined > * function. But lets me make it into a macro :-/ > */ > -#define __trace_event_vstr_len(fmt, va) \ > +#define __trace_event_vstr_len(vf) \ > ({ \ > - va_list __ap; \ > int __ret; \ > \ > - va_copy(__ap, *(va)); \ > - __ret = __vsnprintf(NULL, 0, fmt, __ap) + 1; \ > - va_end(__ap); \ > + __ret = snprintf(NULL, 0, "%pV", vf) + 1; \ This adds an extra snprintf call - non-trivial and more stack. Can't you just use the old code with vf->fmt and vf->ap ? And does the %pV" include the va_copy()? It isn't normally needed. Any scheme for avoiding doing the printf processing twice is likely to be a gain. -- David