Jan Engelhardt [Sat, 7 Nov 2009 02:08:32 +0000 (18:08 -0800)]
netfilter: xt_connlimit: fix regression caused by zero family value
Commit v2.6.28-rc1~717^2~109^2~2 was slightly incomplete; not all
instances of par->match->family were changed to par->family.
References: http://bugzilla.netfilter.org/show_bug.cgi?id=610 Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Date: Thu, 05 Nov 2009 15:59:16 +0100
From: Holger Schurig <holgerschurig@gmail.com>
To: linux-wireless@vger.kernel.org
Subject: BUG: oops when "rmmod ipw2200"
This happened on wireless-testing v2.6.32-rc6-41575-g5e68bfb. I
modprobed ipw2200, put it into monitor mode, used tshark a while to
monitor, then I stopped tshark, "ifconfig eth2 down" and finally
"rmmod ipw2200", and voila:
Eric Dumazet [Fri, 6 Nov 2009 08:50:39 +0000 (00:50 -0800)]
decnet: netdevice refcount leak
While working on device refcount stuff, I found a device refcount leak
through DECNET.
This nasty bug can be used to hold refcounts on any !DECNET netdevice.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Vitezslav Samel discovered that since 2.6.30.4+ active FTP can not work
over NAT. The "cause" of the problem was a fix of unacknowledged data
detection with NAT (commit a3a9f79e361e864f0e9d75ebe2a0cb43d17c4272).
However, actually, that fix uncovered a long standing bug in TCP conntrack:
when NAT was enabled, we simply updated the max of the right edge of
the segments we have seen (td_end), by the offset NAT produced with
changing IP/port in the data. However, we did not update the other parameter
(td_maxend) which is affected by the NAT offset. Thus that could drift
away from the correct value and thus resulted breaking active FTP.
The patch below fixes the issue by *not* updating the conntrack parameters
from NAT, but instead taking into account the NAT offsets in conntrack in a
consistent way. (Updating from NAT would be more harder and expensive because
it'd need to re-calculate parameters we already calculated in conntrack.)
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
The bridge code assumes ethernet addressing, so be more strict in
the what is allowed. This showed up when GRE had a bug and was not
using correct address format.
Add some more comments for increased clarity.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
introduced the first reference to __devexit in struct virtio_driver
virtio_net which upset modpost ("Section mismatch in reference from the
variable virtio_net to the function .devexit.text:virtnet_remove()").
Fix this by renaming virtio_net to virtio_net_driver.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reported-by: Michael S. Tsirkin <mst@redhat.com> Blame-taken-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Larry Finger [Wed, 4 Nov 2009 06:00:25 +0000 (00:00 -0600)]
rtl8187: Fix kernel oops when device is removed when LEDS enabled
As reported by Rick Farina (sidhayn@gmail.com), removing the RTL8187
USB stick, or unloading the driver rtl8187 using rmmod will cause a
kernel oops. There are at least two forms of the failure, (1) BUG:
Scheduling while atomic, and (2) a fatal kernel page fault. This
problem is reported in Bugzilla #14539.
This problem does not occur for kernel 2.6.31, but does for 2.6.32-rc2,
thus it is technically a regression; however, bisection did not locate
any faulty patch. The fix was found by comparing the faulty code in
rtl8187 with p54usb. My interpretation is that the handling of work
queues in mac80211 changed enough to the LEDs to be unregistered
before tasks on the work queues are cancelled. Previously, these
actions could be done in either order.
(Herton Ronaldo Krzesinski <herton@mandriva.com.br> reports that the
code is the same in 2.6.31, so this may be a candidate for 2.6.31.x.
-- JWL)
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Reported-by: Rick Farina <sidhayn@gmail.com> Tested-by: Rick Farina <sidhayn@gmail.com> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
Roel Kluin [Wed, 4 Nov 2009 16:31:59 +0000 (08:31 -0800)]
isdn: hfc_usb: Fix read buffer overflow
Check whether index is within bounds before testing the element.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Cc: Karsten Keil <isdn@linux-pingi.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Roel Kluin [Wed, 4 Nov 2009 16:31:19 +0000 (08:31 -0800)]
isdn: hisax: Fix test in waitforxfw
The negation makes it a bool before the comparison and hence it
will never be 0x40.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Cc: Karsten Keil <isdn@linux-pingi.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Dan Carpenter [Wed, 4 Nov 2009 16:27:09 +0000 (08:27 -0800)]
misdn: Fix reversed 'if' in st_own_ctrl
The current code probably returns -EINVAL a lot. Otherwise it would oops.
Compile tested only. Found by smatch (http://repo.or.cz/w/smatch.git).
Signed-off-by: Dan Carpenter <error27@gmail.com> Cc: Karsten Keil <isdn@linux-pingi.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Jiri Slaby [Wed, 4 Nov 2009 16:25:57 +0000 (08:25 -0800)]
isdn: hisax: Fix lock imbalance.
Add omittted unlocks to 2 functions.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Cc: Karsten Keil <Karsten-Keil@t-online.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Johannes Berg [Sun, 1 Nov 2009 18:25:40 +0000 (19:25 +0100)]
mac80211: check interface is down before type change
For some strange reason the netif_running() check
ended up after the actual type change instead of
before, potentially causing all kinds of problems
if the interface is up while changing the type;
one of the problems manifests itself as a warning:
WARNING: at net/mac80211/iface.c:651 ieee80211_teardown_sdata+0xda/0x1a0 [mac80211]()
Hardware name: Aspire one
Pid: 2596, comm: wpa_supplicant Tainted: G W 2.6.31-10-generic #32-Ubuntu
Call Trace:
[] warn_slowpath_common+0x6d/0xa0
[] warn_slowpath_null+0x15/0x20
[] ieee80211_teardown_sdata+0xda/0x1a0 [mac80211]
[] ieee80211_if_change_type+0x4a/0xc0 [mac80211]
[] ieee80211_change_iface+0x61/0xa0 [mac80211]
[] cfg80211_wext_siwmode+0xc7/0x120 [cfg80211]
[] ioctl_standard_call+0x58/0xf0
Cc: Arjan van de Ven <arjan@infradead.org> Cc: stable@kernel.org Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
introduced a potential NULL pointer dereference that
some people have been hitting for some reason -- the
params.bssid pointer is not guaranteed to be non-NULL
for what seems to be a race between various ways of
reaching the same thing.
While I'm trying to analyse the problem more let's
first fix the crash. I think the real fix may be to
avoid doing _anything_ if it ended up being NULL, but
right now I'm not sure yet.
I think
http://bugzilla.kernel.org/show_bug.cgi?id=14342
might also be this issue.
Reported-by: Parag Warudkar <parag.lkml@gmail.com> Tested-by: Parag Warudkar <parag.lkml@gmail.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
David Woodhouse [Fri, 30 Oct 2009 17:45:14 +0000 (17:45 +0000)]
libertas if_usb: Fix crash on 64-bit machines
On a 64-bit kernel, skb->tail is an offset, not a pointer. The libertas
usb driver passes it to usb_fill_bulk_urb() anyway, causing interesting
crashes. Fix that by using skb->data instead.
This highlights a problem with usb_fill_bulk_urb(). It doesn't notice
when dma_map_single() fails and return the error to its caller as it
should. In fact it _can't_ currently return the error, since it returns
void.
So this problem was showing up only at unmap time, after we'd already
suffered memory corruption by doing DMA to a bogus address.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Cc: stable@kernel.org Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Thu, 29 Oct 2009 09:09:28 +0000 (10:09 +0100)]
mac80211: fix reason code output endianness
When HT debugging is enabled and we receive a DelBA
frame we print out the reason code in the wrong byte
order. Fix that so we don't get weird values printed.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
downgraded an ASSERT to a WARN_ON() but also misplaced a
semicolon at the end of the second check. What this did
was force the rate control code to always return the rate
even if we should have warned about it. Since this should
not have happened anymore anyway this fix isn't critical
as the proper rate would have been returned anyway.
Cc: stable@kernel.org Reported-by: Jiri Slaby <jirislaby@gmail.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Michael Buesch [Wed, 28 Oct 2009 21:08:13 +0000 (22:08 +0100)]
b43: Fix DMA TX bounce buffer copying
b43 allocates a bouncebuffer, if the supplied TX skb is in an invalid
memory range for DMA.
However, this is broken in that it fails to copy over some metadata to the
new skb.
This patch fixes three problems:
* Failure to adjust the ieee80211_tx_info pointer to the new buffer.
This results in a kmemcheck warning.
* Failure to copy the skb cb, which contains ieee80211_tx_info, to the new skb.
This results in breakage of various TX-status postprocessing (Rate control).
* Failure to transfer the queue mapping.
This results in the wrong queue being stopped on saturation and can result in queue overflow.
Signed-off-by: Michael Buesch <mb@bu3sch.de> Tested-by: Christian Casteyde <casteyde.christian@free.fr> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Zhu Yi [Thu, 15 Oct 2009 06:50:28 +0000 (14:50 +0800)]
ipw2200: fix oops on missing firmware
For non-monitor interfaces, the syntax for alloc_ieee80211/free_80211
is wrong. Because alloc_ieee80211 only creates (wiphy_new) a wiphy, but
free_80211() does wiphy_unregister() also. This is only correct when
the later wiphy_register() is called successfully, which apparently
is not the case for your fw doesn't exist one.
Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Herbert Xu [Fri, 30 Oct 2009 05:51:48 +0000 (05:51 +0000)]
gre: Fix dev_addr clobbering for gretap
Nathan Neulinger noticed that gretap devices get their MAC address
from the local IP address, which results in invalid MAC addresses
half of the time.
This is because gretap is still using the tunnel netdev ops rather
than the correct tap netdev ops struct.
This patch also fixes changelink to not clobber the MAC address
for the gretap case.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Stephen Hemminger <shemminger@vyatta.com> Tested-by: Nathan Neulinger <nneul@mst.edu> Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Fri, 30 Oct 2009 05:03:53 +0000 (05:03 +0000)]
net: fix sk_forward_alloc corruption
On UDP sockets, we must call skb_free_datagram() with socket locked,
or risk sk_forward_alloc corruption. This requirement is not respected
in SUNRPC.
Add a convenient helper, skb_free_datagram_locked() and use it in SUNRPC
Reported-by: Francis Moreau <francis.moro@gmail.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Bruce Allan [Thu, 29 Oct 2009 13:46:05 +0000 (13:46 +0000)]
e1000e: rework disable K1 at 1000Mbps for 82577/82578
This patch reworks a previous workaround (commit 7d3cabbcc) for an issue
in hardware where noise on the interconnect between the MAC and PHY could
be generated by a lower power mode (K1) at 1000Mbps resulting in bad
packets. Disable K1 while at 1000 Mbps but keep it enabled for 10/100Mbps
and when the cable is disconnected. The original version of this
workaround was found to be incomplete.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Bruce Allan [Thu, 29 Oct 2009 13:45:45 +0000 (13:45 +0000)]
e1000e: config PHY via software after resets
On PCH-based (82577/82578) and some ICH8-based parts (82566) there is an
issue with the hardware automatically configuring the PHY with contents
from the EEPROM after the PHY is reset, so do the configuration by the
driver instead. This was already similarly done for some 82566 parts in
e1000_phy_hw_reset_ich8lan() but needs to be done after other resets,
so move the PHY configuration code to its own function and call after
all PHY resets.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Bruce Allan [Thu, 29 Oct 2009 13:42:41 +0000 (13:42 +0000)]
e100: e100_phy_init() isolates selected PHY, causes 10 second boot delay
A change in how PHYs are electrically isolated caused all PHYs to be
isolated followed by reverting that isolation for the selected PHY.
Unfortunately, isolating the selected PHY for even a short period of
time can result in DHCP negotiation taking more than 10 seconds on certain
embedded configurations delaying boot time as reported by Bernhard Kaindl.
This patch reverts the change to how PHYs are isolated yet still works
around the issue for 82552 needing the selected PHY's BMCR register to
be written after the unused PHYs are isolated. This code is moved below
the setting of nic->phy ID in order to do the 82552-specific workaround.
Cc: Bernhard Kaindl <bernhard.kaindl@gmx.net> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Gabor Gombas [Thu, 29 Oct 2009 10:19:11 +0000 (03:19 -0700)]
net: Fix 'Re: PACKET_TX_RING: packet size is too long'
Currently PACKET_TX_RING forces certain amount of every frame to remain
unused. This probably originates from an early version of the
PACKET_TX_RING patch that in fact used the extra space when the (since
removed) CONFIG_PACKET_MMAP_ZERO_COPY option was enabled. The current
code does not make any use of this extra space.
This patch removes the extra space reservation and lets userspace make
use of the full frame size.
Signed-off-by: Gabor Gombas <gombasg@sztaki.hu> Signed-off-by: David S. Miller <davem@davemloft.net>
netdev: usb: dm9601.c can drive a device not supported yet, add support for it
I found that the current version of drivers/net/usb/dm9601.c can be used to
successfully drive a low-power, low-cost network adapter with USB ID
0a46:9000, based on a DM9000E chipset. As no device with this ID is yet
present in the kernel, I have created a patch that adds support for the device
to the dm9601 driver.
Created and tested against linux-2.6.32-rc5.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Acked-by: Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
Ron Mercer [Wed, 28 Oct 2009 08:39:21 +0000 (08:39 +0000)]
qlge: Fix firmware mailbox command timeout.
The mailbox command process would only process a maximum of 5 unrelated
firmware events while waiting for it's command completion status.
It should process an unlimited number of events while waiting for a maximum of 5 seconds.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Neil Horman [Wed, 28 Oct 2009 08:59:47 +0000 (08:59 +0000)]
AF_RAW: Augment raw_send_hdrinc to expand skb to fit iphdr->ihl (v2)
Augment raw_send_hdrinc to correct for incorrect ip header length values
A series of oopses was reported to me recently. Apparently when using AF_RAW
sockets to send data to peers that were reachable via ipsec encapsulation,
people could panic or BUG halt their systems.
I've tracked the problem down to user space sending an invalid ip header over an
AF_RAW socket with IP_HDRINCL set to 1.
Basically what happens is that userspace sends down an ip frame that includes
only the header (no data), but sets the ip header ihl value to a large number,
one that is larger than the total amount of data passed to the sendmsg call. In
raw_send_hdrincl, we allocate an skb based on the size of the data in the msghdr
that was passed in, but assume the data is all valid. Later during ipsec
encapsulation, xfrm4_tranport_output moves the entire frame back in the skbuff
to provide headroom for the ipsec headers. During this operation, the
skb->transport_header is repointed to a spot computed by
skb->network_header + the ip header length (ihl). Since so little data was
passed in relative to the value of ihl provided by the raw socket, we point
transport header to an unknown location, resulting in various crashes.
This fix for this is pretty straightforward, simply validate the value of of
iph->ihl when sending over a raw socket. If (iph->ihl*4U) > user data buffer
size, drop the frame and return -EINVAL. I just confirmed this fixes the
reported crashes.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Jiri Bohac [Thu, 29 Oct 2009 05:23:54 +0000 (22:23 -0700)]
bonding: fix a race condition in calls to slave MII ioctls
In mii monitor mode, bond_check_dev_link() calls the the ioctl
handler of slave devices. It stores the ndo_do_ioctl function
pointer to a static (!) ioctl variable and later uses it to call the
handler with the IOCTL macro.
If another thread executes bond_check_dev_link() at the same time
(even with a different bond, which none of the locks prevent), a
race condition occurs. If the two racing slaves have different
drivers, this may result in one driver's ioctl handler being
called with a pointer to a net_device controlled with a different
driver, resulting in unpredictable breakage.
Unless I am overlooking something, the "static" must be a
copy'n'paste error (?).
Signed-off-by: Jiri Bohac <jbohac@suse.cz> Signed-off-by: David S. Miller <davem@davemloft.net>
virtio net used to unlink skbs from send queues on error,
but ever since 48925e372f04f5e35fec6269127c62b2c71ab794
we do not do this. This causes guest data corruption and crashes
with vhost since net core can requeue the skb or free it without
it being taken off the list.
This patch fixes this by queueing the skb after successful
transmit.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Ben Hutchings [Wed, 28 Oct 2009 10:43:49 +0000 (03:43 -0700)]
sfc: Set ip_summed correctly for page buffers passed to GRO
Page buffers containing packets with an incorrect checksum or using a
protocol not handled by hardware checksum offload were previously not
passed to LRO. The conversion to GRO changed this, but did not set
the ip_summed value accordingly.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Björn Smedman [Sat, 24 Oct 2009 18:55:09 +0000 (20:55 +0200)]
mac80211: fix for incorrect sequence number on hostapd injected frames
When hostapd injects a frame, e.g. an authentication or association
response, mac80211 looks for a suitable access point virtual interface
to associate the frame with based on its source address. This makes it
possible e.g. to correctly assign sequence numbers to the frames.
A small typo in the ethernet address comparison statement caused a
failure to find a suitable ap interface. Sequence numbers on such
frames where therefore left unassigned causing some clients
(especially windows-based 11b/g clients) to reject them and fail to
authenticate or associate with the access point. This patch fixes the
typo in the address comparison statement.
Signed-off-by: Björn Smedman <bjorn.smedman@venatech.se> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Tue, 20 Oct 2009 06:08:53 +0000 (15:08 +0900)]
cfg80211: sme: deauthenticate on assoc failure
When the in-kernel SME gets an association failure from
the AP we don't deauthenticate, and thus get into a very
confused state which will lead to warnings later on. Fix
this by actually deauthenticating when the AP indicates
an association failure.
(Brought to you by the hacking session at Kernel Summit 2009 in Tokyo,
Japan. -- JWL)
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Tue, 20 Oct 2009 06:08:12 +0000 (15:08 +0900)]
mac80211: keep auth state when assoc fails
When association fails, we should stay authenticated,
which in mac80211 is represented by the existence of
the mlme work struct, so we cannot free that, instead
we need to just set it to idle.
(Brought to you by the hacking session at Kernel Summit 2009 in Tokyo,
Japan. -- JWL)
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reinette Chatre [Mon, 19 Oct 2009 21:55:37 +0000 (14:55 -0700)]
mac80211: fix ibss joining
Recent commit "mac80211: fix logic error ibss merge bssid check" fixed
joining of ibss cell when static bssid is provided. In this case
ifibss->bssid is set before the cell is joined and comparing that address
to a bss should thus always succeed. Unfortunately this change broke the
other case of joining a ibss cell without providing a static bssid where
the value of ifibss->bssid is not set before the cell is joined.
Since ifibss->bssid may be set before or after joining the cell we do not
learn anything by comparing it to a known bss. Remove this check.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Larry Finger [Fri, 16 Oct 2009 15:18:09 +0000 (10:18 -0500)]
b43: Fix Bugzilla #14181 and the bug from the previous 'fix'
"b43: Fix PPC crash in rfkill polling on unload" fixed the bug reported
in Bugzilla No. 14181; however, it introduced a new bug. Whenever the
radio switch was turned off, it was necessary to unload and reload
the driver for it to recognize the switch again.
This patch fixes both the original bug in #14181 and the bug introduced by
the previous patch. It must be stated, however, that if there is a BCM4306/3
with an rfkill switch (not yet proven), then the driver will need an
unload/reload cycle to turn the device back on.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Benoit PAPILLAULT <benoit.papillault@free.fr> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Michal Ostrowski [Mon, 26 Oct 2009 23:23:20 +0000 (16:23 -0700)]
PPPoE: Fix flush/close races.
Be more careful about the state of pointers during tear-down.
The "pppoe_dev" field can only be looked at safely while holding socket locks.
This subsequently allows for the flush_lock to be killed.
We depend on the PPPOX_CONNECTED state to tell us that that those fields are
valid, so whoever clears that state (pppox_unbind_sock()) is responsible for
the dev_put() call.
We also have to ensure that we delete_item() on all sockets before they are
cleaned up.
The need for these changes has been exposed by scenarios wherein namespace
bindings of ethernet devices change while there are ongoing PPPoE sessions,
which resulted in oopses due to unusual socket connection termination paths,
exposing these issues.
Bruce Allan [Mon, 26 Oct 2009 11:24:02 +0000 (11:24 +0000)]
e1000e: allow for swflag to be held over consecutive PHY accesses
PCH-based parts (82577/82578) and some ICH8-based parts (82566) need to
hold the swflag (sw/fw/hw hardware semaphore) over consecutive PHY accesses
in order to perform sw-driven PHY configuration during initialization to
workaround known hardware issues (see follow-on patch). This patch
provides new PHY read/write functions (and function pointers) that will
allow accessing the PHY registers assuming the swflag has already been
acquired. The actual PHY register access code has moved into helper
functions that are called with a flag indicating whether or not the swflag
has already been acquired and acquires/releases it if not.
The functions called from within the updated PHY access functions had to be
updated to assume the swflag was already acquired, and other functions that
called those functions were also updated to acquire/release the swflag.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Bruce Allan [Mon, 26 Oct 2009 11:23:43 +0000 (11:23 +0000)]
e1000e: separate mutex usage between NVM and PHY/CSR register for ICHx/PCH
Accesses to NVM and PHY/CSR registers on ICHx/PCH-based parts are protected
from concurrent accesses with a mutex that is acquired when the access is
initiated and released when the access has completed. However, the two
types of accesses should not be protected by the same mutex because the
driver may have to access the NVM while already holding the mutex over
several consecutive PHY/CSR accesses which would result in livelock.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Bruce Allan [Mon, 26 Oct 2009 11:23:25 +0000 (11:23 +0000)]
e1000e: 82577/82578 requires a different method to configure LPLU
Unlike previous ICHx-based parts, the PCH-based parts (82577/82578) require
LPLU (Low Power Link Up, or "reverse auto-negotiation") to be configured in
the PHY rather than the MAC.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Bruce Allan [Mon, 26 Oct 2009 11:23:06 +0000 (11:23 +0000)]
e1000e: increase swflag acquisition timeout for ICHx/PCH
In some conditions (e.g. when AMT is enabled on the system), it is possible
to take an extended period of time to for the driver to acquire the sw/fw/hw
hardware semaphore used to protect against concurrent access of a shared
resource (e.g. PHY registers). This could cause PHY registers to not get
configured properly resulting in link issues.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Bruce Allan [Mon, 26 Oct 2009 11:22:47 +0000 (11:22 +0000)]
e1000e: clear PHY wakeup bit after LCD reset on 82577/82578
Performing a dummy read of the PHY Wakeup Control (WUC) register clears the
wakeup enable bit set by an PHY reset. If this bit remains set, link
problems may occur.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Alexander Duyck [Mon, 26 Oct 2009 11:32:25 +0000 (11:32 +0000)]
igbvf: fix memory leak when ring size changed while interface down
This patch resolves a memory leak which occurs while changing the ring size
while the interface is down.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Alexander Duyck [Mon, 26 Oct 2009 11:32:05 +0000 (11:32 +0000)]
ixgbe: fix memory leak when resizing rings while interface is down
This patch resolves a memory leak that occurs when you resize the rings via
the ethtool -G option while the interface is down.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Alexander Duyck [Mon, 26 Oct 2009 11:31:47 +0000 (11:31 +0000)]
igb: fix memory leak when setting ring size while interface is down
Changing ring sizes while the interface was down was causing a double
allocation of the receive and transmit rings. This issue is amplified when
there are multiple rings enabled. To prevent this we need to add an
additional check which will just update the ring counts when the interface
is not up and skip the allocation steps.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Jasper Spaans [Fri, 23 Oct 2009 04:08:46 +0000 (04:08 +0000)]
bonding: Modify hash transmit policies to use the packet's source MAC address
Modify bonding hash transmit policies to use the psource MAC address of
the packet instead of the MAC address configured for the bonding device.
The old sitation conflicts with the documentation.
Signed-off-by: Jasper Spaans <spaans@fox-it.com> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Simon Wunderlich [Sat, 24 Oct 2009 13:47:33 +0000 (06:47 -0700)]
r8169: fix Ethernet Hangup for RTL8110SC rev d
The 8110SC rev d chip on our board shows a regression which the 8110SB chip
did not have. When inbound traffic is overflowing the receive descriptor queue,
"holes" in the ring buffer may occur which lead to a hangup until the buffer
is filled again. The packets are than completely processed, but the ring
remains porous and no packets are processed until the next overflow. Setting
the interface down and up can fix the problem temporary from userspace.
For some reason we don't know, this behaviour is not occuring if the RxVlan
bit for hardware VLAN untagging is set. There is another "Work around for
AMD plateform" in the current code which checks the VLAN status
word in receive descriptors, but does never come to effect when hardware
VLAN support is enabled. We assume that this is a bug in the chip.
The following patch fixes the problem. Without the patch we could reproduce
the hang within minutes (given other devices also generating lots of
interrupts), without we couldn't reproduce within a few days of long term
testing.
This version contains minor style adjustments and is sent with mutt which
will hopefully not destroy the formatting again.
Signed-off-by: Bernhard Schmidt <bernhard.schmidt@saxnet.de> Signed-off-by: Simon Wunderlich <simon.wunderlich@saxnet.de> Acked-by: Francois Romieu <romieu@zoreil.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Manuel Lauss [Sat, 17 Oct 2009 02:00:07 +0000 (02:00 +0000)]
net: au1000_eth: add missing capability.h
fixes the following build failure:
CC drivers/net/au1000_eth.o
/drivers/net/au1000_eth.c: In function 'au1000_set_settings':
/drivers/net/au1000_eth.c:623: error: implicit declaration of function 'capable'
/drivers/net/au1000_eth.c:623: error: 'CAP_NET_ADMIN' undeclared (first use in this function)
/drivers/net/au1000_eth.c:623: error: (Each undeclared identifier is reported only once
/drivers/net/au1000_eth.c:623: error: for each function it appears in.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Arjan van de Ven [Fri, 23 Oct 2009 04:37:56 +0000 (21:37 -0700)]
net: use WARN() for the WARN_ON in commit b6b39e8f3fbbb
Commit b6b39e8f3fbbb (tcp: Try to catch MSG_PEEK bug) added a printk()
to the WARN_ON() that's in tcp.c. This patch changes this combination
to WARN(); the advantage of WARN() is that the printk message shows up
inside the message, so that kerneloops.org will collect the message.
In addition, this gets rid of an extra if() statement.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Bruce Allan [Fri, 23 Oct 2009 04:22:18 +0000 (21:22 -0700)]
e1000e: reset the PHY on 82577/82578 when going to Sx
The PHY on 82577/82578 parts needs a soft reset when transitioning to Sx
state in order for the PHY write which disables gigabit speed to take
effect. Gigabit speed must be disabled in order for the PHY writes to
registers on page 800 (the wakeup control registers) to work as expected
otherwise the system might not wake via WoL.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.32-rc4-testing #7
-------------------------------------------------------
ipppd/28379 is trying to acquire lock:
(&netdev->queue_lock){......}, at: [<e62ad0fd>] isdn_net_device_busy+0x2c/0x74 [isdn]
but task is already holding lock:
(&netdev->local->xmit_lock){+.....}, at: [<e62aefc2>] isdn_net_write_super+0x3f/0x6e [isdn]
which lock already depends on the new lock.
.......
We don't need to lock nd->queue->xmit_lock to protect single
isdn_net_lp_busy(). This can fix above lockdep warnings.
Reported-and-tested-by: Tilman Schmidt <tilman@imap.cc> Signed-off-by: Xiaotian Feng <xtfeng@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Dhananjay Phadke [Wed, 21 Oct 2009 19:39:03 +0000 (19:39 +0000)]
netxen: avoid undue board config check
Old code assumed board config version in the flash to be 1.
When this will get changed by tools, driver just refuses to
attach. This is unnecessary since driver does not have to
parse board config structure directly (maintained by firmware).
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Clear NX_RESETING bit in netxen_tx_timeout_task() so that
the firmware watchdog task can catch need_reset request
from tx timeout.
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ben Dooks [Mon, 19 Oct 2009 23:49:05 +0000 (23:49 +0000)]
KS8851: Fix ks8851_set_rx_mode() for IFF_MULTICAST
In ks8851_set_rx_mode() the case handling IFF_MULTICAST was also setting
the RXCR1_AE bit by accident. This meant that all unicast frames where
being accepted by the device. Remove RXCR1_AE from this case.
Note, RXCR1_AE was also masking a problem with setting the MAC address
properly, so needs to be applied after fixing the MAC write order.
Fixes a bug reported by Doong, Ping of Micrel. This version of the
patch avoids setting RXCR1_ME for all cases.
Signed-off-by: Ben Dooks <ben@simtec.co.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
Ben Dooks [Mon, 19 Oct 2009 23:49:04 +0000 (23:49 +0000)]
KS8851: Fix MAC address write order
The MAC address register was being written in the wrong order, so add
a new address macro to convert mac-address byte to register address and
a ks8851_wrreg8() function to write each byte without having to worry
about any difficult byte swapping.
Fixes a bug reported by Doong, Ping of Micrel.
Signed-off-by: Ben Dooks <ben@simtec.co.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
Ben Dooks [Mon, 19 Oct 2009 23:49:03 +0000 (23:49 +0000)]
KS8851: Add soft reset at probe time
Issue a full soft reset at probe time.
This was reported by Doong Ping of Micrel, but no explanation of why this
is necessary or what bug it is fixing. Add it as it does not seem to hurt
the current driver and ensures that the device is in a known state when we
start setting it up.
Signed-off-by: Ben Dooks <ben@simtec.co.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
Herbert Xu [Mon, 19 Oct 2009 19:41:06 +0000 (19:41 +0000)]
tcp: Try to catch MSG_PEEK bug
This patch tries to print out more information when we hit the
MSG_PEEK bug in tcp_recvmsg. It's been around since at least
2005 and it's about time that we finally fix it.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Reported-by: Oliver Hartkopp <oliver@hartkopp.net> Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Tested-by: Oliver Hartkopp <oliver@hartkopp.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Julian Anastasov [Mon, 19 Oct 2009 10:10:40 +0000 (10:10 +0000)]
tcp: fix TCP_DEFER_ACCEPT retrans calculation
Fix TCP_DEFER_ACCEPT conversion between seconds and
retransmission to match the TCP SYN-ACK retransmission periods
because the time is converted to such retransmissions. The old
algorithm selects one more retransmission in some cases. Allow
up to 255 retransmissions.
Signed-off-by: Julian Anastasov <ja@ssi.bg> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Julian Anastasov [Mon, 19 Oct 2009 10:03:58 +0000 (10:03 +0000)]
tcp: reduce SYN-ACK retrans for TCP_DEFER_ACCEPT
Change SYN-ACK retransmitting code for the TCP_DEFER_ACCEPT
users to not retransmit SYN-ACKs during the deferring period if
ACK from client was received. The goal is to reduce traffic
during the deferring period. When the period is finished
we continue with sending SYN-ACKs (at least one) but this time
any traffic from client will change the request to established
socket allowing application to terminate it properly.
Also, do not drop acked request if sending of SYN-ACK fails.
Signed-off-by: Julian Anastasov <ja@ssi.bg> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Julian Anastasov [Mon, 19 Oct 2009 10:01:56 +0000 (10:01 +0000)]
tcp: accept socket after TCP_DEFER_ACCEPT period
Willy Tarreau and many other folks in recent years
were concerned what happens when the TCP_DEFER_ACCEPT period
expires for clients which sent ACK packet. They prefer clients
that actively resend ACK on our SYN-ACK retransmissions to be
converted from open requests to sockets and queued to the
listener for accepting after the deferring period is finished.
Then application server can decide to wait longer for data
or to properly terminate the connection with FIN if read()
returns EAGAIN which is an indication for accepting after
the deferring period. This change still can have side effects
for applications that expect always to see data on the accepted
socket. Others can be prepared to work in both modes (with or
without TCP_DEFER_ACCEPT period) and their data processing can
ignore the read=EAGAIN notification and to allocate resources for
clients which proved to have no data to send during the deferring
period. OTOH, servers that use TCP_DEFER_ACCEPT=1 as flag (not
as a timeout) to wait for data will notice clients that didn't
send data for 3 seconds but that still resend ACKs.
Thanks to Willy Tarreau for the initial idea and to
Eric Dumazet for the review and testing the change.
Signed-off-by: Julian Anastasov <ja@ssi.bg> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
projects / mv-sheeva.git / log