From: Bill Wendling
> Sent: 09 June 2022 23:49
> 
> On Thu, Jun 9, 2022 at 3:25 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Thu,  9 Jun 2022 22:16:19 +0000 Bill Wendling <morbo@google.com> wrote:
> >
> > > This patch set fixes some clang warnings when -Wformat is enabled.
> > >
> >
> > tldr:
> >
> > -       printk(msg);
> > +       printk("%s", msg);
> >
> > the only reason to make this change is where `msg' could contain a `%'.
> > Generally, it came from userspace.
> 
> It helps kernel developers not accidentally to insert an unescaped '%'
> in their messages, potentially exposing their code to an attack
> vector.
> 
> > Otherwise these changes are a
> > useless consumer of runtime resources.
> 
> Calling a "printf" style function is already insanely expensive. :-) I
> understand that it's not okay blithely to increase runtime resources
> simply because it's already slow, but in this case it's worthwhile.

Yep, IMHO definitely should be fixed.
It is even possible that using "%s" is faster because the printf
code doesn't have to scan the string for format effectors.

> > I think it would be better to quieten clang in some fashion.
> 
> The "printk" and similar functions all have the "__printf" attribute.
> I don't know of a modification to that attribute which can turn off
> this type of check.

And you wouldn't want to for these cases.

The only problems arise when the format is calculated
(or passed in from a caller).
But that is likely to be dangerous - reading formats from
files (eg for language translation) isn't a good idea at all.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

On Friday 2022-06-10 10:17, David Laight wrote:
>> 
>> Calling a "printf" style function is already insanely expensive. :-) I
>> understand that it's not okay blithely to increase runtime resources
>> simply because it's already slow, but in this case it's worthwhile.
>
>Yep, IMHO definitely should be fixed.
>It is even possible that using "%s" is faster because the printf
>code doesn't have to scan the string for format effectors.

I see no special handling; the vsnprintf function just loops
over fmt as usual and I see no special casing of fmt by
e.g. strcmp(fmt, "%s") == 0 to take a shortcut.

From: Jan Engelhardt
> Sent: 10 June 2022 09:32
> 
> 
> On Friday 2022-06-10 10:17, David Laight wrote:
> >>
> >> Calling a "printf" style function is already insanely expensive. :-) I
> >> understand that it's not okay blithely to increase runtime resources
> >> simply because it's already slow, but in this case it's worthwhile.
> >
> >Yep, IMHO definitely should be fixed.
> >It is even possible that using "%s" is faster because the printf
> >code doesn't have to scan the string for format effectors.
> 
> I see no special handling; the vsnprintf function just loops
> over fmt as usual and I see no special casing of fmt by
> e.g. strcmp(fmt, "%s") == 0 to take a shortcut.

Consider the difference between:
	printf("fubar");
and
	printf("%s", "fubar");
In the former all of "fubar" is checked for '%'.
In the latter only the length of "fubar" has to be counted.

FWIW the patch description should probably by:
	use "%s" when formatting a single string.
(or something to that effect).

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

On Friday 2022-06-10 11:14, David Laight wrote:
>> >Yep, IMHO definitely should be fixed.
>> >It is even possible that using "%s" is faster because the printf
>> >code doesn't have to scan the string for format effectors.
>> 
>> I see no special handling; the vsnprintf function just loops
>> over fmt as usual and I see no special casing of fmt by
>> e.g. strcmp(fmt, "%s") == 0 to take a shortcut.
>
>Consider the difference between:
>	printf("fubar");
>and
>	printf("%s", "fubar");
>In the former all of "fubar" is checked for '%'.
>In the latter only the length of "fubar" has to be counted.

To check the length of "fubar", printf first needs to know that there
even is an argument to be pulled from the stack, which it does by
evaluating the format string.

So, in fairness, it's more like:

 >> In the latter, all of "%s" is checked for '%'.