[PATCH] netfilter: conntrack: fix -Wformat

[Nick Desaulniers]

Clang is more aggressive about -Wformat warnings when the format flag
specifies a type smaller than the parameter. Fixes 8 instances of:

warning: format specifies type 'unsigned short' but the argument has
type 'int' [-Wformat]

Link: https://github.com/ClangBuiltLinux/linux/issues/378
Signed-off-by: Nick Desaulniers <ndesau...@google.com>
---
net/netfilter/nf_conntrack_standalone.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/net/netfilter/nf_conntrack_standalone.c b/net/netfilter/nf_conntrack_standalone.c
index 46c5557c1fec..c5aa45c38eb2 100644
--- a/net/netfilter/nf_conntrack_standalone.c
+++ b/net/netfilter/nf_conntrack_standalone.c
@@ -50,38 +50,38 @@ print_tuple(struct seq_file *s, const struct nf_conntrack_tuple *tuple,

switch (l4proto->l4proto) {
case IPPROTO_ICMP:
- seq_printf(s, "type=%u code=%u id=%u ",
+ seq_printf(s, "type=%u code=%u id=%hu ",
tuple->dst.u.icmp.type,
tuple->dst.u.icmp.code,
- ntohs(tuple->src.u.icmp.id));
+ (__be16)ntohs(tuple->src.u.icmp.id));
break;
case IPPROTO_TCP:
seq_printf(s, "sport=%hu dport=%hu ",
- ntohs(tuple->src.u.tcp.port),
- ntohs(tuple->dst.u.tcp.port));
+ (__be16)ntohs(tuple->src.u.tcp.port),
+ (__be16)ntohs(tuple->dst.u.tcp.port));
break;
case IPPROTO_UDPLITE:
case IPPROTO_UDP:
seq_printf(s, "sport=%hu dport=%hu ",
- ntohs(tuple->src.u.udp.port),
- ntohs(tuple->dst.u.udp.port));
+ (__be16)ntohs(tuple->src.u.udp.port),
+ (__be16)ntohs(tuple->dst.u.udp.port));

