linux.git/net, branch v2.6.22-rc4

[ICMP]: Fix icmp_errors_use_inbound_ifaddr sysctl

2007-06-04T01:08:51+00:00

Currently when icmp_errors_use_inbound_ifaddr is set and an ICMP error is
sent after the packet passed through ip_output(), an address from the
outgoing interface is chosen as ICMP source address since skb->dev doesn't
point to the incoming interface anymore.

Fix this by doing an interface lookup on rt->dst.iif and using that device.

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller

[IPV4]: Fix "ipOutNoRoutes" counter error for TCP and UDP

2007-06-04T01:08:50+00:00

Signed-off-by: Wei Dong 
Signed-off-by: David S. Miller

[NET] gso: Fix GSO feature mask in sk_setup_caps

2007-06-04T01:08:49+00:00

This isn't a bug just yet as only TCP uses sk_setup_caps for GSO.
However, if and when UDP or something else starts using it this is
likely to cause a problem if we forget to add software emulation
for it at the same time.

The problem is that right now we translate GSO emulation to the
bitmask NETIF_F_GSO_MASK, which includes every protocol, even
ones that we cannot emulate.

This patch makes it provide only the ones that we can emulate.

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

[TCP]: Fix GSO ignorance of pkts_acked arg (cong.cntrl modules)

2007-06-04T01:08:48+00:00

The code used to ignore GSO completely, passing either way too
small or zero pkts_acked when GSO skb or part of it got ACKed.
In addition, there is no need to calculate the value in the loop
but simple arithmetics after the loop is sufficient. There is
no need to handle SYN case specially because congestion control
modules are not yet initialized when FLAG_SYN_ACKED is set.

Signed-off-by: Ilpo Järvinen 
Signed-off-by: David S. Miller

[NET]: Fix comparisons of unsigned < 0.

2007-06-04T01:08:47+00:00

Recent gcc versions emit warnings when unsigned variables are
compared < 0 or >= 0.

Signed-off-by: Bill Nottingham 
Signed-off-by: David S. Miller

[NET]: Make net watchdog timers 1 sec jiffy aligned.

2007-06-04T01:08:46+00:00

round_jiffies for net dev watchdog timer.

Signed-off-by: Venkatesh Pallipadi 
Signed-off-by: David S. Miller

[TCP]: Use default 32768-61000 outgoing port range in all cases.

2007-06-04T01:08:43+00:00

This diff changes the default port range used for outgoing connections,
from "use 32768-61000 in most cases, but use N-4999 on small boxes
(where N is a multiple of 1024, depending on just *how* small the box
is)" to just "use 32768-61000 in all cases".

I don't believe there are any drawbacks to this change, and it keeps
outgoing connection ports farther away from the mess of
IANA-registered ports.

Signed-off-by: Mark Glines 
Signed-off-by: David S. Miller

[AF_UNIX]: Fix datagram connect race causing an OOPS.

2007-06-04T01:08:42+00:00

Based upon an excellent bug report and initial patch by
Frederik Deweerdt.

The UNIX datagram connect code blindly dereferences other->sk_socket
via the call down to the security_unix_may_send() function.

Without locking 'other' that pointer can go NULL via unix_release_sock()
which does sock_orphan() which also marks the socket SOCK_DEAD.

So we have to lock both 'sk' and 'other' yet avoid all kinds of
potential deadlocks (connect to self is OK for datagram sockets and it
is possible for two datagram sockets to perform a simultaneous connect
to each other).  So what we do is have a "double lock" function similar
to how we handle this situation in other areas of the kernel.  We take
the lock of the socket pointer with the smallest address first in
order to avoid ABBA style deadlocks.

Once we have them both locked, we check to see if SOCK_DEAD is set
for 'other' and if so, drop everything and retry the lookup.

Signed-off-by: David S. Miller

[AF_UNIX]: Make socket locking much less confusing.

2007-06-04T01:08:40+00:00

The unix_state_*() locking macros imply that there is some
rwlock kind of thing going on, but the implementation is
actually a spinlock which makes the code more confusing than
it needs to be.

So use plain unix_state_lock and unix_state_unlock.

Signed-off-by: David S. Miller

VLAN: kill_vid is only useful for VLAN filtering devices

2007-06-03T15:44:19+00:00

The interface for network device VLAN extension was confusing.
The kill_vid function is only really useful for devices that do
hardware filtering. Devices that only do VLAN receiption without
filtering were being forced to provide the hook, and there were
bugs in those devices.

Many drivers had kill_vid routine that called vlan_group_set_device, with
NULL, but that is done already.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Jeff Garzik