netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@vyatta.com>
To: Dave Jones <davej@codemonkey.org.uk>
Cc: netdev@vger.kernel.org
Subject: Re: Fwd: [Bug 447812] New: Netlink messages from "tc"  to sch_netem module are not interpreted correctly
Date: Wed, 21 May 2008 15:10:21 -0700	[thread overview]
Message-ID: <20080521151021.3d47a3d8@extreme> (raw)
In-Reply-To: <20080521214523.GB22591@codemonkey.org.uk>

Something in the new netlink parsing made netem break. One other person
saw it and was working on fixing, but no definitive answer yet.

Begin forwarded message:

Date: Thu, 08 May 2008 17:59:24 -0700
From: Karl Auerbach 
To: Stephen Hemminger <shemminger@linux-foundation.org>
Subject: Re: Some netem issues with 2.6.25 kernel



I've dug even deeper into the issue of netem on the 2.6.25.x kernels.

(And I'm also attaching a cleaner version of my patch to q_netem.c for 
iproute2.2.6.25: I pulled out the gratuitous changes and left only the 
necessary ones to fix the bug in which uninitialized data was being sent 
across the netlink API, plus one teensy one to remove some whitespace.) 
  (I believe that there are still some remaining issues in the tc 
support of netem in which some correlation values, for instance, could 
be zeroed out, but I did not go after those.)

 From what I can see the larger problem with the netlink messages is 
happening on the kernel side of the boundary.

I used several old binary images of the 'tc' command, several of which I 
built but also ones "borrowed" from Fedora 8/32-bit and tried 'em. 
Every one showed caused the 2.6.25.x kernel to emit the warnings while 
they worked fine on a 2.6.24.x kernel.

I wondered whether this might be caused by my kernel on the AMD Geode 
LX, so I hopped over to a more typical platform - I  went and built a 
64-bit version of 2.6.25.1 and slapped it onto a Fedora 8/64-bit box and 
it, using the Fedora 8 version of 'tc', also showed an error.

My typical test case is a script that clears things out and then imposes 
an impairment on the last line.  (But I get the same problem with other 
command sequences as well, but this one is nice and short.)

/sbin/tc qdisc del dev eth1 root
/sbin/tc qdisc del dev eth1 ingress
/sbin/tc qdisc add dev eth1 root handle 1: prio bands 5 priomap 4 4 4 4 
4 4 4 4 4 4 4 4 4 4 4 4
/sbin/tc qdisc add dev eth1 parent 1:1 handle 10: netem
/sbin/tc qdisc add dev eth1 parent 10:1 handle 100: tbf rate 2147483647 
burst 1600 latency 2000000 mpu 64
/sbin/tc qdisc change dev eth1 parent 1:1 handle 10: netem delay 50ms 
5ms 10% corrupt 8%

It also generates the warning if the last line of the above is simply:

/sbin/tc qdisc change dev eth1 parent 1:1 handle 10: netem delay 50ms 
5ms 10%

But not if that last line is (i.e. with the correlation part dropped.)

/sbin/tc qdisc change dev eth1 parent 1:1 handle 10: netem delay 50ms 5ms

So, all in all, it seems to me that a bug has crept into the kernel 
interpretation of the netem netlink messages.

		--karl--

  reply	other threads:[~2008-05-21 22:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-21 21:45 Fwd: [Bug 447812] New: Netlink messages from "tc" to sch_netem module are not interpreted correctly Dave Jones
2008-05-21 22:10 ` Stephen Hemminger [this message]
2008-05-22  0:21   ` Thomas Graf
2008-05-22  0:57     ` Rick Jones
2008-05-22 11:18       ` Thomas Graf
2008-05-22 16:32         ` Rick Jones
2008-05-22 11:37     ` [NETLINK]: Fix nla_parse_nested_compat() to call nla_parse() directly Thomas Graf
2008-05-22 12:45       ` Patrick McHardy
2008-05-22 17:49         ` David Miller
2008-05-22 18:02           ` Stephen Hemminger
2008-05-22 18:11             ` David Miller
2008-05-21 22:16 ` Fwd: [Bug 447812] New: Netlink messages from "tc" to sch_netem module are not interpreted correctly Rick Jones
2008-05-21 22:36   ` Rick Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080521151021.3d47a3d8@extreme \
    --to=shemminger@vyatta.com \
    --cc=davej@codemonkey.org.uk \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).