dev_queue_xmit() and the other IP output functions expect to get a skb
with clear or properly initialized skb->cb. Unlike TCP and UDP, the
dccp_skb_cb doesn't contain a struct inet_skb_parm at the beginning,
so the DCCP-specific data is interpreted by the IP output functions.
This can cause false negatives for the conditional POST_ROUTING hook
invocation, making the packet bypass the hook.

Add a inet_skb_parm/inet6_skb_parm union to the beginning of
dccp_skb_cb to avoid clashes. Also add a BUILD_BUG_ON to make
sure it fits in the cb.

[ Combined with patch from Gerrit Renker to remove two now unnecessary
  memsets of IPCB(skb)->opt ]
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The ax25_uid_free call walks the ax25_uid_list and releases entries
from it. The problem is that after the fisrt call to hlist_del_init
the hlist_for_each_entry (which hides behind the ax25_uid_for_each)
will consider the current position to be the last and will return.

Thus, the whole list will be left not freed.
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Copy the network namespace from the socket to the timewait socket.
Signed-off-by: NDaniel Lezcano <dlezcano@fr.ibm.com>
Acked-by: NMark Lord <mlord@pobox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This fixes kernel bugzilla 10371.

As reported by M.Piechaczek@osmosys.tv, if we try to grab a
char sized socket option value, as in:

  unsigned char ttl = 255;
  socklen_t     len = sizeof(ttl);
  setsockopt(socket, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, &len);

  getsockopt(socket, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, &len);

The ttl returned will be wrong on big-endian, and on both little-
endian and big-endian the next three bytes in userspace are written
with garbage.

