All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Rasmus Villemoes <ravi@prevas.dk>
Cc: Petr Mladek <pmladek@suse.com>,
	Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	Kees Cook <kees@kernel.org>, Steven Rostedt <rostedt@goodmis.org>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org,
	John Ogness <john.ogness@linutronix.de>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v1 6/6] vsnprintf: Mark va_format() with __printf() attribute
Date: Fri, 21 Mar 2025 16:16:57 +0200	[thread overview]
Message-ID: <Z9102aHbXlVS50Cq@smile.fi.intel.com> (raw)
In-Reply-To: <87iko2ear3.fsf@prevas.dk>

On Fri, Mar 21, 2025 at 03:09:20PM +0100, Rasmus Villemoes wrote:
> On Thu, Mar 20 2025, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

...

> I'm sorry, but this is broken in so many ways I don't know where to
> start.

You shouldn't be sorry, my guts feeling was on the same page, I was sending it
with the expectation that someone will direct me, so thank you!

(And that's why there is a paragraph about this rather hackish patch)

> The format string that va_format actually passes on is va_fmt->fmt, and
> that is _not_ at all the same thing as va_fmt cast to (const char*),
> even if ->fmt is the first member, so the static_assert doesn't do what
> you think it does. So of course the ptr variable (which is (void*)) can
> be passed as a (const char*) argument just as well as it can be passed
> as a (struct va_format *) argument, and sure, the callee can take that
> arbitrary pointer and cast to the real type of that argument. But it
> seems you did that only to have _some_ random const char* parameter to
> attach that __printf attribute to.

True, and again, I felt that what I'm doing here is all not right.

> So, since the format string that va_format() passes to vsnprintf() is
> not one of va_format()'s own parameters, there is no parameter to attach
> that __printf() attribute to. So I actually consider this somewhat of a
> gcc bug. But can't we just silence that false positive with the tool
> that gcc provides for this very purpose:
> 
> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored "-Wsuggest-attribute=format"
> static char *va_format(char *buf, char *end, struct va_format *va_fmt,
> ...
> }
> #pragma GCC diagnostic pop
> 
> with whatever added sauce to also make it work for clang.

clang doesn't produce this warning to me. But I will check again.

> Then you don't need to annotate pointer(),

Sure, I also felt that that one is hack to satisfy a broken tool.

> and then you don't need to annotate the BINARY_PRINTF users of pointer(),
> though I think those two do make sense.

I prefer to have them marked as they really like printf():s.

Thanks for the suggestion, I will experiment and send the result in v2.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2025-03-21 14:17 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-20 18:04 [PATCH v1 0/6] vsprintf: Add __printf attribute to where it's required Andy Shevchenko
2025-03-20 18:04 ` [PATCH v1 1/6] seq_buf: Mark binary printing functions with __printf() attribute Andy Shevchenko
2025-03-24 16:04   ` Steven Rostedt
2025-03-24 16:08     ` Andy Shevchenko
2025-03-24 16:17     ` Andy Shevchenko
2025-03-20 18:04 ` [PATCH v1 2/6] seq_file: " Andy Shevchenko
2025-03-20 18:04 ` [PATCH v1 3/6] tracing: " Andy Shevchenko
2025-03-21 14:09   ` Andy Shevchenko
2025-03-24 16:02   ` Steven Rostedt
2025-03-24 16:11     ` Andy Shevchenko
2025-03-20 18:04 ` [PATCH v1 4/6] vsnprintf: " Andy Shevchenko
2025-03-20 18:04 ` [PATCH v1 5/6] vsnprintf: Mark pointer() " Andy Shevchenko
2025-03-21 13:43   ` Rasmus Villemoes
2025-03-21 13:52     ` Andy Shevchenko
2025-03-20 18:04 ` [PATCH v1 6/6] vsnprintf: Mark va_format() " Andy Shevchenko
2025-03-21 14:09   ` Rasmus Villemoes
2025-03-21 14:16     ` Andy Shevchenko [this message]
2025-03-20 18:32 ` [PATCH v1 0/6] vsprintf: Add __printf attribute to where it's required Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z9102aHbXlVS50Cq@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=john.ogness@linutronix.de \
    --cc=kees@kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=pmladek@suse.com \
    --cc=ravi@prevas.dk \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.