LARTC - Mar 2005 - Adding dsmark qdisc fails

I''m trying to configure dsmark qdisc on 2.6.11.4 user mode linux and
tc from iproute2-2.6.11-050314.

I think I have some mismatch in my setup since adding dsmark qdisc
fails *unless* I specify "set_tc_index" argument which I believe
should
be optional:

# tc qdisc add dev eth1 handle 1:0 root dsmark indices 8
RTNETLINK answers: Invalid argument
Mar 20 13:00:50 user user.debug kernel: dsmark_init(sch a0bb3ae0,[qdisc 
a0bb3b60],opt 00000000)

here the log shows that opt is null, sch_dsmark checks for that and
bails out.  However running tc with "set_tc_index" goes ok:

# tc qdisc add dev eth1 handle 1:0 root dsmark indices 8 set_tc_index
Mar 20 13:01:12 user user.debug kernel: dsmark_init(sch a0bb3060,[qdisc 
a0bb30e0],opt a038e9d0)
Mar 20 13:01:12 user user.debug kernel: dsmark_init: qdisc a0bb30e0

# tc qdisc show dev eth1
qdisc dsmark 1: indices 0x0008 set_tc_index


but then changing the class fails:

# tc class change dev eth1 classid 1:1 dsmark mask 0x0 value 0xb8
RTNETLINK answers: Invalid argument
Mar 20 13:02:28 user user.debug kernel: dsmark_get(sch a0bb3060,[qdisc 
a0bb30e0],classid 10001)
Mar 20 13:02:28 user user.debug kernel: dsmark_change(sch a0bb3060,[qdisc 
a0bb30e0],classid 10001,parent 0),arg 0x2


Any ideas where I''ve gone wrong?

--
Tero

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it''s
FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Tero Saarni wrote:
> I''m trying to configure dsmark qdisc on 2.6.11.4 user mode linux
and
> tc from iproute2-2.6.11-050314.
> 
> I think I have some mismatch in my setup since adding dsmark qdisc
> fails *unless* I specify "set_tc_index" argument which I believe
should
> be optional:
> 
> # tc qdisc add dev eth1 handle 1:0 root dsmark indices 8
> RTNETLINK answers: Invalid argument
> Mar 20 13:00:50 user user.debug kernel: dsmark_init(sch a0bb3ae0,[qdisc 
> a0bb3b60],opt 00000000)
> 
> here the log shows that opt is null, sch_dsmark checks for that and
> bails out.  However running tc with "set_tc_index" goes ok:
> 
> # tc qdisc add dev eth1 handle 1:0 root dsmark indices 8 set_tc_index
> Mar 20 13:01:12 user user.debug kernel: dsmark_init(sch a0bb3060,[qdisc 
> a0bb30e0],opt a038e9d0)
> Mar 20 13:01:12 user user.debug kernel: dsmark_init: qdisc a0bb30e0
> 
> # tc qdisc show dev eth1
> qdisc dsmark 1: indices 0x0008 set_tc_index
> 
> 
> but then changing the class fails:
> 
> # tc class change dev eth1 classid 1:1 dsmark mask 0x0 value 0xb8
> RTNETLINK answers: Invalid argument
> Mar 20 13:02:28 user user.debug kernel: dsmark_get(sch a0bb3060,[qdisc 
> a0bb30e0],classid 10001)
> Mar 20 13:02:28 user user.debug kernel: dsmark_change(sch 
> a0bb3060,[qdisc a0bb30e0],classid 10001,parent 0),arg 0x2
> 
> 
> Any ideas where I''ve gone wrong?
It is caused by this patch, the transformation to use NLMSG_TAIL is
not equivalent (it calculates the size of the aligned message). This
makes parsing the attributes in rtnetlink_rcv_msg() fail. I haven''t 
checked what the exact problem is, Thomas, can you have a look at this
please?

Regards
Patrick


_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