It's because of this test in do_ip_getsockopt():

	if (len < sizeof(int) && len > 0 && val>=0 && val<255) {

It should allow a 'val' of 255 to pass here, but it doesn't so it
copies a full 'int' back to userspace.

On little-endian that will write the correct value into the location
but it spams on the next three bytes in userspace.  On big endian it
writes the wrong value into the location and spams the next three
bytes.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Without this patch, the generic L3 tracker would kick in
if nf_conntrack_ipv4 was not loaded before nf_nat, which
would lead to translation problems with ICMP errors.

NAT does not make sense without IPv4 connection tracking
anyway, so just add a call to need_ipv4_conntrack().
Signed-off-by: NJan Engelhardt <jengelh@computergmbh.de>
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Shifts larger than the data type are undefined, don't try to shift
an u32 by 32. Also remove some special-casing of bitmasks divisible
by 32.

Based on patch by Jan Engelhardt <jengelh@computergmbh.de>.
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit df9dcb45 ([IPSEC]: Fix inter address family IPsec tunnel handling)
broke openswan by removing the selector initialization for tunnel mode
in case it is uninitialized.

This patch restores the initialization, fixing openswan, but probably
breaking inter-family tunnels again (unknown since the patch author
disappeared). The correct thing for inter-family tunnels is probably
to simply initialize the selector family explicitly.
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When associating to a b-only AP where there is no ERP IE, short preamble
mode is left at previous state (probably also protection mode). In this
case, disable protection and use short preamble mode as specified in
capability field. The same is done if capability field is changed on-the-fly.
Signed-off-by: NVladimir Koutny <vlado@ksp.sk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If print_mac() is used inside of a pr_debug() the compiler
can't see that the call is redundant so still performs it
even of pr_debug() ends up being a nop.

So don't use print_mac() in such cases in hot code paths,
use MAC_FMT et al. instead.

As noted by Joe Perches, pr_debug() could be modified to
handle this better, but that is a change to an interface
used by the entire kernel and thus needs to be validated
carefully.  This here is thus the less risky fix for
2.6.25
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

MTU probe can cause some remedies for FRTO because the normal
packet ordering may be violated allowing FRTO to make a wrong
decision (it might not be that serious threat for anything
though). Thus it's safer to not run FRTO while MTU probe is
underway.

It seems that the basic FRTO variant should also look for an
skb at probe_seq.start to check if that's retransmitted one
but I didn't implement it now (plain seqno in window check
isn't robust against wraparounds).
Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This fixes Bugzilla #10384

tcp_simple_retransmit does L increment without any checking
whatsoever for overflowing S+L when Reno is in use.

The simplest scenario I can currently think of is rather
complex in practice (there might be some more straightforward
cases though). Ie., if mss is reduced during mtu probing, it
may end up marking everything lost and if some duplicate ACKs
arrived prior to that sacked_out will be non-zero as well,
leading to S+L > packets_out, tcp_clean_rtx_queue on the next
cumulative ACK or tcp_fastretrans_alert on the next duplicate
ACK will fix the S counter.

More straightforward (but questionable) solution would be to
just call tcp_reset_reno_sack() in tcp_simple_retransmit but
it would negatively impact the probe's retransmission, ie.,
the retransmissions would not occur if some duplicate ACKs
had arrived.

So I had to add reno sacked_out reseting to CA_Loss state
when the first cumulative ACK arrives (this stale sacked_out
might actually be the explanation for the reports of left_out
overflows in kernel prior to 2.6.23 and S+L overflow reports
of 2.6.24). However, this alone won't be enough to fix kernel
before 2.6.24 because it is building on top of the commit
1b6d427b ([TCP]: Reduce sacked_out with reno when purging
write_queue) to keep the sacked_out from overflowing.
Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
Reported-by: NAlessandro Suardi <alessandro.suardi@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fixes a long-standing bug which makes NewReno recovery crippled.
With GSO the whole head skb was marked as LOST which is in
violation of NewReno procedure that only wants to mark one packet
and ended up breaking our TCP code by causing counter overflow
because our code was built on top of assumption about valid
NewReno procedure. This manifested as triggering a WARN_ON for
the overflow in a number of places.

It seems relatively safe alternative to just do nothing if
tcp_fragment fails due to oom because another duplicate ACK is
likely to be received soon and the fragmentation will be retried.

Special thanks goes to Soeren Sonnenburg <kernel@nn7.de> who was
lucky enough to be able to reproduce this so that the warning
for the overflow was hit. It's not as easy task as it seems even
if this bug happens quite often because the amount of outstanding
data is pretty significant for the mismarkings to lead to an
overflow.

Because it's very late in 2.6.25-rc cycle (if this even makes in
time), I didn't want to touch anything with SACK enabled here.
Fragmenting might be useful for it as well but it's more or less
a policy decision rather than mandatory fix. Thus there's no need
to rush and we can postpone considering tcp_fragment with SACK
for 2.6.26.

In 2.6.24 and earlier, this very same bug existed but the effect
is slightly different because of a small changes in the if
conditions that fit to the patch's context. With them nothing
got lost marker and thus no retransmissions happened.
Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The fast retransmission can be forced locally to the rfc3517
branch in tcp_update_scoreboard instead of making such fragile
constructs deeper in tcp_mark_head_lost.

This is necessary for the next patch which must not have
loopholes for cnt > packets check. As one can notice,
readability got some improvements too because of this :-).
Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This fixes the STA AID setting and actually makes hostapd/mac80211
work properly in presence of power-saving stations.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

These entries are allocated in vlan_dev_set_egress_priority, 
but are never released and leaks on vlan device removal.

Drop these in vlan's ->uninit callback - after the device is 
brought down and everyone is notified about it is going to
be unregistered.

Found during testing vlan netnsization patchset.
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Acked-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Anycast DST entries allocated inside ipv6_dev_ac_inc are leaked when
network device is stopped without removing IPv6 addresses from it. The
bug has been observed in the reality on 2.6.18-rhel5 kernel.

In the above case addrconf_ifdown marks all entries as obsolete and
ip6_del_rt called from __ipv6_dev_ac_dec returns ENOENT. The
referrence is not dropped.

The fix is simple. DST entry should not keep referrence when stored in
the FIB6 tree.
Signed-off-by: NDenis V. Lunev <den@openvz.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In the other case it will be destroyed when last address will be removed
from lo inside a namespace. This will break IPv6 in several places. The
most obvious one is ip6_dst_ifdown.
Signed-off-by: NDenis V. Lunev <den@openvz.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

