| Message ID | 20201107075550.2244055-1-ndesaulniers@google.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | netfilter: conntrack: fix -Wformat | expand |
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...
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.
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. >
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.
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
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?
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/
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.
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.
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.
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
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.
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 --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 ",
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(-)