* Patrick McHardy <423D9398.8050907@trash.net> 2005-03-20
16:15
> ># tc qdisc add dev eth1 handle 1:0 root dsmark indices 8
> >RTNETLINK answers: Invalid argument
> >Mar 20 13:00:50 user user.debug kernel: dsmark_init(sch a0bb3ae0,[qdisc
> >a0bb3b60],opt 00000000)
> >
> It is caused by this patch, the transformation to use NLMSG_TAIL is
> not equivalent (it calculates the size of the aligned message). This
> makes parsing the attributes in rtnetlink_rcv_msg() fail. I
haven''t
> checked what the exact problem is, Thomas, can you have a look at this
> please?
My patch is right but discovered a quite more serious bug in the
generic routing attribute handling. nlmsg_len is not aligned to
RTA_ALIGNTO if the data length of the attribute did not have
this alignment itself. The fact that the addition of the next attribute
fixed this bug automatically by issueing NLMSG_ALIGN(nlmsg_len) + len
put a good shadow around it and made it only a problem when the last
attribute added was not properly aligned. Patch attached, alternatively
one can clone bk://kernel.bkbits.net/tgraf/iproute2-tgr and als get
the new fancy multipath bits installed. ;->

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/03/20 17:19:39+01:00 tgraf@suug.ch 
#   Fix netlink message alignment when the last routing attribute added
#   has a data length not aligned to RTA_ALIGNTO.
# 
# lib/libnetlink.c
#   2005/03/20 17:19:38+01:00 tgraf@suug.ch +4 -4
#   Fix netlink message alignment when the last routing attribute added
#   has a data length not aligned to RTA_ALIGNTO.
# 
diff -Nru a/lib/libnetlink.c b/lib/libnetlink.c
--- a/lib/libnetlink.c	2005-03-20 17:19:53 +01:00
+++ b/lib/libnetlink.c	2005-03-20 17:19:53 +01:00
@@ -491,7 +491,7 @@
 	int len = RTA_LENGTH(alen);
 	struct rtattr *rta;
 
-	if (NLMSG_ALIGN(n->nlmsg_len) + len > maxlen) {
+	if (NLMSG_ALIGN(n->nlmsg_len) + RTA_ALIGN(len) > maxlen) {
 		fprintf(stderr, "addattr_l ERROR: message exceeded bound of
%d\n",maxlen);
 		return -1;
 	}
@@ -499,7 +499,7 @@
 	rta->rta_type = type;
 	rta->rta_len = len;
 	memcpy(RTA_DATA(rta), data, alen);
-	n->nlmsg_len = NLMSG_ALIGN(n->nlmsg_len) + len;
+	n->nlmsg_len = NLMSG_ALIGN(n->nlmsg_len) + RTA_ALIGN(len);
 	return 0;
 }
 
@@ -539,7 +539,7 @@
 	struct rtattr *subrta;
 	int len = RTA_LENGTH(alen);
 
-	if (RTA_ALIGN(rta->rta_len) + len > maxlen) {
+	if (RTA_ALIGN(rta->rta_len) + RTA_ALIGN(len) > maxlen) {
 		fprintf(stderr,"rta_addattr_l: Error! max allowed bound %d
exceeded\n",maxlen);
 		return -1;
 	}
@@ -547,7 +547,7 @@
 	subrta->rta_type = type;
 	subrta->rta_len = len;
 	memcpy(RTA_DATA(subrta), data, alen);
-	rta->rta_len = NLMSG_ALIGN(rta->rta_len) + len;
+	rta->rta_len = NLMSG_ALIGN(rta->rta_len) + RTA_ALIGN(len);
 	return 0;
 }

>From: Thomas Graf <tgraf@suug.ch>
>My patch is right but discovered a quite more serious bug in the
>generic routing attribute handling. nlmsg_len is not aligned to
>RTA_ALIGNTO if the data length of the attribute did not have
>this alignment itself. The fact that the addition of the next attribute
>fixed this bug automatically by issueing NLMSG_ALIGN(nlmsg_len) + len
>put a good shadow around it and made it only a problem when the last
>attribute added was not properly aligned. Patch attached, alternatively
>one can clone bk://kernel.bkbits.net/tgraf/iproute2-tgr and als get
>the new fancy multipath bits installed. ;->
Thanks!
That fixed it.

--
Tero

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/