[PATCH] netfilter: conntrack: fix -Wformat

[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 <ndesaulniers@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

Re: [PATCH] netfilter: conntrack: fix -Wformat

[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_-wEb0NeZsA@mail.gmail.com/
https://lore.kernel.org/lkml/CAHk-=wgoxnmsj8GEVFJSvTwdnWm8wVJthefNk2n6+4TC=20e0Q@mail.gmail.com/
https://lore.kernel.org/lkml/a68114afb134b8633905f5a25ae7c4e6799ce8f1.camel@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...

Re: [PATCH] netfilter: conntrack: fix -Wformat

[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.

Re: [PATCH] netfilter: conntrack: fix -Wformat

[Lukas Bulwahn]

[-- Attachment #1: Type: text/plain, Size: 2476 bytes --]



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_-wEb0NeZsA@mail.gmail.com/
> https://lore.kernel.org/lkml/CAHk-=wgoxnmsj8GEVFJSvTwdnWm8wVJthefNk2n6+4TC=20e0Q@mail.gmail.com/
> https://lore.kernel.org/lkml/a68114afb134b8633905f5a25ae7c4e6799ce8f1.camel@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-linux+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/4910042649a4f3ab22fac93191b8c1fa0a2e17c3.camel%40perches.com.
> 

Re: [PATCH] netfilter: conntrack: fix -Wformat

[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_-wEb0NeZsA@mail.gmail.com/
> > https://lore.kernel.org/lkml/CAHk-=wgoxnmsj8GEVFJSvTwdnWm8wVJthefNk2n6+4TC=20e0Q@mail.gmail.com/
> > https://lore.kernel.org/lkml/a68114afb134b8633905f5a25ae7c4e6799ce8f1.camel@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.

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

Re: [PATCH] netfilter: conntrack: fix -Wformat

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 4796 bytes --]

Hi Nick,

I love your patch! Perhaps something to improve:

[auto build test WARNING on nf-next/master]
[also build test WARNING on nf/master ipvs/master v5.10-rc3 next-20201109]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Nick-Desaulniers/netfilter-conntrack-fix-Wformat/20201109-085104
base:   https://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git master
config: riscv-randconfig-s031-20201109 (attached as .config)
compiler: riscv32-linux-gcc (GCC) 9.3.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # apt-get install sparse
        # sparse version: v0.6.3-76-gf680124b-dirty
        # https://github.com/0day-ci/linux/commit/407a53117fa32f8f17a73a51bced0e85f168acb4
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Nick-Desaulniers/netfilter-conntrack-fix-Wformat/20201109-085104
        git checkout 407a53117fa32f8f17a73a51bced0e85f168acb4
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=riscv 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


"sparse warnings: (new ones prefixed by >>)"
>> net/netfilter/nf_conntrack_standalone.c:56:29: sparse: sparse: cast to restricted __be16
   net/netfilter/nf_conntrack_standalone.c:60:29: sparse: sparse: cast to restricted __be16
   net/netfilter/nf_conntrack_standalone.c:61:29: sparse: sparse: cast to restricted __be16
   net/netfilter/nf_conntrack_standalone.c:66:29: sparse: sparse: cast to restricted __be16
   net/netfilter/nf_conntrack_standalone.c:67:29: sparse: sparse: cast to restricted __be16
   net/netfilter/nf_conntrack_standalone.c:72:29: sparse: sparse: cast to restricted __be16
   net/netfilter/nf_conntrack_standalone.c:73:29: sparse: sparse: cast to restricted __be16
   net/netfilter/nf_conntrack_standalone.c:77:29: sparse: sparse: cast to restricted __be16
   net/netfilter/nf_conntrack_standalone.c:78:29: sparse: sparse: cast to restricted __be16
   net/netfilter/nf_conntrack_standalone.c:84:29: sparse: sparse: cast to restricted __be16

vim +56 net/netfilter/nf_conntrack_standalone.c

    32	
    33	#ifdef CONFIG_NF_CONNTRACK_PROCFS
    34	void
    35	print_tuple(struct seq_file *s, const struct nf_conntrack_tuple *tuple,
    36	            const struct nf_conntrack_l4proto *l4proto)
    37	{
    38		switch (tuple->src.l3num) {
    39		case NFPROTO_IPV4:
    40			seq_printf(s, "src=%pI4 dst=%pI4 ",
    41				   &tuple->src.u3.ip, &tuple->dst.u3.ip);
    42			break;
    43		case NFPROTO_IPV6:
    44			seq_printf(s, "src=%pI6 dst=%pI6 ",
    45				   tuple->src.u3.ip6, tuple->dst.u3.ip6);
    46			break;
    47		default:
    48			break;
    49		}
    50	
    51		switch (l4proto->l4proto) {
    52		case IPPROTO_ICMP:
    53			seq_printf(s, "type=%u code=%u id=%hu ",
    54				   tuple->dst.u.icmp.type,
    55				   tuple->dst.u.icmp.code,
  > 56				   (__be16)ntohs(tuple->src.u.icmp.id));
    57			break;
    58		case IPPROTO_TCP:
    59			seq_printf(s, "sport=%hu dport=%hu ",
    60				   (__be16)ntohs(tuple->src.u.tcp.port),
    61				   (__be16)ntohs(tuple->dst.u.tcp.port));
    62			break;
    63		case IPPROTO_UDPLITE:
    64		case IPPROTO_UDP:
    65			seq_printf(s, "sport=%hu dport=%hu ",
    66				   (__be16)ntohs(tuple->src.u.udp.port),
    67				   (__be16)ntohs(tuple->dst.u.udp.port));
    68	
    69			break;
    70		case IPPROTO_DCCP:
    71			seq_printf(s, "sport=%hu dport=%hu ",
    72				   (__be16)ntohs(tuple->src.u.dccp.port),
    73				   (__be16)ntohs(tuple->dst.u.dccp.port));
    74			break;
    75		case IPPROTO_SCTP:
    76			seq_printf(s, "sport=%hu dport=%hu ",
    77				   (__be16)ntohs(tuple->src.u.sctp.port),
    78				   (__be16)ntohs(tuple->dst.u.sctp.port));
    79			break;
    80		case IPPROTO_ICMPV6:
    81			seq_printf(s, "type=%u code=%u id=%hu ",
    82				   tuple->dst.u.icmp.type,
    83				   tuple->dst.u.icmp.code,
    84				   (__be16)ntohs(tuple->src.u.icmp.id));
    85			break;
    86		case IPPROTO_GRE:
    87			seq_printf(s, "srckey=0x%x dstkey=0x%x ",
    88				   ntohs(tuple->src.u.gre.key),
    89				   ntohs(tuple->dst.u.gre.key));
    90			break;
    91		default:
    92			break;
    93		}
    94	}
    95	EXPORT_SYMBOL_GPL(print_tuple);
    96	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 30080 bytes --]

Re: [PATCH] netfilter: conntrack: fix -Wformat

[Nick Desaulniers]

On Sat, Nov 7, 2020 at 2:33 AM Joe Perches <joe@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_-wEb0NeZsA@mail.gmail.com/
> https://lore.kernel.org/lkml/CAHk-=wgoxnmsj8GEVFJSvTwdnWm8wVJthefNk2n6+4TC=20e0Q@mail.gmail.com/
> https://lore.kernel.org/lkml/a68114afb134b8633905f5a25ae7c4e6799ce8f1.camel@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

Re: [PATCH] netfilter: conntrack: fix -Wformat

[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/5e3265c241602bb54286fbaae9222070daa4768e.camel@perches.com/

Re: [PATCH] netfilter: conntrack: fix -Wformat

[Nick Desaulniers]

On Tue, Nov 10, 2020 at 2:04 PM Joe Perches <joe@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/5e3265c241602bb54286fbaae9222070daa4768e.camel@perches.com/

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

Re: [PATCH] netfilter: conntrack: fix -Wformat

[Nick Desaulniers]

On Tue, Nov 10, 2020 at 2:04 PM Joe Perches <joe@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/5e3265c241602bb54286fbaae9222070daa4768e.camel@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.
-- 
Thanks,
~Nick Desaulniers

Re: [PATCH] netfilter: conntrack: fix -Wformat

[Tom Rix]

On 12/2/20 2:34 PM, Nick Desaulniers wrote:
> On Tue, Nov 10, 2020 at 2:04 PM Joe Perches <joe@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/5e3265c241602bb54286fbaae9222070daa4768e.camel@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

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

Re: [PATCH] netfilter: conntrack: fix -Wformat

[Lukas Bulwahn]

On Thu, Dec 3, 2020 at 1:46 AM Tom Rix <trix@redhat.com> wrote:
>
>
> On 12/2/20 2:34 PM, Nick Desaulniers wrote:
> > On Tue, Nov 10, 2020 at 2:04 PM Joe Perches <joe@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/5e3265c241602bb54286fbaae9222070daa4768e.camel@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
>
> >
> > See also commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging
> > use of unnecessary %h[xudi] and %hh[xudi]") for a concise summary of
> > related context.
>

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.78739-1-dwaipayanray1@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

Re: [PATCH] netfilter: conntrack: fix -Wformat

[Miguel Ojeda]

On Thu, Dec 3, 2020 at 8:26 AM Lukas Bulwahn <lukas.bulwahn@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.78739-1-dwaipayanray1@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

Re: [PATCH] netfilter: conntrack: fix -Wformat

[Tom Rix]

On 12/2/20 11:26 PM, Lukas Bulwahn wrote:
> On Thu, Dec 3, 2020 at 1:46 AM Tom Rix <trix@redhat.com> wrote:
>>
>> On 12/2/20 2:34 PM, Nick Desaulniers wrote:
>>> On Tue, Nov 10, 2020 at 2:04 PM Joe Perches <joe@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/5e3265c241602bb54286fbaae9222070daa4768e.camel@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
>>
>>> See also commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging
>>> use of unnecessary %h[xudi] and %hh[xudi]") for a concise summary of
>>> related context.
> 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.78739-1-dwaipayanray1@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.

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
>

Re: [PATCH] netfilter: conntrack: fix -Wformat

[Lukas Bulwahn]

On Thu, Dec 3, 2020 at 2:44 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Thu, Dec 3, 2020 at 8:26 AM Lukas Bulwahn <lukas.bulwahn@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.78739-1-dwaipayanray1@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!
>

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

Re: [PATCH] netfilter: conntrack: fix -Wformat

[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.

Re: [PATCH] netfilter: conntrack: fix -Wformat

[Tom Rix]

On 12/2/20 2:34 PM, Nick Desaulniers wrote:
> On Tue, Nov 10, 2020 at 2:04 PM Joe Perches <joe@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/5e3265c241602bb54286fbaae9222070daa4768e.camel@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.

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

Re: [PATCH] netfilter: conntrack: fix -Wformat

[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 <joe@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/5e3265c241602bb54286fbaae9222070daa4768e.camel@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.

Re: [PATCH] netfilter: conntrack: fix -Wformat

[Tom Rix]

On 12/13/20 3:25 PM, Joe Perches wrote:
> 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 <joe@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/5e3265c241602bb54286fbaae9222070daa4768e.camel@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.

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

>
>