linux-stable.git/net/core, branch linux-2.6.17.y

PKTGEN: Fix oops when used with balance-tlb bonding

2006-09-08T21:51:39+00:00

Signed-off-by: Chen-Li Tien 
Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

PKTGEN: Make sure skb->{nh,h} are initialized in fill_packet_ipv6() too.

2006-09-08T21:51:39+00:00

[PKTGEN]: Make sure skb->{nh,h} are initialized in fill_packet_ipv6() too.

Mirror the bug fix from fill_packet_ipv4()

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Fix IFLA_ADDRESS handling

2006-08-23T21:13:30+00:00

[RTNETLINK]: Fix IFLA_ADDRESS handling.

The ->set_mac_address handlers expect a pointer to a
sockaddr which contains the MAC address, whereas
IFLA_ADDRESS provides just the MAC address itself.

So whip up a sockaddr to wrap around the netlink
attribute for the ->set_mac_address call.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Fix timer race in dst GC code

2006-08-23T21:13:30+00:00

[NET]: add_timer -> mod_timer() in dst_run_gc()

Patch from Dmitry Mishin :

Replace add_timer() by mod_timer() in dst_run_gc
in order to avoid BUG message.

   CPU1                            CPU2
dst_run_gc()  entered           dst_run_gc() entered
spin_lock(&dst_lock)                   .....
del_timer(&dst_gc_timer)         fail to get lock
   ....                         mod_timer() <--- puts
					     timer back
					     to the list
add_timer(&dst_gc_timer) <--- BUG because timer is in list already.

Found during OpenVZ internal testing.

At first we thought that it is OpenVZ specific as we
added dst_run_gc(0) call in dst_dev_event(),
but as Alexey pointed to me it is possible to trigger
this condition in mainstream kernel.

F.e. timer has fired on CPU2, but the handler was preeempted
by an irq before dst_lock is tried.
Meanwhile, someone on CPU1 adds an entry to gc list and
starts the timer.
If CPU2 was preempted long enough, this timer can expire
simultaneously with resuming timer handler on CPU1, arriving
exactly to the situation described.

Signed-off-by: Dmitry Mishin 
Signed-off-by: Kirill Korotaev 
Signed-off-by: Alexey Kuznetsov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Update frag_list in pskb_trim

2006-08-07T03:52:14+00:00

[NET]: Update frag_list in pskb_trim

When pskb_trim has to defer to ___pksb_trim to trim the frag_list part of
the packet, the frag_list is not updated to reflect the trimming.  This
will usually work fine until you hit something that uses the packet length
or tail from the frag_list.

Examples include esp_output and ip_fragment.

Another problem caused by this is that you can end up with a linear packet
with a frag_list attached.

It is possible to get away with this if we audit everything to make sure
that they always consult skb->len before going down onto frag_list.  In
fact we can do the samething for the paged part as well to avoid copying
the data area of the skb.  For now though, let's do the conservative fix
and update frag_list.

Many thanks to Marco Berizzi for helping me to track down this bug.

This 4-year old bug took 3 months to track down.  Marco was very patient
indeed :)

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Add missing UFO initialisations

2006-07-25T03:35:25+00:00

This bug was unknowingly fixed the GSO patches (or rather, its effect was
unknown at the time).

Thanks to Marco Berizzi's persistence which is documented in the thread
"ipsec tunnel asymmetrical mtu", we now know that it can have highly
non-obvious symptoms.

What happens is that uninitialised uso_size fields can cause packets to
be incorrectly identified as UFO, which means that it does not get
fragmented even if it's over the MTU.

The fix is simple enough.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ethtool: oops in ethtool_set_pauseparam()

2006-07-25T03:35:21+00:00

The function pointers which were checked were for their get_* counterparts.
Typically a copy-paste typo.

Signed-off-by: Willy Tarreau 
Acked-by: Jeff Garzik 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

[PATCH] ETHTOOL: Fix UFO typo

2006-06-30T00:17:15+00:00

The function ethtool_get_ufo was referring to ETHTOOL_GTSO instead of
ETHTOOL_GUFO.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright

[NET]: dev.c comment fixes

2006-05-26T20:25:24+00:00

Noticed that dev_alloc_name() comment was incorrect, and more spellung
errors.

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller

[NEIGH]: Fix IP-over-ATM and ARP interaction.

2006-05-12T21:56:08+00:00

The classical IP over ATM code maintains its own IPv4 <-> 
ARP table, using the standard neighbour-table code. The
neigh_table_init function adds this neighbour table to a linked list
of all neighbor tables which is used by the functions neigh_delete()
neigh_add() and neightbl_set(), all called by the netlink code.

Once the ATM neighbour table is added to the list, there are two
tables with family == AF_INET there, and ARP entries sent via netlink
go into the first table with matching family. This is indeterminate
and often wrong.

To see the bug, on a kernel with CLIP enabled, create a standard IPv4
ARP entry by pinging an unused address on a local subnet. Then attempt
to complete that entry by doing

ip neigh replace  lladdr  nud reachable

Looking at the ARP tables by using 

ip neigh show

will reveal two ARP entries for the same address. One of these can be
found in /proc/net/arp, and the other in /proc/net/atm/arp.

This patch adds a new function, neigh_table_init_no_netlink() which
does everything the neigh_table_init() does, except add the table to
the netlink all-arp-tables chain. In addition neigh_table_init() has a
check that all tables on the chain have a distinct address family.
The init call in clip.c is changed to call
neigh_table_init_no_netlink().

Since ATM ARP tables are rather more complicated than can currently be
handled by the available rtattrs in the netlink protocol, no
functionality is lost by this patch, and non-ATM ARP manipulation via
netlink is rescued. A more complete solution would involve a rtattr
for ATM ARP entries and some way for the netlink code to give
neigh_add and friends more information than just address family with
which to find the correct ARP table.

[ I've changed the assertion checking in neigh_table_init() to not
  use BUG_ON() while holding neigh_tbl_lock.  Instead we remember that
  we found an existing tbl with the same family, and after dropping
  the lock we'll give a diagnostic kernel log message and a stack dump.
  -DaveM ]

Signed-off-by: Simon Kelley 
Signed-off-by: David S. Miller