linux.git/net, branch v2.6.33 Linux kernel source tree net: bug fix for vlan + gro issue 2010-02-24T03:09:31+00:00 Ajit Khaparde ajitkhaparde@gmail.com 2010-02-16T20:25:43+00:00 c4d49794ff2838038fd9756eae39c39a5a685833 Traffic (tcp) doesnot start on a vlan interface when gro is enabled. Even the tcp handshake was not taking place. This is because, the eth_type_trans call before the netif_receive_skb in napi_gro_finish() resets the skb->dev to napi->dev from the previously set vlan netdev interface. This causes the ip_route_input to drop the incoming packet considering it as a packet coming from a martian source. I could repro this on 2.6.32.7 (stable) and 2.6.33-rc7. With this fix, the traffic starts and the test runs fine on both vlan and non-vlan interfaces. CC: Herbert Xu <herbert@gondor.apana.org.au> CC: Patrick McHardy <kaber@trash.net> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> 
Traffic (tcp) doesnot start on a vlan interface when gro is enabled.
Even the tcp handshake was not taking place.
This is because, the eth_type_trans call before the netif_receive_skb
in napi_gro_finish() resets the skb->dev to napi->dev from the previously
set vlan netdev interface. This causes the ip_route_input to drop the
incoming packet considering it as a packet coming from a martian source.

I could repro this on 2.6.32.7 (stable) and 2.6.33-rc7.
With this fix, the traffic starts and the test runs fine on both vlan
and non-vlan interfaces.

CC: Herbert Xu <herbert@gondor.apana.org.au>
CC: Patrick McHardy <kaber@trash.net>
Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
net-sysfs: Use rtnl_trylock in wireless sysfs methods. 2010-02-19T23:40:51+00:00 Eric W. Biederman ebiederm@xmission.com 2010-02-19T13:23:47+00:00 b8afe6416101549e877f8470f2a160df69676166 The wireless sysfs methods like the rest of the networking sysfs methods are removed with the rtnl_lock held and block until the existing methods stop executing. So use rtnl_trylock and restart_syscall so that the code continues to work. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
The wireless sysfs methods like the rest of the networking sysfs
methods are removed with the rtnl_lock held and block until
the existing methods stop executing.  So use rtnl_trylock
and restart_syscall so that the code continues to work.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: Fix sysctl restarts... 2010-02-19T23:40:50+00:00 Eric W. Biederman ebiederm@xmission.com 2010-02-19T13:22:59+00:00 88af182e389097997c5e2a0b42285b3522796759 Yuck. It turns out that when we restart sysctls we were restarting with the values already changed. Which unfortunately meant that the second time through we thought there was no change and skipped all kinds of work, despite the fact that there was indeed a change. I have fixed this the simplest way possible by restoring the changed values when we restart the sysctl write. One of my coworkers spotted this bug when after disabling forwarding on an interface pings were still forwarded. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
Yuck.  It turns out that when we restart sysctls we were restarting
with the values already changed.  Which unfortunately meant that
the second time through we thought there was no change and skipped
all kinds of work, despite the fact that there was indeed a change.

I have fixed this the simplest way possible by restoring the changed
values when we restart the sysctl write.

One of my coworkers spotted this bug when after disabling forwarding
on an interface pings were still forwarded.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 2010-02-17T00:52:04+00:00 Linus Torvalds torvalds@linux-foundation.org 2010-02-17T00:52:04+00:00 5d677670477f92006406d9d77cb42391fad17fcd * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (22 commits) be2net: set proper value to version field in req hdr xfrm: Fix xfrm_state_clone leak ipcomp: Avoid duplicate calls to ipcomp_destroy ethtool: allow non-admin user to read GRO settings. ixgbe: fix WOL register setup for 82599 ixgbe: Fix - Do not allow Rx FC on 82598 at 1G due to errata sfc: Fix SFE4002 initialisation mac80211: fix handling of null-rate control in rate_control_get_rate inet: Remove bogus IGMPv3 report handling iwlwifi: fix AMSDU Rx after paged Rx patch tcp: fix ICMP-RTO war via-velocity: Fix races on shared interrupts via-velocity: Take spinlock on set coalesce via-velocity: Remove unused IRQ status parameter from rx_srv and tx_srv rtl8187: Add new device ID iwmc3200wifi: Test of wrong pointer after kzalloc in iwm_mlme_update_bss_table() ath9k: Fix sequence numbers for PAE frames mac80211: fix deferred hardware scan requests iwlwifi: Fix to set correct ht configuration mac80211: Fix probe request filtering in IBSS mode ... 
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (22 commits)
  be2net: set proper value to version field in req hdr
  xfrm: Fix xfrm_state_clone leak
  ipcomp: Avoid duplicate calls to ipcomp_destroy
  ethtool: allow non-admin user to read GRO settings.
  ixgbe: fix WOL register setup for 82599
  ixgbe: Fix - Do not allow Rx FC on 82598 at 1G due to errata
  sfc: Fix SFE4002 initialisation
  mac80211: fix handling of null-rate control in rate_control_get_rate
  inet: Remove bogus IGMPv3 report handling
  iwlwifi: fix AMSDU Rx after paged Rx patch
  tcp: fix ICMP-RTO war
  via-velocity: Fix races on shared interrupts
  via-velocity: Take spinlock on set coalesce
  via-velocity: Remove unused IRQ status parameter from rx_srv and tx_srv
  rtl8187: Add new device ID
  iwmc3200wifi: Test of wrong pointer after kzalloc in iwm_mlme_update_bss_table()
  ath9k: Fix sequence numbers for PAE frames
  mac80211: fix deferred hardware scan requests
  iwlwifi: Fix to set correct ht configuration
  mac80211: Fix probe request filtering in IBSS mode
  ...