addrconf_ifdown is broken in respect to the usage of how
parameter. This function is called with (event != NETDEV_DOWN) and (2)
on the IPv6 stop.  It the latter case inet6_dev from loopback device
should be destroyed.
Signed-off-by: NDenis V. Lunev <den@openvz.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The ICMP relookup path is only meant to modify behaviour when
appropriate IPsec policies are in place and marked as requiring
relookups.  It is certainly not meant to modify behaviour when
IPsec policies don't exist at all.

However, due to an oversight on the error paths existing behaviour
may in fact change should one of the relookup steps fail.

This patch corrects this by redirecting all errors on relookup
failures to the previous code path.  That is, if the initial
xfrm_lookup let the packet pass, we will stand by that decision
should the relookup fail due to an error.

This should be safe from a security point-of-view because compliant
systems must install a default deny policy so the packet would'nt
have passed in that case.

Many thanks to Julian Anastasov for pointing out this error.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This may lead to situations, when each of two proc entries produce
data for the other's device.

Looks like a BUG, so this patch is for net-2.6. It will not apply to
net-2.6.26 since dev->nd_net access is replaced with dev_net(dev)
one.
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When we encounter an error while looking up the dst the second
time we need to drop the first dst.  This patch is pretty much
the same as the one for IPv4.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

From RFC341:
A temporary address is created only if this calculated Preferred
Lifetime is greater than REGEN_ADVANCE time units.  In particular, an
implementation must not create a temporary address with a zero
Preferred Lifetime.
Signed-off-by: NBenoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When receiving a prefix information from a routeur, only update the
lifetimes of the temporary address associated with that prefix.

Otherwise if one deprecated prefix is advertized, all your temporary
addresses will become deprecated.
Signed-off-by: NBenoit Boissinot <benoit.boissinot@ens-lyon.org>
Acked-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Lockdep warning will be trigged while rfcomm connection closing.

The locks taken in rfcomm_dev_add:
rfcomm_dev_lock --> d->lock

In __rfcomm_dlc_close:
d->lock --> rfcomm_dev_lock (in rfcomm_dev_state_change)

There's two way to fix it, one is in rfcomm_dev_add we first locking
d->lock then the rfcomm_dev_lock

The other (in this patch), remove the locking of d->lock for
rfcomm_dev_state_change because just locking "d->state = BT_CLOSED;"
is enough.