break;
case IPPROTO_DCCP:
seq_printf(s, "sport=%hu dport=%hu ",
- ntohs(tuple->src.u.dccp.port),
- ntohs(tuple->dst.u.dccp.port));
+ (__be16)ntohs(tuple->src.u.dccp.port),
+ (__be16)ntohs(tuple->dst.u.dccp.port));
break;
case IPPROTO_SCTP:
seq_printf(s, "sport=%hu dport=%hu ",
- ntohs(tuple->src.u.sctp.port),
- ntohs(tuple->dst.u.sctp.port));
+ (__be16)ntohs(tuple->src.u.sctp.port),
+ (__be16)ntohs(tuple->dst.u.sctp.port));
break;
case IPPROTO_ICMPV6:
- seq_printf(s, "type=%u code=%u id=%u ",
+ seq_printf(s, "type=%u code=%u id=%hu ",
tuple->dst.u.icmp.type,
tuple->dst.u.icmp.code,
- ntohs(tuple->src.u.icmp.id));
+ (__be16)ntohs(tuple->src.u.icmp.id));
break;
case IPPROTO_GRE:
seq_printf(s, "srckey=0x%x dstkey=0x%x ",
--
2.29.2.222.g5d2a92d10f8-goog

[Joe Perches]

On Fri, 2020-11-06 at 23:55 -0800, Nick Desaulniers wrote:
> Clang is more aggressive about -Wformat warnings when the format flag
> specifies a type smaller than the parameter. Fixes 8 instances of:
>
> warning: format specifies type 'unsigned short' but the argument has
> type 'int' [-Wformat]

Likely clang's -Wformat message is still bogus.
Wasn't that going to be fixed?

Integer promotions are already done on these types to int anyway.
Didn't we have this discussion last year?

https://lore.kernel.org/lkml/CAKwvOd=mqzj2pAZEUsW-M_62xn4pijpCJmP=B1h_-wE...@mail.gmail.com/
https://lore.kernel.org/lkml/CAHk-=wgoxnmsj8GEVFJSvTwdnWm8wVJthefNk2n6+4TC=20...@mail.gmail.com/
https://lore.kernel.org/lkml/a68114afb134b8633905f5a...@perches.com/

Look at commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use
of unnecessary %h[xudi] and %hh[xudi]")

The "h" and "hh" things should never be used. The only reason for them
being used if if you have an "int", but you want to print it out as a
"char" (and honestly, that is a really bad reason, you'd be better off
just using a proper cast to make the code more obvious).

So if what you have a "char" (or unsigned char) you should always just
print it out as an "int", knowing that the compiler already did the
proper type conversion.

> diff --git a/net/netfilter/nf_conntrack_standalone.c b/net/netfilter/nf_conntrack_standalone.c

[]
> @@ -50,38 +50,38 @@ print_tuple(struct seq_file *s, const struct nf_conntrack_tuple *tuple,
>  
>
>   switch (l4proto->l4proto) {
>   case IPPROTO_ICMP:
> - seq_printf(s, "type=%u code=%u id=%u ",
> + seq_printf(s, "type=%u code=%u id=%hu ",

etc...

[Jakub Kicinski]

On Fri, 6 Nov 2020 23:55:50 -0800 Nick Desaulniers wrote:
> - ntohs(tuple->src.u.icmp.id));
> + (__be16)ntohs(tuple->src.u.icmp.id));

Joe has a point, besides __be16 clearly is not the right type here,
the result of ntohs is in host order.

[Lukas Bulwahn]

On Sat, 7 Nov 2020, Joe Perches wrote:

> On Fri, 2020-11-06 at 23:55 -0800, Nick Desaulniers wrote:
> > Clang is more aggressive about -Wformat warnings when the format flag
> > specifies a type smaller than the parameter. Fixes 8 instances of:
> >
> > warning: format specifies type 'unsigned short' but the argument has
> > type 'int' [-Wformat]
>
> Likely clang's -Wformat message is still bogus.
> Wasn't that going to be fixed?
>
> Integer promotions are already done on these types to int anyway.
> Didn't we have this discussion last year?
>
> https://lore.kernel.org/lkml/CAKwvOd=mqzj2pAZEUsW-M_62xn4pijpCJmP=B1h_-wE...@mail.gmail.com/
> https://lore.kernel.org/lkml/CAHk-=wgoxnmsj8GEVFJSvTwdnWm8wVJthefNk2n6+4TC=20...@mail.gmail.com/
> https://lore.kernel.org/lkml/a68114afb134b8633905f5a...@perches.com/
>
> Look at commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use
> of unnecessary %h[xudi] and %hh[xudi]")
>
> The "h" and "hh" things should never be used. The only reason for them
> being used if if you have an "int", but you want to print it out as a
> "char" (and honestly, that is a really bad reason, you'd be better off
> just using a proper cast to make the code more obvious).
>

Joe, would this be a good rule to check for in checkpatch?

Can Dwaipayan or Aditya give it a try to create a suitable patch to add
such a rule?

Dwaipayan, Aditya, if Joe thinks it is worth a rule, it is "first come,
first serve" for you to take that task.

Lukas

> So if what you have a "char" (or unsigned char) you should always just
> print it out as an "int", knowing that the compiler already did the
> proper type conversion.
>
> > diff --git a/net/netfilter/nf_conntrack_standalone.c b/net/netfilter/nf_conntrack_standalone.c
> []
> > @@ -50,38 +50,38 @@ print_tuple(struct seq_file *s, const struct nf_conntrack_tuple *tuple,
> >  
> >
> >   switch (l4proto->l4proto) {
> >   case IPPROTO_ICMP:
> > - seq_printf(s, "type=%u code=%u id=%u ",
> > + seq_printf(s, "type=%u code=%u id=%hu ",
>
> etc...
>
>

> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-li...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/4910042649a4f3ab22fac93191b8c1fa0a2e17c3.camel%40perches.com.
>

[Joe Perches]

On Sun, 2020-11-08 at 08:34 +0100, Lukas Bulwahn wrote:
> On Sat, 7 Nov 2020, Joe Perches wrote:
> > On Fri, 2020-11-06 at 23:55 -0800, Nick Desaulniers wrote:
> > > Clang is more aggressive about -Wformat warnings when the format flag
> > > specifies a type smaller than the parameter. Fixes 8 instances of:
> > >
> > > warning: format specifies type 'unsigned short' but the argument has
> > > type 'int' [-Wformat]
> >
> > Likely clang's -Wformat message is still bogus.
> > Wasn't that going to be fixed?
> >
> > Integer promotions are already done on these types to int anyway.
> > Didn't we have this discussion last year?
> >
> > https://lore.kernel.org/lkml/CAKwvOd=mqzj2pAZEUsW-M_62xn4pijpCJmP=B1h_-wE...@mail.gmail.com/
> > https://lore.kernel.org/lkml/CAHk-=wgoxnmsj8GEVFJSvTwdnWm8wVJthefNk2n6+4TC=20...@mail.gmail.com/
> > https://lore.kernel.org/lkml/a68114afb134b8633905f5a...@perches.com/
> >
> > Look at commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use
> > of unnecessary %h[xudi] and %hh[xudi]")
> >
> > The "h" and "hh" things should never be used. The only reason for them
> > being used if if you have an "int", but you want to print it out as a
> > "char" (and honestly, that is a really bad reason, you'd be better off
> > just using a proper cast to make the code more obvious).
> >
> Joe, would this be a good rule to check for in checkpatch?
>
> Can Dwaipayan or Aditya give it a try to create a suitable patch to add
> such a rule?

$ git grep -P '"[^"]*%[\d\.\*\-]*h+[idux].*"'

I suppose so.
Please avoid warning on scanf and its variants and the asm bits though.

[Nick Desaulniers]

On Sat, Nov 7, 2020 at 2:33 AM Joe Perches <j...@perches.com> wrote:
>
> On Fri, 2020-11-06 at 23:55 -0800, Nick Desaulniers wrote:
> > Clang is more aggressive about -Wformat warnings when the format flag
> > specifies a type smaller than the parameter. Fixes 8 instances of:
> >
> > warning: format specifies type 'unsigned short' but the argument has
> > type 'int' [-Wformat]
>
> Likely clang's -Wformat message is still bogus.
> Wasn't that going to be fixed?
>
> Integer promotions are already done on these types to int anyway.
> Didn't we have this discussion last year?
>
> https://lore.kernel.org/lkml/CAKwvOd=mqzj2pAZEUsW-M_62xn4pijpCJmP=B1h_-wE...@mail.gmail.com/
> https://lore.kernel.org/lkml/CAHk-=wgoxnmsj8GEVFJSvTwdnWm8wVJthefNk2n6+4TC=20...@mail.gmail.com/
> https://lore.kernel.org/lkml/a68114afb134b8633905f5a...@perches.com/

Now I'll have to page in some old context...

The case we addressed last year was printing char with a wider format
string like %hd: https://reviews.llvm.org/rL369791,
https://bugs.llvm.org/show_bug.cgi?id=41467 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95588 have a little more
info but not much. Which is the case that Linus commented on. Let's
say we're printing a "wider format than intended." Those have been
fixed in Clang. These cases are printing a "narrower format than
intended." Two distinct cases.

>
> Look at commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use
> of unnecessary %h[xudi] and %hh[xudi]")
>
> The "h" and "hh" things should never be used. The only reason for them
> being used if if you have an "int", but you want to print it out as a
> "char" (and honestly, that is a really bad reason, you'd be better off
> just using a proper cast to make the code more obvious).
>
> So if what you have a "char" (or unsigned char) you should always just
> print it out as an "int", knowing that the compiler already did the
> proper type conversion.

Yeah, we could go through and remove %h and %hh to solve this, too, right?
--
Thanks,
~Nick Desaulniers

[Joe Perches]

On Tue, 2020-11-10 at 14:00 -0800, Nick Desaulniers wrote:

> Yeah, we could go through and remove %h and %hh to solve this, too, right?

Yup.

I think one of the checkpatch improvement mentees is adding
some suggestion and I hope an automated fix mechanism for that.

https://lore.kernel.org/lkml/5e3265c241602bb54286fba...@perches.com/

[Nick Desaulniers]

SGTM, please try to remember to CC me (or CBL) if you do any such
treewide change so that I can remove -Wno-format from
scripts/Makefile.extrawarn for Clang afterwards, and maybe help review
it, too.
--
Thanks,
~Nick Desaulniers

[Nick Desaulniers]

On Tue, Nov 10, 2020 at 2:04 PM Joe Perches <j...@perches.com> wrote:
>

+ Tom, who's been looking at leveraging clang-tidy to automate such
treewide mechanical changes.
ex. https://reviews.llvm.org/D91789

See also commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging
use of unnecessary %h[xudi] and %hh[xudi]") for a concise summary of
related context.
--
Thanks,
~Nick Desaulniers

[Tom Rix]

On 12/2/20 2:34 PM, Nick Desaulniers wrote:
> On Tue, Nov 10, 2020 at 2:04 PM Joe Perches <j...@perches.com> wrote:
>> On Tue, 2020-11-10 at 14:00 -0800, Nick Desaulniers wrote:
>>
>>> Yeah, we could go through and remove %h and %hh to solve this, too, right?
>> Yup.
>>
>> I think one of the checkpatch improvement mentees is adding
>> some suggestion and I hope an automated fix mechanism for that.
>>
>> https://lore.kernel.org/lkml/5e3265c241602bb54286fba...@perches.com/
> + Tom, who's been looking at leveraging clang-tidy to automate such
> treewide mechanical changes.
> ex. https://reviews.llvm.org/D91789

This looks like a good one to automate.

If you don't mind, I'll give it a try next.

Need a break from semicolons ;)

Tom

[Lukas Bulwahn]

Nick, Tom,

It is not a competition between checkpatch and clang-format, but if it would be:

...checkpatch was first...

But jokes aside: Dwaipayan Ray, a mentee Joe and I are working with,
has already submitted a patch to checkpatch that identifies those
patterns and provides a fix:

https://lore.kernel.org/lkml/20201128200046.787...@gmail.com/

Maybe that is helpful; and of course, clean-up patches to the various
places still need to be sent out and having a second tool with
clang-format that can check and provide automatic fixes as well is
great.

Tom, go for it: that clean-up is certainly helpful to get a "make
CC=clang -W1" warning-free kernel build. For some smaller x86 kernel
config (my playground config), there were not too many warnings
outstanding, but the -Wformat was still among the larger class among
them.

Lukas

[Miguel Ojeda]

On Thu, Dec 3, 2020 at 8:26 AM Lukas Bulwahn <lukas....@gmail.com> wrote:
>
> It is not a competition between checkpatch and clang-format, but if it would be:

Please note that clang-tidy is a different tool, it is designed to
write lints based on the AST rather than formatting.

> But jokes aside: Dwaipayan Ray, a mentee Joe and I are working with,
> has already submitted a patch to checkpatch that identifies those
> patterns and provides a fix:
>
> https://lore.kernel.org/lkml/20201128200046.787...@gmail.com/

That is very good! However, it does not hurt to have it repeated in
clang-tidy too: it is a very good thing to have a full C parser behind
when writing lints!

Cheers,
Miguel

[Tom Rix]

i see 17k for -Wformat-pedantic, beating out -Wextra-semi-stmt by a hefty 8k on my allyesconfig

Yes, enabling new warnings is one of the things i am chasing.


I agree if it can be done in checkpatch it should.

It is good to have multiple passes on cleaning.

checkpatch is best at fixing new problems, clang-tidy-fix is best at fixing old problems.

Tom

> Lukas
>

[Lukas Bulwahn]

Completely agree. A regular expression is only a limited (but quite
powerful) heuristics to a full C parser :)

... and it did a good job in the case here.

Lukas

> Cheers,
> Miguel

[Joe Perches]

On Thu, 2020-12-03 at 06:39 -0800, Tom Rix wrote:
> I agree if it can be done in checkpatch it should.
> It is good to have multiple passes on cleaning.

true

> checkpatch is best at fixing new problems,
> clang-tidy-fix is best at fixing old problems.

checkpatch is a set of brainless regexes that operates on
incomplete information. It's not a real parser nor compiler.

It's really only useful as a way to avoid trivial style issues.

[Tom Rix]

On 12/2/20 2:34 PM, Nick Desaulniers wrote:

I have posted the fixer here

https://reviews.llvm.org/D93182

It catches about 200 problems in 100 files, I'll be posting these soon.

clang-tidy-fix's big difference over checkpatch is using the __printf(x,y) attribute to find the log functions.

I will be doing a follow-on to add the missing __printf or __scanf's and rerunning the fixer.

Tom

[Joe Perches]

On Sun, 2020-12-13 at 11:21 -0800, Tom Rix wrote:
> On 12/2/20 2:34 PM, Nick Desaulniers wrote:
> > On Tue, Nov 10, 2020 at 2:04 PM Joe Perches <j...@perches.com> wrote:
> > > On Tue, 2020-11-10 at 14:00 -0800, Nick Desaulniers wrote:
> > >
> > > > Yeah, we could go through and remove %h and %hh to solve this, too, right?
> > > Yup.
> > >
> > > I think one of the checkpatch improvement mentees is adding
> > > some suggestion and I hope an automated fix mechanism for that.
> > >
> > > https://lore.kernel.org/lkml/5e3265c241602bb54286fba...@perches.com/
> > + Tom, who's been looking at leveraging clang-tidy to automate such
> > treewide mechanical changes.
> > ex. https://reviews.llvm.org/D91789
> >
> > See also commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging
> > use of unnecessary %h[xudi] and %hh[xudi]") for a concise summary of
> > related context.
>
> I have posted the fixer here
>
> https://reviews.llvm.org/D93182
>
> It catches about 200 problems in 100 files, I'll be posting these soon.

Thanks, but see below:

> clang-tidy-fix's big difference over checkpatch is using the __printf(x,y) attribute to find the log functions.
>
> I will be doing a follow-on to add the missing __printf or __scanf's and rerunning the fixer.

scanf should not be tested because the %h use is required there.

[Tom Rix]

Yes.

I mean the clang-tidy check i am planning on writing will find missing __scanf as well as the __printf.

The %h fixer only works on __printf.

Tom

>
>