(Is this the right place for iproute2 bug reports?)
It appears that by default the gcc compiler for the i386 arch will pad
structures to the next multiple of 4 bytes.
But the gcc port for the Axis cris arch (gcc-cris) does not do this.
I've seen problems caused by this before and I was assured at that time
that it's not a compiler bug - either behavior is supposed to be
acceptable.
There are at least 2 places where iproute2 has problems because of this.
One is in xfrm_policy_print() (in ip/xfrm_policy.c). On the cris arch, I
see output like this:
# ip x p
!!!Deficit 3, rta_len=300
src 192.168.251.32/29 dst 192.168.251.32/29
dir in priority 0
!!!Deficit 3, rta_len=180
src 0.0.0.0/0 dst 192.168.251.32/29
dir in priority 2208
....
There are similar errors from 'ip x s', I'm guessing for much the same
reason - I'll investigate that shortly.
The policy print errors can be fixed by this patch (this is against
iproute2-2.6.16-060323):
# diff -u --show-c-function xfrm_policy.c~ xfrm_policy.c
--- xfrm_policy.c~ 2005-11-07 13:39:30.000000000 -0500
+++ xfrm_policy.c 2006-06-07 18:29:13.000000000 -0400
@@ -362,7 +362,7 @@ int xfrm_policy_print(const struct socka
} else {
xpexp = NULL;
xpinfo = NLMSG_DATA(n);
- len -= NLMSG_LENGTH(sizeof(*xpinfo));
+ len -= NLMSG_LENGTH(NLMSG_ALIGN(sizeof(*xpinfo)));
}
if (len < 0) {
Here *xpinfo is a struct xfrm_userpolicy_info which is 161 bytes on
cris, 164 on i386. But the netlink message is 180 bytes in both cases
(including a 16 byte header), so len ends up as 3 instead of zero in the
cris case. That makes the while loop run again and try to process the
last 3 bytes. Forcing the alignment effectively discards the extra 3
bytes, which I think is correct here.
I can add much more detail as to what's happening if anyone is
interested - I started doing that but it gets quite involved! It took me
2 days to track this down, so far...
I have some concerns with the patch though:
- Apart from the "!!!Deficit 3" messages everything else *appears* to
be working OK here. But I wonder if some sort of audit is needed to see
if there are other places that reference this struct (or other unaligned
ones) that may cause other problems later?
- The policy that's being printed here was acquired from the kernel
through netlink. But in the netlink message the struct is apparently
padded (making the netlink message 3 bytes too long, which causes the
Deficit errors). Curious, because the same compiler is used to build the
kernel. So is the kernel doing the correct thing here?
Anyways, I'll look into the ip x s errors next...
Please cc me on any reply, I'm not subscribed to linux-net.
Thanks -
Andy
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
