[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8808f8a3-ea1c-f91b-8288-cc4952086f04@gmail.com>
Date: Wed, 19 Sep 2018 09:57:10 -0700
From: David Ahern <dsahern@...il.com>
To: Florian Westphal <fw@...len.de>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: array bounds warning in xfrm_output_resume
On 6/18/18 11:10 AM, David Ahern wrote:
> Florian:
>
> I am seeing this warning:
>
> $ make O=kbuild/perf -j 24 -s
> In file included from /home/dsa/kernel-3.git/include/linux/kernel.h:10:0,
> from /home/dsa/kernel-3.git/include/linux/list.h:9,
> from /home/dsa/kernel-3.git/include/linux/module.h:9,
> from /home/dsa/kernel-3.git/net/xfrm/xfrm_output.c:13:
> /home/dsa/kernel-3.git/net/xfrm/xfrm_output.c: In function
> ‘xfrm_output_resume’:
> /home/dsa/kernel-3.git/include/linux/compiler.h:252:20: warning: array
> subscript is above array bounds [-Warray-bounds]
> __read_once_size(&(x), __u.__c, sizeof(x)); \
> ^~~~
> /home/dsa/kernel-3.git/include/linux/compiler.h:258:22: note: in
> expansion of macro ‘__READ_ONCE’
> #define READ_ONCE(x) __READ_ONCE(x, 1)
> ^~~~~~~~~~~
> /home/dsa/kernel-3.git/include/linux/rcupdate.h:350:48: note: in
> expansion of macro ‘READ_ONCE’
> typeof(*p) *________p1 = (typeof(*p) *__force)READ_ONCE(p); \
> ^~~~~~~~~
> /home/dsa/kernel-3.git/include/linux/rcupdate.h:487:2: note: in
> expansion of macro ‘__rcu_dereference_check’
> __rcu_dereference_check((p), (c) || rcu_read_lock_held(), __rcu)
> ^~~~~~~~~~~~~~~~~~~~~~~
> /home/dsa/kernel-3.git/include/linux/rcupdate.h:545:28: note: in
> expansion of macro ‘rcu_dereference_check’
> #define rcu_dereference(p) rcu_dereference_check(p, 0)
> ^~~~~~~~~~~~~~~~~~~~~
> /home/dsa/kernel-3.git/include/linux/netfilter.h:218:15: note: in
> expansion of macro ‘rcu_dereference’
> hook_head = rcu_dereference(net->nf.hooks_arp[hook]);
> ^~~~~~~~~~~~~~~
>
> Line in question is the nf_hook in xfrm_output_resume.
> NF_INET_POST_ROUTING = 4 which is greater than NF_ARP_NUMHOOKS = 3
>
> I believe ef57170bbfdd6 is the commit that introduced the warning
>
Hi Florian:
I am still seeing this. I realize the compiler is not understanding the
conditions properly, but it is a distraction every time I do a kernel
build on Debian Stretch having to filter the above noise from whether I
introduce another warning.
Powered by blists - more mailing lists