diff mbox series

netfilter: conntrack: fix -Wformat

Message ID 20201107075550.2244055-1-ndesaulniers@google.com
State New
Headers show
Series netfilter: conntrack: fix -Wformat | expand

Commit Message

Nick Desaulniers Nov. 7, 2020, 7:55 a.m. UTC 
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(-)

-- 
2.29.2.222.g5d2a92d10f8-goog

Comments

Joe Perches Nov. 7, 2020, 10:32 a.m. UTC | #1 
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...
Jakub Kicinski Nov. 7, 2020, 5:52 p.m. UTC | #2 
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 Nov. 8, 2020, 7:34 a.m. UTC | #3 
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.

>
Joe Perches Nov. 8, 2020, 10:10 a.m. UTC | #4 
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.
kernel test robot Nov. 9, 2020, 3:43 p.m. UTC | #5 
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
Nick Desaulniers Nov. 10, 2020, 10 p.m. UTC | #6 
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
Joe Perches Nov. 10, 2020, 10:04 p.m. UTC | #7 
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/
Nick Desaulniers Nov. 10, 2020, 10:06 p.m. UTC | #8 
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
Nick Desaulniers Dec. 2, 2020, 10:34 p.m. UTC | #9 
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
Tom Rix Dec. 3, 2020, 12:46 a.m. UTC | #10 
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.
Tom Rix Dec. 13, 2020, 7:21 p.m. UTC | #11 
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
Joe Perches Dec. 13, 2020, 11:25 p.m. UTC | #12 
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.
Tom Rix Dec. 13, 2020, 11:29 p.m. UTC | #13 
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

>

>
diff mbox series

Patch

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 ",