xfrm: Fix xfrm_state_clone leak 2010-02-16T22:53:24+00:00 Herbert Xu herbert@gondor.apana.org.au 2010-02-15T20:00:51+00:00 553f9118abc4fc53674fff87f6fe5fa3f56a41ed xfrm_state_clone calls kfree instead of xfrm_state_put to free a failed state. Depending on the state of the failed state, it can cause leaks to things like module references. All states should be freed by xfrm_state_put past the point of xfrm_init_state. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> 
xfrm_state_clone calls kfree instead of xfrm_state_put to free
a failed state.  Depending on the state of the failed state, it
can cause leaks to things like module references.

All states should be freed by xfrm_state_put past the point of
xfrm_init_state.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
ipcomp: Avoid duplicate calls to ipcomp_destroy 2010-02-16T22:53:24+00:00 Herbert Xu herbert@gondor.apana.org.au 2010-02-15T19:24:30+00:00 10e7454ed7a2da39f1f6255f63d7df27ab4bb67f When ipcomp_tunnel_attach fails we will call ipcomp_destroy twice. This may lead to double-frees on certain structures. As there is no reason to explicitly call ipcomp_destroy, this patch removes it from ipcomp*.c and lets the standard xfrm_state destruction take place. This is based on the discovery and patch by Alexey Dobriyan. Tested-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> 
When ipcomp_tunnel_attach fails we will call ipcomp_destroy twice.
This may lead to double-frees on certain structures.

As there is no reason to explicitly call ipcomp_destroy, this patch
removes it from ipcomp*.c and lets the standard xfrm_state destruction
take place.

This is based on the discovery and patch by Alexey Dobriyan.

Tested-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
ethtool: allow non-admin user to read GRO settings. 2010-02-16T22:53:23+00:00 stephen hemminger shemminger@vyatta.com 2010-02-11T13:48:29+00:00 1cab819b5e244e1b853c7b440981e6a960da3bfb Looks like an oversight in GRO design. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
Looks like an oversight in GRO design.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Merge branch 'master' of ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6 2010-02-14T19:56:38+00:00 David S. Miller davem@davemloft.net 2010-02-14T19:56:38+00:00 3d0beb921fa34ebf8b13e206e5473329b14deb83 






mac80211: fix handling of null-rate control in rate_control_get_rate
2010-02-12T19:50:22+00:00

Juuso Oikarinen
juuso.oikarinen@nokia.com

2010-02-12T08:05:45+00:00

5affcd6ba2036b59a4dee3f0576ae3584e92e4f1

For hardware with IEEE80211_HW_HAS_RATE_CONTROL the rate controller is not
initialized. However, calling functions such as ieee80211_beacon_get result
in the rate_control_get_rate function getting called, which is accessing
(in this case uninitialized) rate control structures unconditionally.

Fix by exiting the function before setting the rates for HW with
IEEE80211_HW_HAS_RATE_CONTROL set. The initialization of the ieee80211_tx_info
struct is intentionally still executed.

Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Kalle Valo <kalle.valo@nokia.com>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>





For hardware with IEEE80211_HW_HAS_RATE_CONTROL the rate controller is not
initialized. However, calling functions such as ieee80211_beacon_get result
in the rate_control_get_rate function getting called, which is accessing
(in this case uninitialized) rate control structures unconditionally.

Fix by exiting the function before setting the rates for HW with
IEEE80211_HW_HAS_RATE_CONTROL set. The initialization of the ieee80211_tx_info
struct is intentionally still executed.

Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Kalle Valo <kalle.valo@nokia.com>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>







inet: Remove bogus IGMPv3 report handling
2010-02-12T19:42:20+00:00

Herbert Xu
herbert@gondor.apana.org.au

2010-02-07T17:26:30+00:00

c6b471e6454c0e1c6d756672841cbaeae7c949f8

Currently we treat IGMPv3 reports as if it were an IGMPv2/v1 report.
This is broken as IGMPv3 reports are formatted differently.  So we
end up suppressing a bogus multicast group (which should be harmless
as long as the leading reserved field is zero).

In fact, IGMPv3 does not allow membership report suppression so
we should simply ignore IGMPv3 membership reports as a host.

This patch does exactly that.  I kept the case statement for it
so people won't accidentally add it back thinking that we overlooked
this case.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>





Currently we treat IGMPv3 reports as if it were an IGMPv2/v1 report.
This is broken as IGMPv3 reports are formatted differently.  So we
end up suppressing a bogus multicast group (which should be harmless
as long as the leading reserved field is zero).

In fact, IGMPv3 does not allow membership report suppression so
we should simply ignore IGMPv3 membership reports as a host.

This patch does exactly that.  I kept the case statement for it
so people won't accidentally add it back thinking that we overlooked
this case.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>