From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.14) Gecko/20080416 Fedora/2.0.0.14-1.fc8 Firefox/2.0.0.14

Description of problem:
When using the tc command to send netem settings to the netem module, the messages cause a kernel error to be emitted into dmesg and part of the data in the netlink message may be lost.

This makes the netem mechanism quietly unreliable when used on a 2.6.25 kernel.

I have tried this on all of the 2.6.25.X kernels and the results are the same.

This problem did not occur with the2.6.24 kernels.

The problem is the same on x86_64 and i386 architectures.

Version-Release number of selected component (if applicable):
2.6.25.3-18.fc9.x86_64

How reproducible:
Always


Steps to Reproduce:
Here is a shell script (needs to be run as root):

#!/bin/bash

DEV=eth0
TC=/sbin/tc

# Clean out any prior settings.
# This may generate some messages of the form:
#   RTNETLINK answers: No such file or directory
${TC} qdisc del dev ${DEV} root > /dev/null 2>&1
${TC} qdisc del dev ${DEV} ingress > /dev/null 2>&1

${TC} qdisc add dev ${DEV} root handle 1: prio bands 5 priomap 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
${TC} qdisc add dev ${DEV} parent 1:1 handle 10: netem

# If the kernel is acting up this will cause a kernel
# message of the following form to be emitted and visible
# via dmesg | tail
#  netlink: 12 bytes leftover after parsing attributes.
${TC} qdisc change dev ${DEV} parent 1:1 handle 10: netem delay 50ms 5ms 10% corrupt 8%
echo
echo
echo "Does the following contain a netlink message about leftover bytes?"
echo "If so, the the kernel code in .../net/netlink/attr.c"
echo "is unhappy with the netlink messages from the tc command."
dmesg | tail -3

# Take a look at the netem status and see whether a corruption
# value has been established or not.
echo
echo
echo "Does the following show a corruption setting or not?"
echo "If not then the kernel module .../net/sched/sch_netem.c"
echo "did not pick up all the pieces from the netlink message"
echo "complained of by .../net/netlink/attr.c"
echo "A GOOD response should look like this:"
echo "    qdisc prio 1: root bands 5 priomap  4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4"
echo "    qdisc netem 10: parent 1:1 limit 1000 delay 50.0ms  5.0ms 10% corrupt 8%"

${TC} qdisc show dev ${DEV}

${TC} qdisc show dev ${DEV} | grep netem | grep -q corrupt > /dev/null
RC=$?

if [ "${RC}" != 0 ] ; then
   echo
   echo "I did not see any corruption setting, did you?"
   echo "Seems like there is a bug in the tc-to-netem module netlink."
fi

# Clean up after ourselves.
# This may generate some messages of the form:
#   RTNETLINK answers: No such file or directory
${TC} qdisc del dev ${DEV} root > /dev/null 2>&1
${TC} qdisc del dev ${DEV} ingress > /dev/null 2>&1


Actual Results:
On all 2.6.25 kernels, whether i386 or x86_64, this causes a kernel message to be emitted about unused bytes.  In addition, the netem module does not pick up all of the data that was sent to it, such as the corruption settings.

All of this stuff worked in the 2.6.24 kernels.

Expected Results:
No kernel message should have been emitted.

The data sent by the user via the "tc" command should have been received by the netem module.

Additional info:
I tried to figure out whether the problem is in "tc" or in the kernel.

So I ran some old "tc" binaries on new kernels.  The result was the same as if I had run current "tc" binaries.  This suggests that the problem is in the kernel rather than in the "tc" command.

I also did some simple printk debugging on the way that .../net/netlink/attr.c was parsing the netlink messages.  The number of bytes that it reported unused always was the sizeof the first chunk of netem data that was lost in the netlink message.