[  295.002046] =======================================================
[  295.002046] [ INFO: possible circular locking dependency detected ]
[  295.002046] 2.6.25-rc7 #1
[  295.002046] -------------------------------------------------------
[  295.002046] krfcommd/2705 is trying to acquire lock:
[  295.002046]  (rfcomm_dev_lock){-.--}, at: [<f89a090a>] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm]
[  295.002046] 
[  295.002046] but task is already holding lock:
[  295.002046]  (&d->lock){--..}, at: [<f899c533>] __rfcomm_dlc_close+0x43/0xd0 [rfcomm]
[  295.002046] 
[  295.002046] which lock already depends on the new lock.
[  295.002046] 
[  295.002046] 
[  295.002046] the existing dependency chain (in reverse order) is:
[  295.002046] 
[  295.002046] -> #1 (&d->lock){--..}:
[  295.002046]        [<c0149b23>] check_prev_add+0xd3/0x200
[  295.002046]        [<c0149ce5>] check_prevs_add+0x95/0xe0
[  295.002046]        [<c0149f6f>] validate_chain+0x23f/0x320
[  295.002046]        [<c014b7b1>] __lock_acquire+0x1c1/0x760
[  295.002046]        [<c014c349>] lock_acquire+0x79/0xb0
[  295.002046]        [<c03d6b99>] _spin_lock+0x39/0x80
[  295.002046]        [<f89a01c0>] rfcomm_dev_add+0x240/0x360 [rfcomm]
[  295.002046]        [<f89a047e>] rfcomm_create_dev+0x6e/0xe0 [rfcomm]
[  295.002046]        [<f89a0823>] rfcomm_dev_ioctl+0x33/0x60 [rfcomm]
[  295.002046]        [<f899facc>] rfcomm_sock_ioctl+0x2c/0x50 [rfcomm]
[  295.002046]        [<c0363d38>] sock_ioctl+0x118/0x240
[  295.002046]        [<c0194196>] vfs_ioctl+0x76/0x90
[  295.002046]        [<c0194446>] do_vfs_ioctl+0x56/0x140
[  295.002046]        [<c0194569>] sys_ioctl+0x39/0x60
[  295.002046]        [<c0104faa>] syscall_call+0x7/0xb
[  295.002046]        [<ffffffff>] 0xffffffff
[  295.002046] 
[  295.002046] -> #0 (rfcomm_dev_lock){-.--}:
[  295.002046]        [<c0149a84>] check_prev_add+0x34/0x200
[  295.002046]        [<c0149ce5>] check_prevs_add+0x95/0xe0
[  295.002046]        [<c0149f6f>] validate_chain+0x23f/0x320
[  295.002046]        [<c014b7b1>] __lock_acquire+0x1c1/0x760
[  295.002046]        [<c014c349>] lock_acquire+0x79/0xb0
[  295.002046]        [<c03d6639>] _read_lock+0x39/0x80
[  295.002046]        [<f89a090a>] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm]
[  295.002046]        [<f899c548>] __rfcomm_dlc_close+0x58/0xd0 [rfcomm]
[  295.002046]        [<f899d44f>] rfcomm_recv_ua+0x6f/0x120 [rfcomm]
[  295.002046]        [<f899e061>] rfcomm_recv_frame+0x171/0x1e0 [rfcomm]
[  295.002046]        [<f899e357>] rfcomm_run+0xe7/0x550 [rfcomm]
[  295.002046]        [<c013c18c>] kthread+0x5c/0xa0
[  295.002046]        [<c0105c07>] kernel_thread_helper+0x7/0x10
[  295.002046]        [<ffffffff>] 0xffffffff
[  295.002046] 
[  295.002046] other info that might help us debug this:
[  295.002046] 
[  295.002046] 2 locks held by krfcommd/2705:
[  295.002046]  #0:  (rfcomm_mutex){--..}, at: [<f899e2eb>] rfcomm_run+0x7b/0x550 [rfcomm]
[  295.002046]  #1:  (&d->lock){--..}, at: [<f899c533>] __rfcomm_dlc_close+0x43/0xd0 [rfcomm]
[  295.002046] 
[  295.002046] stack backtrace:
[  295.002046] Pid: 2705, comm: krfcommd Not tainted 2.6.25-rc7 #1
[  295.002046]  [<c0128a38>] ? printk+0x18/0x20
[  295.002046]  [<c014927f>] print_circular_bug_tail+0x6f/0x80
[  295.002046]  [<c0149a84>] check_prev_add+0x34/0x200
[  295.002046]  [<c0149ce5>] check_prevs_add+0x95/0xe0
[  295.002046]  [<c0149f6f>] validate_chain+0x23f/0x320
[  295.002046]  [<c014b7b1>] __lock_acquire+0x1c1/0x760
[  295.002046]  [<c014c349>] lock_acquire+0x79/0xb0
[  295.002046]  [<f89a090a>] ? rfcomm_dev_state_change+0x6a/0xd0 [rfcomm]
[  295.002046]  [<c03d6639>] _read_lock+0x39/0x80
[  295.002046]  [<f89a090a>] ? rfcomm_dev_state_change+0x6a/0xd0 [rfcomm]
[  295.002046]  [<f89a090a>] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm]
[  295.002046]  [<f899c548>] __rfcomm_dlc_close+0x58/0xd0 [rfcomm]
[  295.002046]  [<f899d44f>] rfcomm_recv_ua+0x6f/0x120 [rfcomm]
[  295.002046]  [<f899e061>] rfcomm_recv_frame+0x171/0x1e0 [rfcomm]
[  295.002046]  [<c014abd9>] ? trace_hardirqs_on+0xb9/0x130
[  295.002046]  [<c03d6e89>] ? _spin_unlock_irqrestore+0x39/0x70
[  295.002046]  [<f899e357>] rfcomm_run+0xe7/0x550 [rfcomm]
[  295.002046]  [<c03d4559>] ? __sched_text_start+0x229/0x4c0
[  295.002046]  [<c0120000>] ? cpu_avg_load_per_task+0x20/0x30
[  295.002046]  [<f899e270>] ? rfcomm_run+0x0/0x550 [rfcomm]
[  295.002046]  [<c013c18c>] kthread+0x5c/0xa0
[  295.002046]  [<c013c130>] ? kthread+0x0/0xa0
[  295.002046]  [<c0105c07>] kernel_thread_helper+0x7/0x10
[  295.002046]  =======================
Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

