From: Andrew Gallatin <hidden> Date: 2012-11-30 21:51:45
On 11/30/12 16:02, kbuild test robot wrote:
tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: 1b4c44e6369dbbafd113f1e00b406f1eda5ab5b2
commit: 1b4c44e6369dbbafd113f1e00b406f1eda5ab5b2 [98/98] myri10ge: Add vlan rx for better GRO perf.
sparse warnings:
+ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1286:34: sparse: cast to restricted __be16
+ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1286:34: sparse: cast to restricted __be16
+ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1286:34: sparse: cast to restricted __be16
+ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1286:34: sparse: cast to restricted __be16
+ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1286:16: sparse: restricted __be16 degrades to integer
OK, maybe a dumb question again, but how do I get sparse to produce
the 'cast to restricted' warnings? I ran sparse before submission,
but it only showed the pre-existing, non "cast to restricted"
warnings, so I did not know I was introducing a new warning.
Do I need to use a different architecture? (I was using x86_64).
Also, the line it is warning about is this:
1b4c44e6 Andrew Gallatin 2012-11-30 @1286 veh->h_vlan_proto == ntohs(ETH_P_8021Q)) {
Which seems to be nearly identical to the usage in
if_vlan.h:__vlan_get_tag, which I was treating as canonical..
So I'm a bit confused as to how to fix it.
Thanks,
Drew
From: Stephen Hemminger <hidden> Date: 2012-11-30 21:55:09
On Fri, 30 Nov 2012 16:51:41 -0500
Andrew Gallatin [off-list ref] wrote:
On 11/30/12 16:02, kbuild test robot wrote:
quoted
tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: 1b4c44e6369dbbafd113f1e00b406f1eda5ab5b2
commit: 1b4c44e6369dbbafd113f1e00b406f1eda5ab5b2 [98/98] myri10ge: Add vlan rx for better GRO perf.
sparse warnings:
+ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1286:34: sparse: cast to restricted __be16
+ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1286:34: sparse: cast to restricted __be16
+ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1286:34: sparse: cast to restricted __be16
+ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1286:34: sparse: cast to restricted __be16
+ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1286:16: sparse: restricted __be16 degrades to integer
OK, maybe a dumb question again, but how do I get sparse to produce
the 'cast to restricted' warnings? I ran sparse before submission,
but it only showed the pre-existing, non "cast to restricted"
warnings, so I did not know I was introducing a new warning.
Do I need to use a different architecture? (I was using x86_64).
See Documentation/sparse.txt
The optional make variable CF can be used to pass arguments to sparse. The
build system passes -Wbitwise to sparse automatically. To perform endianness
checks, you may define __CHECK_ENDIAN__:
make C=2 CF="-D__CHECK_ENDIAN__"
These checks are disabled by default as they generate a host of warnings.
On Fri, Nov 30, 2012 at 04:51:41PM -0500, Andrew Gallatin wrote:
On 11/30/12 16:02, kbuild test robot wrote:
quoted
tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: 1b4c44e6369dbbafd113f1e00b406f1eda5ab5b2
commit: 1b4c44e6369dbbafd113f1e00b406f1eda5ab5b2 [98/98] myri10ge: Add vlan rx for better GRO perf.
sparse warnings:
+ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1286:34: sparse: cast to restricted __be16
+ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1286:34: sparse: cast to restricted __be16
+ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1286:34: sparse: cast to restricted __be16
+ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1286:34: sparse: cast to restricted __be16
+ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1286:16: sparse: restricted __be16 degrades to integer
OK, maybe a dumb question again, but how do I get sparse to produce
the 'cast to restricted' warnings?
[snip]
Also, the line it is warning about is this:
quoted
1b4c44e6 Andrew Gallatin 2012-11-30 @1286 veh->h_vlan_proto == ntohs(ETH_P_8021Q)) {
Which seems to be nearly identical to the usage in
if_vlan.h:__vlan_get_tag, which I was treating as canonical..
So I'm a bit confused as to how to fix it.
Andrew, here is the explanations from Christopher Li:
On Thu, Nov 29, 2012 at 09:58:58AM -0800, Christopher Li wrote:
On Wed, Nov 28, 2012 at 2:42 PM, Andrew Morton
[off-list ref] wrote:
quoted
On Wed, 28 Nov 2012 17:23:47 +0800
quoted
+ fs/hfsplus/xattr.c:363:23: sparse: cast to restricted __be32
I think it is likely cause by record_type get value assigned.
What you want here is have one variable for record_type store in back
end endian.
Then have a different variable to store the record_type in CPU endian.
It is bad idea to store both endian in the same variable. That is what sparse is
complaining right now.
The detail cause of the complain is that, record_type has type __be32 __u32.
After be32_to_cpu() it return __u32 type.
When you assign __u32 type to a __be32_u32, sparse find out it has
type mismatch,
so it will do implicitly up cast. Think about if you assign char
variable to int, the compiler
will need to insert a cast to do the sign extension. That case is
causing the error message
because __be32 can't be cased.
Any way, it seems sparse is doing what it suppose to do here. The suggested
way to fix the warning is give different variable for back end and
CPU. That should get rid
of the warning.
Chris
From: Andrew Gallatin <hidden> Date: 2012-11-30 22:19:09
Thanks guys.
In this case, it found a real typo (use of ntohs() rather than htons()).
If it would not have been for this tool making me stare at it, I never
would have seen this.
I need audit the rest of the warnings in the driver..
Sorry for the noise & thanks for this service!
Drew
From: Andrew Gallatin <hidden> Date: 2012-12-03 19:21:18
I think I have a handle on most of the pre-existing warnings. The
device responds to BAR reads/writes with big endian data, while
I think everything expects little endian. These will be easy
to fix. The warning I don't see a fix for is this:
drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1434:35: warning:
context imbalance in 'myri10ge_intr' - different lock contexts for basic
block
Which is apparently triggered by using __netif_tx_trylock().
Is there something I'm missing, or does sparse just not like
__netif_tx_trylock() because it divides spinlock acquisition and
release into 2 different functions?
Thanks,
Drew
From: Christopher Li <sparse@chrisli.org> Date: 2012-12-03 20:13:45
On Mon, Dec 3, 2012 at 11:21 AM, Andrew Gallatin [off-list ref] wrote:
drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1434:35: warning:
context imbalance in 'myri10ge_intr' - different lock contexts for basic
block
Which is apparently triggered by using __netif_tx_trylock().
Is there something I'm missing, or does sparse just not like
__netif_tx_trylock() because it divides spinlock acquisition and
release into 2 different functions?
Right. Sparse currently does not have cross function analyse.
It will complain if the lock is not balanced with lock split into
different functions.
Chris