'rfcomm connect' will trigger lockdep warnings which is caused by
locking diffrent kinds of bluetooth sockets at the same time.

So using sub-classes per AF_BLUETOOTH sub-type for lockdep.

Thanks for the hints from dave jones.

---
> From: Dave Jones <davej@codemonkey.org.uk>
> Date: Thu, 27 Mar 2008 12:21:56 -0400
>
> > Mar 27 08:10:57 localhost kernel: Pid: 3611, comm: obex-data-serve Not tainted 2.6.25-0.121.rc5.git4.fc9 #1
> > Mar 27 08:10:57 localhost kernel:  [__lock_acquire+2287/3089] __lock_acquire+0x8ef/0xc11
> > Mar 27 08:10:57 localhost kernel:  [sched_clock+8/11] ? sched_clock+0x8/0xb
> > Mar 27 08:10:57 localhost kernel:  [lock_acquire+106/144] lock_acquire+0x6a/0x90
> > Mar 27 08:10:57 localhost kernel:  [<f8bd9321>] ? l2cap_sock_bind+0x29/0x108 [l2cap]
> > Mar 27 08:10:57 localhost kernel:  [lock_sock_nested+182/198] lock_sock_nested+0xb6/0xc6
> > Mar 27 08:10:57 localhost kernel:  [<f8bd9321>] ? l2cap_sock_bind+0x29/0x108 [l2cap]
> > Mar 27 08:10:57 localhost kernel:  [security_socket_post_create+22/27] ? security_socket_post_create+0x16/0x1b
> > Mar 27 08:10:57 localhost kernel:  [__sock_create+388/472] ? __sock_create+0x184/0x1d8
> > Mar 27 08:10:57 localhost kernel:  [<f8bd9321>] l2cap_sock_bind+0x29/0x108 [l2cap]
> > Mar 27 08:10:57 localhost kernel:  [kernel_bind+10/13] kernel_bind+0xa/0xd
> > Mar 27 08:10:57 localhost kernel:  [<f8dad3d7>] rfcomm_dlc_open+0xc8/0x294 [rfcomm]
> > Mar 27 08:10:57 localhost kernel:  [lock_sock_nested+187/198] ? lock_sock_nested+0xbb/0xc6
> > Mar 27 08:10:57 localhost kernel:  [<f8dae18c>] rfcomm_sock_connect+0x8b/0xc2 [rfcomm]
> > Mar 27 08:10:57 localhost kernel:  [sys_connect+96/125] sys_connect+0x60/0x7d
> > Mar 27 08:10:57 localhost kernel:  [__lock_acquire+1370/3089] ? __lock_acquire+0x55a/0xc11
> > Mar 27 08:10:57 localhost kernel:  [sys_socketcall+140/392] sys_socketcall+0x8c/0x188
> > Mar 27 08:10:57 localhost kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
---
Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

rose_release() doesn't release sockets properly, e.g. it skips
sock_orphan(), so OOPSes are triggered in sock_def_write_space(),
which was observed especially while ROSE skbs were kfreed from
ax25_frames_acked(). There is also sock_hold() and lock_sock() added -
similarly to ax25_release(). Thanks to Bernard Pidoux for substantial
help in debugging this problem.
Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
Reported-and-tested-by: NBernard Pidoux <bpidoux@free.fr>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

ERP IE bit for preamble mode is 0 for short and 1 for long, not the other
way around. This fixes the value reported to the driver via
bss_conf->use_short_preamble field.
Signed-off-by: NVladimir Koutny <vlado@ksp.sk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ieee80211_sta_work is disabled while network interface
is down. Therefore, if you configure wireless parameters
before bringing the interface up, these configurations are
not yet effective and association fails.

A workaround from userspace is calling a command like
'iwconfig wlan0 ap any' after the interface is brought up.

To fix this behaviour, trigger execution of ieee80211_sta_work from
ieee80211_open when in STA or IBSS mode.
Signed-off-by: NJan Niehusmann <jan@gondor.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Allocate the skb for llc responses with the received packet size by
using the size adjustable llc_frame_alloc.
Don't allocate useless extra payload.
Cleanup magic numbers.

So, this fixes oops.
Reported by Jim Westfall:
kernel: skb_over_panic: text:c0541fc7 len:1000 put:997 head:c166ac00 data:c166ac2f tail:0xc166b017 end:0xc166ac80 dev:eth0
kernel: ------------[ cut here ]------------
kernel: kernel BUG at net/core/skbuff.c:95!
Signed-off-by: NJoonwoo Park <joonwpark81@gmail.com>
Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In ip6_mc_input(), we need to check whether we have listener(s) for
the packet.

After commit ae7bf20a, all packets
for multicast destinations are delivered to upper layer if
IFF_PROMISC or IFF_ALLMULTI is set.

In fact, bug was rather ancient; the original (before the commit)
intent of the dev->flags check was to skip the ipv6_chk_mcast_addr()
call, assuming L2 filters packets appropriately, but it was even not
true.

Let's explicitly check our multicast list.
Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Acked-by: NDavid L Stevens <dlstevens@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Based upon a lockdep trace from Dave Jones.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

kill unnecessary llc_station_mac_sa.
Signed-off-by: NJoonwoo Park <joonwpark81@gmail.com>
Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

discard llc packet which has bogus packet length.
Signed-off-by: NJoonwoo Park <joonwpark81@gmail.com>
Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The qdisc_run loop is currently unbounded and runs entirely in a
softirq.  This is bad as it may create an unbounded softirq run.

This patch fixes this by calling need_resched and breaking out if
necessary.

It also adds a break out if the jiffies value changes since that would
indicate we've been transmitting for too long which starves other
softirqs.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 9af3912e ("[NET] Move DF check
to ip_forward") added a new check to send ICMP fragmentation needed
for large packets.

Unlike the check in ip_finish_output(), it doesn't check for GSO.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The older RW_LOCK_UNLOCKED macros defeat lockdep state tracing so
replace them with the newer __RW_LOCK_UNLOCKED macros.
Signed-off-by: NRobert P. J. Day <rpjday@crashcourse.ca>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Mar 23 09:06:31 opensuse103 kernel: Installing 9P2000 support
Mar 23 09:06:31 opensuse103 kernel: sys_init_module: '9pnet_fd'->init suspiciously returned 1, it should follow 0/-E convention
Mar 23 09:06:31 opensuse103 kernel: sys_init_module: loading module anyway...
Mar 23 09:06:31 opensuse103 kernel: Pid: 5323, comm: modprobe Not tainted 2.6.25-rc6-git7-default #1
Mar 23 09:06:31 opensuse103 kernel:  [<c013c253>] sys_init_module+0x172b/0x17c9
Mar 23 09:06:31 opensuse103 kernel:  [<c0108a6a>] sys_mmap2+0x62/0x77
Mar 23 09:06:31 opensuse103 kernel:  [<c01059c4>] sysenter_past_esp+0x6d/0xa9
Mar 23 09:06:31 opensuse103 kernel:  =======================

Cc: Latchesar Ionkov <lucho@ionkov.net>
Cc: Eric Van Hensbergen <ericvh@opteron.(none)>
Cc: David S. Miller <davem@davemloft.net>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: <devzero@web.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>