Migrate from the legacy PM hooks to use dev_pm_ops structure.
Signed-off-by: Chaithrika U S <chaithrika@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This introduced a problem that can happen if the TX ring size
is increased. We need to size the PCI pool using cbs->max
instead of the default cbs->count value.
Signed-off-by: David S. Miller <davem@davemloft.net>
Joe Perches [Sat, 13 Mar 2010 20:26:15 +0000 (12:26 -0800)]
drivers/net/tulip/eeprom.c: fix bogus "(null)" in tulip init messages
On Wed, 2010-03-10 at 08:41 -0800, David Miller wrote:
> From: Mikael Pettersson <mikpe@it.uu.se>
> Date: Wed, 10 Mar 2010 16:33:28 +0100
> > Booting 2.6.34-rc1 on a machine with a tulip nic I see
> > a number of kernel messages that include "(null)" where
> > previous kernels included the string "tulip0":
> CC:'ing the guilty party :-) It's one of the following
> commits:
Thanks Mikael.
Anonymity has some good attributes.
Blame avoidance is one of them.
I've broad shoulders. It's me, then Dwight Howard...
There might be another few of these where ->name or ->dev
was used before struct device or net_device was registered.
I'll go back and check.
Herbert Xu [Sat, 13 Mar 2010 20:23:29 +0000 (12:23 -0800)]
ipv6: Send netlink notification when DAD fails
If we are managing IPv6 addresses using DHCP, it would be nice
for user-space to be notified if an address configured through
DHCP fails DAD. Otherwise user-space would have to poll to see
whether DAD succeeds.
This patch uses the existing notification mechanism and simply
hooks it into the DAD failure code path.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Fri, 12 Mar 2010 08:00:17 +0000 (00:00 -0800)]
ipconfig: Handle devices which take some time to come up.
Some network devices, particularly USB ones, take several seconds to
fully init and appear in the device list.
If the user turned ipconfig on, they are using it for NFS root or some
other early booting purpose. So it makes no sense to just flat out
fail immediately if the device isn't found.
It also doesn't make sense to just jack up the initial wait to
something crazy like 10 seconds.
Instead, poll immediately, and then periodically once a second,
waiting for a usable device to appear. Fail after 12 seconds.
Signed-off-by: David S. Miller <davem@davemloft.net> Tested-by: Christian Pellegrin <chripell@fsfe.org>
Juuso Oikarinen [Tue, 9 Mar 2010 12:25:02 +0000 (14:25 +0200)]
mac80211: Fix (dynamic) power save entry
Currently hardware with !IEEE80211_HW_PS_NULLFUNC_STACK and
IEEE80211_HW_REPORTS_TX_ACK_STATUS will never enter PSM due to the
conditions in the power save entry functions.
Fix those conditions.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
Zhu Yi [Tue, 9 Mar 2010 08:05:31 +0000 (16:05 +0800)]
ipw2200: use kmalloc for large local variables
Fixed below compiler warning:
drivers/net/wireless/ipw2x00/ipw2200.c: In function ‘ipw_load_firmware’:
drivers/net/wireless/ipw2x00/ipw2200.c:3260: warning: the frame size of
1168 bytes is larger than 1024 bytes
Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bruno Randolf [Tue, 9 Mar 2010 07:56:10 +0000 (16:56 +0900)]
ath5k: read eeprom IQ calibration values correctly for G mode
we read the IQ correction values (i_cal and q_cal) for G mode from a wrong
location (the same shifts as for A mode is applied which is incorrect). use
correct locations, matching the docs and HAL sources.
also we should write IQ correction only when we have that information in the
EEPROM, starting from version 4. also write it in the same way as we do in the
periodic recalibration (enable last), just to be sure.
Signed-off-by: Bruno Randolf <br1@einfach.org> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bruno Randolf [Tue, 9 Mar 2010 07:56:05 +0000 (16:56 +0900)]
ath5k: fix I/Q calibration (for real)
I/Q calibration was completely broken, resulting in a high number of CRC errors
on received packets. before i could see around 10% to 20% CRC errors, with this
patch they are between 0% and 3%.
1.) the removal of the mask in commit "ath5k: Fix I/Q calibration
(f1cf2dbd0f798b71b1590e7aca6647f2caef1649)" resulted in no mask beeing used
when writing the I/Q values into the register. additional errors in the
calculation of the values (see 2.) resulted too high numbers, exceeding the
masks, so wrong values like 0xfffffffe were written. to be safe we should
always use the bitmask when writing parts of a register.
2.) using a (s32) cast for q_coff is a wrong conversion to signed, since we
convert to a signed value later by substracting 128. this resulted in too low
numbers for Q many times, which were limited to -16 by the boundary check later
on.
3.) checked everything against the HAL sources and took over comments and minor
optimizations from there.
4.) we can't use ENABLE_BITS when we want to write a number (the number can
contain zeros). also always write the correction values first and set ENABLE
bit last, like the HAL does.
Signed-off-by: Bruno Randolf <br1@einfach.org> Cc: stable@kernel.org Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bruno Randolf [Tue, 9 Mar 2010 07:55:33 +0000 (16:55 +0900)]
ath5k: fix TSF reset
to reset the TSF, AR5K_BEACON_RESET_TSF has to be 1, not 0. also we have a
function for that so use it.
Signed-off-by: Bruno Randolf <br1@einfach.org> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bruno Randolf [Tue, 9 Mar 2010 07:55:23 +0000 (16:55 +0900)]
ath5k: use fixed antenna for tx descriptors
when using a fixed antenna we should use the antenna number in all tx
descriptors, otherwise the hardware will sometimes send the frame out on the
other antenna. it seems like the hardware does not always respect the default
antenna and diversity settings (esp. AR5K_STA_ID1_DEFAULT_ANTENNA).
also i would like to note that antenna diversity does not always work correctly
on 5414 (at least) when only one antenna is connected: for example all frames
might be received on antenna A but still the HW tries to send on antenna B some
times, causing packet loss.
this is both verified with the antenna statistics output of the previous patch
and a spectrum analyzer.
Signed-off-by: Bruno Randolf <br1@einfach.org> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Zhu Yi [Mon, 8 Mar 2010 05:18:03 +0000 (13:18 +0800)]
libipw: split ieee->networks into small pieces
The ieee->networks consists of 128 struct libipw_network entries. If
we allocate this chunk of memory altogether, it ends up with an
order 4 page allocation. High order page allocation is likely to fail
on system high load. This patch splits the big chunk memory allocation
into small pieces, each is 344 bytes, allocates them with 128 times.
The patch fixed bug http://bugzilla.kernel.org/show_bug.cgi?id=14989
Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jouni Malinen [Sat, 6 Mar 2010 16:35:08 +0000 (18:35 +0200)]
mac80211: Fix sta_mtx unlocking on insert STA failure path
Commit 34e895075e21be3e21e71d6317440d1ee7969ad0 introduced sta_mtx
locking into sta_info_insert() (now sta_info_insert_rcu), but forgot
to unlock this mutex on one of the error paths. Fix this by adding
the missing mutex_unlock() call for the case where STA insert fails
due to an entry existing already. This may happen at least in AP mode
when a STA roams between two BSSes (vifs).
Signed-off-by: Jouni Malinen <j@w1.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Helmut Schaa [Fri, 5 Mar 2010 16:44:22 +0000 (17:44 +0100)]
rt2x00: remove KSEG1ADDR define from rt2x00soc.h
Remove the KSEG1ADDR define from rt2x00soc.h as it redefines and covers the
correct one from the arch/mips/include/asm/addrspace.h. Otherwise the driver
oopses on the target platform (Ralink rt3050 board).
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jussi Kivilinna [Tue, 9 Mar 2010 12:24:38 +0000 (12:24 +0000)]
asix: fix setting mac address for AX88772
Setting new MAC address only worked when device was set to promiscuous mode.
Fix MAC address by writing new address to device using undocumented command
AX_CMD_READ_NODE_ID+1. Patch is tested with AX88772 device.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Acked-by: David Hollis <dhollis@davehollis.com> Signed-off-by: David S. Miller <davem@davemloft.net>
ipv6 ip6_tunnel: eliminate unused recursion field from ip6_tnl{}.
Commit a43912ab19... ("tunnel: eliminate recursion field") eliminated
use of recursion field from tunnel structures, but its definition
still exists in ip6_tnl{}.
Let's remove that unused field.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Tue, 9 Mar 2010 05:55:56 +0000 (05:55 +0000)]
tcp: Fix tcp_v4_rcv()
Commit d218d111 (tcp: Generalized TTL Security Mechanism) added a bug
for TIMEWAIT sockets. We should not test min_ttl for TW sockets.
Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Acked-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Frank Blaschka [Mon, 8 Mar 2010 20:36:57 +0000 (20:36 +0000)]
qeth: change checksumming default for HiperSockets
Deactivate inbound checksumming on HiperSocket is a valid but
dangerous optimization in case the frame is routed from an OSA
network to an HiperSockets network. To go for sure we change the
default to software checksumming.
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ursula Braun [Mon, 8 Mar 2010 20:36:56 +0000 (20:36 +0000)]
qeth: no recovery after layer mismatch (z/VM NICs)
Depending on their definition in z/VM, virtual devices for z/VM
VSWITCH or GuestLAN must be configured either in layer2 or in
layer3 mode. If qeth detects a layer mismatch, device activation
fails. Trying to recover from this error cannot help; thus
scheduling a recovery should be avoided.
In addition, since recovery is forbidden during online setting of
a qeth device, existence of its network device is guaranteed for all
dev_close() calls in qeth. The corresponding checks can be removed.
Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ursula Braun [Mon, 8 Mar 2010 20:36:55 +0000 (20:36 +0000)]
qeth: set promisc off after trace disabling failure
If HiperSockets Network Traffic Analyzer is switched off, but trace
disabling fails somehow, the qeth driver does not switch off its
promisc mode status. A following sniffer reactivation fails, since
qeth does not see a need to reenable tracing.
At the same time the code analyzing results of trace commands is
restructured.
Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Frank Blaschka [Mon, 8 Mar 2010 20:36:54 +0000 (20:36 +0000)]
qeth: l3 send dhcp in non pass thru mode
dhcp frames are valid IPv4 packets so there is no need to send them
in pass thru mode. This allows dhcp packets to pass HiperSockets.
Also the dhcp release frame is send out correctly with this patch.
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ursula Braun [Mon, 8 Mar 2010 20:36:53 +0000 (20:36 +0000)]
qeth: enable kmsg hash processing in qeth_core_sys.c
provide qeth kmsg definitions to enable hash string generation for
kernel message created with dev_err().
Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
As explained by Johannes:
When we
build a probe request frame in the buffer with the SSID, we could
arrive over the limit of 200 bytes. When we build it in the buffer
without the SSID (wildcard) we don't arrive over 200 bytes, but the
ucode still allows direct probe in addition because it has an internal
buffer that is larger when it inserts the SSID...
Reinette Chatre [Fri, 26 Feb 2010 19:01:36 +0000 (11:01 -0800)]
iwl3945: fix memory corruption
Recent patch "iwlwifi: move 3945 clip groups to 3945 data" exposed a memory
corruption problem. When initializing the clip groups the code was
mistakenly using the iwlagn rate count, not the 3945 rate count. This
resulted in more memory being written than was allocated.
"iwlwifi: move 3945 clip groups to 3945 data" moved the location where the
clip groups are stored and the impact is now severe in that the number of
configured TX queues is modified. Previously the
"temperature" field was overwritten, which did not seem to affect the
operation.
Fix this one instance where wrong rate count was used. I also noticed one
more location where the iwlagn rate count was used to index an iwl3945
array, fix this. I also modified one location that modified the iwlagn rate
count to obtain the iwl3945 rate count ... just use the iwl3945 rate count
directly.
This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2165 and
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2168
Part of the large effort I'm trying to help with getting all the downstreamed
code from windriver forward ported to the upstream tree
Origional commit message
Restore check to filter out inadverdently received messages
This patch reimplements a check that allows TIPC to discard messages
that are not intended for it. This check was present in TIPC 1.5/1.6,
but was removed by accident during the development of TIPC 1.7; it has
now been updated to account for new features present in TIPC 1.7 and
reinserted into TIPC. The main benefit of this check is to filter
out messages arriving from orphaned link endpoints, which can arise
when a node exits the network and then re-enters it with a different
TIPC network address (i.e. <Z.C.N> value).
Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Origionally-authored-by: Allan Stephens <allan.stephens@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Neil Horman [Mon, 8 Mar 2010 20:20:58 +0000 (12:20 -0800)]
tipc: fix endianness on tipc subscriber messages
Remove htohl implementation from tipc
I was working on forward porting the downstream commits for TIPC and ran accross this one:
http://tipc.cslab.ericsson.net/cgi-bin/gitweb.cgi?p=people/allan/tipc.git;a=commitdiff;h=894279b9437b63cbb02405ad5b8e033b51e4e31e
I was going to just take it, when I looked closer and noted what it was doing.
This is basically a routine to byte swap fields of data in sent/received packets
for tipc, dependent upon the receivers guessed endianness of the peer when a
connection is established. Asside from just seeming silly to me, it appears to
violate the latest RFC draft for tipc:
http://tipc.sourceforge.net/doc/draft-spec-tipc-02.txt
Which, according to section 4.2 and 4.3.3, requires that all fields of all
commands be sent in network byte order. So instead of just taking this patch,
instead I'm removing the htohl function and replacing the calls with calls to
ntohl in the rx path and htonl in the send path.
As part of this fix, I'm also changing the subscr_cancel function, which
searches the list of subscribers, using a memcmp of the entire subscriber list,
for the entry to tear down. unfortunately it memcmps the entire tipc_subscr
structure which has several bits that are private to the local side, so nothing
will ever match. section 5.2 of the draft spec indicates the <type,upper,lower>
tuple should uniquely identify a subscriber, so convert subscr_cancel to just
match on those fields (properly endian swapped).
I've tested this using the tipc test suite, and its passed without issue.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Barry Song [Mon, 8 Mar 2010 20:13:57 +0000 (12:13 -0800)]
can: fix bfin_can build error after alloc_candev() change
Looks like commit a6e4bc530403 didn't include updates to drivers so the
Blackfin CAN driver fails to build now.
Signed-off-by: Barry Song <barry.song@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org> Acked-by: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Mon, 8 Mar 2010 19:32:01 +0000 (11:32 -0800)]
tcp: Fix tcp_make_synack()
Commit 4957faad (TCPCT part 1g: Responder Cookie => Initiator), part
of TCP_COOKIE_TRANSACTION implementation, forgot to correctly size
synack skb in case user data must be included.
Many thanks to Mika Pentillä for spotting this error.
Reported-by: Penttillä Mika <mika.penttila@ixonos.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Mon, 8 Mar 2010 03:20:00 +0000 (03:20 +0000)]
net: fix route cache rebuilds
We added an automatic route cache rebuilding in commit 1080d709fb9d8cd43
but had to correct few bugs. One of the assumption of original patch,
was that entries where kept sorted in a given way.
This assumption is known to be wrong (commit 1ddbcb005c395518 gave an
explanation of this and corrected a leak) and expensive to respect.
Paweł Staszewski reported to me one of his machine got its routing cache
disabled after few messages like :
[ 2677.850065] Route hash chain too long!
[ 2677.850080] Adjust your secret_interval!
[82839.662993] Route hash chain too long!
[82839.662996] Adjust your secret_interval!
[155843.731650] Route hash chain too long!
[155843.731664] Adjust your secret_interval!
[155843.811881] Route hash chain too long!
[155843.811891] Adjust your secret_interval!
[155843.858209] vlan0811: 5 rebuilds is over limit, route caching
disabled
[155843.858212] Route hash chain too long!
[155843.858213] Adjust your secret_interval!
This is because rt_intern_hash() might be fooled when computing a chain
length, because multiple entries with same keys can differ because of
TOS (or mark/oif) bits.
In the rare case the fast algorithm see a too long chain, and before
taking expensive path, we call a helper function in order to not count
duplicates of same routes, that only differ with tos/mark/oif bits. This
helper works with data already in cpu cache and is not be very
expensive, despite its O(N^2) implementation.
Paweł Staszewski sucessfully tested this patch on his loaded router.
Reported-and-tested-by: Paweł Staszewski <pstaszewski@itcare.pl> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Validate all sections of unified fw image, before accessing them,
to avoid seg fault.
Signed-off-by: Sucheta Chakraborty <sucheta@dut6195.unminc.com> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
For promiscuous mode, driver send request to device for deleting
multicast addresses and again it send request for adding them back
while exiting from this mode, this is bad for performance.
Just setting device in promiscuous mode is enough, no need to del/add
multicast addresses.
Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Statistics added for lro/lso bytes, count for tx stop queue and
wake queue and skb alloc failure count.
Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Kernel default tx csum function (ethtool_op_get_tx_csum) doesn't show
correct csum status. It takes various FLAGS (NETIF_F_ALL_CSUM) in account
to show tx csum status, which driver doesn't set while disabling tx csum.
Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Herbert Xu [Fri, 5 Mar 2010 21:03:35 +0000 (21:03 +0000)]
bridge: Fix RCU race in br_multicast_stop
Thanks to Paul McKenny for pointing out that it is incorrect to use
synchronize_rcu_bh to ensure that pending callbacks have completed.
Instead we should use rcu_barrier_bh.
Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Herbert Xu [Fri, 5 Mar 2010 21:07:39 +0000 (21:07 +0000)]
bridge: Use RCU list primitive in __br_mdb_ip_get
As Paul McKenney correctly pointed out, __br_mdb_ip_get needs
to use the RCU list walking primitive in order to work correctly
on platforms where data-dependency ordering is not guaranteed.
Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
cpmac: fallback to switch mode if no PHY chip found
If we were unable to detect a PHY on any of the MDIO bus id we tried instead of
bailing out with -ENODEV, assume the MAC is connected to a switch and use MDIO
bus 0. This unbreaks quite a lot of devices out there whose switch cannot be
detected.
Signed-off-by: Florian Fainelli <florian@openwrt.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Despite what the comment above CPMAC_SKB_SIZE says, the hardware also
needs to account for the FCS length in a received frame. This patch fix
the receiving of 802.1q frames which have 4 more bytes. While at it
unhardcode the definition and use the one from if_vlan.h.
Signed-off-by: Florian Fainelli <florian@openwrt.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Oliver Hartkopp [Sat, 6 Mar 2010 08:31:50 +0000 (08:31 +0000)]
MAINTAINER: Correct CAN Maintainer responsibilities and paths
Update the CAN Maintainer responsibilities and add source paths.
Additional the SocketCAN core ML is not subscribers-only anymore.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Acked-by: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Petko Manolov [Sun, 7 Mar 2010 06:10:01 +0000 (06:10 +0000)]
another pegasus usb net device
This one removes trailing whitespace in pegasus.h and more importantly
adds new Pegasus compatible device.
Signed-off-by: Julian Brown <julian@codesourcery.com> Signed-off-by: Petko Manolov <petkan@nucleusys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Dan Carpenter [Sat, 6 Mar 2010 01:14:09 +0000 (01:14 +0000)]
bridge: cleanup: remove unneed check
We dereference "port" on the lines immediately before and immediately
after the test so port should hopefully never be null here.
Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
e1000e: fix packet corruption and tx hang during NFSv2
when receiving a particular type of NFS v2 UDP traffic, the hardware could
DMA some bad data and then hang, possibly corrupting memory.
Disable the NFS parsing in this hardware, verified to fix the bug.
Originally reported and reproduced by RedHat's Neil Horman CC: nhorman@tuxdriver.com Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David Dillow [Thu, 4 Mar 2010 04:37:16 +0000 (04:37 +0000)]
typhoon: fix incorrect use of smp_wmb()
The typhoon driver was incorrectly using smp_wmb() to order memory
accesses against IO to the NIC in a few instances. Use wmb() instead,
which is required to actually order between memory types.
Signed-off-by: David Dillow <dave@thedillows.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Jeff Garzik [Thu, 4 Mar 2010 08:21:53 +0000 (08:21 +0000)]
ethtool: Add direct access to ops->get_sset_count
On 03/04/2010 09:26 AM, Ben Hutchings wrote:
> On Thu, 2010-03-04 at 00:51 -0800, Jeff Kirsher wrote:
>> From: Jeff Garzik<jgarzik@redhat.com>
>>
>> This patch is an alternative approach for accessing string
>> counts, vs. the drvinfo indirect approach. This way the drvinfo
>> space doesn't run out, and we don't break ABI later.
> [...]
>> --- a/net/core/ethtool.c
>> +++ b/net/core/ethtool.c
>> @@ -214,6 +214,10 @@ static noinline int ethtool_get_drvinfo(struct net_device *dev, void __user *use
>> info.cmd = ETHTOOL_GDRVINFO;
>> ops->get_drvinfo(dev,&info);
>>
>> + /*
>> + * this method of obtaining string set info is deprecated;
>> + * consider using ETHTOOL_GSSET_INFO instead
>> + */
>
> This comment belongs on the interface (ethtool.h) not the
> implementation.
Debatable -- the current comment is located at the callsite of
ops->get_sset_count(), which is where an implementor might think to add
a new call. Not all the numeric fields in ethtool_drvinfo are obtained
from ->get_sset_count().
Hence the "some" in the attached patch to include/linux/ethtool.h,
addressing your comment.
> [...]
>> +static noinline int ethtool_get_sset_info(struct net_device *dev,
>> + void __user *useraddr)
>> +{
> [...]
>> + /* calculate size of return buffer */
>> + for (i = 0; i< 64; i++)
>> + if (sset_mask& (1ULL<< i))
>> + n_bits++;
> [...]
>
> We have a function for this:
>
> n_bits = hweight64(sset_mask);
Agreed.
I've attached a follow-up patch, which should enable my/Jeff's kernel
patch to be applied, followed by this one.
Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Jeff Garzik [Wed, 3 Mar 2010 22:51:50 +0000 (22:51 +0000)]
ethtool: Add direct access to ops->get_sset_count
This patch is an alternative approach for accessing string
counts, vs. the drvinfo indirect approach. This way the drvinfo
space doesn't run out, and we don't break ABI later.
Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David Brown [Fri, 5 Mar 2010 09:12:34 +0000 (09:12 +0000)]
net: smc91x: Support Qualcomm MSM development boards.
Signed-off-by: David Brown <davidb@quicinc.com> Signed-off-by: Daniel Walker <dwalker@codeaurora.org> Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Zhu Yi [Thu, 4 Mar 2010 18:01:46 +0000 (18:01 +0000)]
x25: use limited socket backlog
Make x25 adapt to the limited socket backlog change.
Cc: Andrew Hendry <andrew.hendry@gmail.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Zhu Yi [Thu, 4 Mar 2010 18:01:45 +0000 (18:01 +0000)]
tipc: use limited socket backlog
Make tipc adapt to the limited socket backlog change.
Cc: Jon Maloy <jon.maloy@ericsson.com> Cc: Allan Stephens <allan.stephens@windriver.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Acked-by: Allan Stephens <allan.stephens@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Zhu Yi [Thu, 4 Mar 2010 18:01:44 +0000 (18:01 +0000)]
sctp: use limited socket backlog
Make sctp adapt to the limited socket backlog change.
Cc: Vlad Yasevich <vladislav.yasevich@hp.com> Cc: Sridhar Samudrala <sri@us.ibm.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Zhu Yi [Thu, 4 Mar 2010 18:01:43 +0000 (18:01 +0000)]
llc: use limited socket backlog
Make llc adapt to the limited socket backlog change.
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Zhu Yi [Thu, 4 Mar 2010 18:01:42 +0000 (18:01 +0000)]
udp: use limited socket backlog
Make udp adapt to the limited socket backlog change.
Cc: "David S. Miller" <davem@davemloft.net> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Cc: "Pekka Savola (ipv6)" <pekkas@netcore.fi> Cc: Patrick McHardy <kaber@trash.net> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Zhu Yi [Thu, 4 Mar 2010 18:01:41 +0000 (18:01 +0000)]
tcp: use limited socket backlog
Make tcp adapt to the limited socket backlog change.
Cc: "David S. Miller" <davem@davemloft.net> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Cc: "Pekka Savola (ipv6)" <pekkas@netcore.fi> Cc: Patrick McHardy <kaber@trash.net> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Zhu Yi [Thu, 4 Mar 2010 18:01:40 +0000 (18:01 +0000)]
net: add limit for socket backlog
We got system OOM while running some UDP netperf testing on the loopback
device. The case is multiple senders sent stream UDP packets to a single
receiver via loopback on local host. Of course, the receiver is not able
to handle all the packets in time. But we surprisingly found that these
packets were not discarded due to the receiver's sk->sk_rcvbuf limit.
Instead, they are kept queuing to sk->sk_backlog and finally ate up all
the memory. We believe this is a secure hole that a none privileged user
can crash the system.
The root cause for this problem is, when the receiver is doing
__release_sock() (i.e. after userspace recv, kernel udp_recvmsg ->
skb_free_datagram_locked -> release_sock), it moves skbs from backlog to
sk_receive_queue with the softirq enabled. In the above case, multiple
busy senders will almost make it an endless loop. The skbs in the
backlog end up eat all the system memory.
The issue is not only for UDP. Any protocols using socket backlog is
potentially affected. The patch adds limit for socket backlog so that
the backlog size cannot be expanded endlessly.
Reported-by: Alex Shi <alex.shi@intel.com> Cc: David Miller <davem@davemloft.net> Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru Cc: "Pekka Savola (ipv6)" <pekkas@netcore.fi> Cc: Patrick McHardy <kaber@trash.net> Cc: Vlad Yasevich <vladislav.yasevich@hp.com> Cc: Sridhar Samudrala <sri@us.ibm.com> Cc: Jon Maloy <jon.maloy@ericsson.com> Cc: Allan Stephens <allan.stephens@windriver.com> Cc: Andrew Hendry <andrew.hendry@gmail.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Jiri Pirko [Thu, 4 Mar 2010 11:32:16 +0000 (03:32 -0800)]
rndis_wlan: correct multicast_list handling V3
My previous patch (655ffee284dfcf9a24ac0343f3e5ee6db85b85c5) added locking in
a bad way. Because rndis_set_oid can sleep, there is need to prepare multicast
addresses into local buffer under netif_addr_lock first, then call
rndis_set_oid outside. This caused reorganizing of the whole function.
Signed-off-by: Jiri Pirko <jpirko@redhat.com> Reported-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
Anton Vorontsov [Wed, 3 Mar 2010 08:18:58 +0000 (08:18 +0000)]
gianfar: Fix TX ring processing on SMP machines
Starting with commit a3bc1f11e9b867a4f49505 ("gianfar: Revive SKB
recycling") gianfar driver sooner or later stops transmitting any
packets on SMP machines.
start_xmit() prepares new skb for transmitting, generally it does
three things:
1. sets up all BDs (marks them ready to send), except the first one.
2. stores skb into tx_queue->tx_skbuff so that clean_tx_ring()
would cleanup it later.
3. sets up the first BD, i.e. marks it ready.
Here is what clean_tx_ring() does:
1. reads skbs from tx_queue->tx_skbuff
2. checks if the *last* BD is ready. If it's still ready [to send]
then it it isn't transmitted, so clean_tx_ring() returns.
Otherwise it actually cleanups BDs. All is OK.
Now, if there is just one BD, code flow:
- start_xmit(): stores skb into tx_skbuff. Note that the first BD
(which is also the last one) isn't marked as ready, yet.
- clean_tx_ring(): sees that skb is not null, *and* its lstatus
says that it is NOT ready (like if BD was sent), so it cleans
it up (bad!)
- start_xmit(): marks BD as ready [to send], but it's too late.
We can fix this simply by reordering lstatus/tx_skbuff writes.
Reported-by: Martyn Welch <martyn.welch@ge.com> Bisected-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Tested-by: Paul Gortmaker <paul.gortmaker@windriver.com> Tested-by: Martyn Welch <martyn.welch@ge.com> Cc: Sandeep Gopalpet <Sandeep.Kumar@freescale.com> Cc: Stable <stable@vger.kernel.org> [2.6.33] Signed-off-by: David S. Miller <davem@davemloft.net>
David Dillow [Wed, 3 Mar 2010 16:33:10 +0000 (16:33 +0000)]
r8169: use correct barrier between cacheable and non-cacheable memory
r8169 needs certain writes to be visible to other CPUs or the NIC before
touching the hardware, but was using smp_wmb() which is only required to
order cacheable memory access. Switch to wmb() which is required to
order both cacheable and non-cacheable memory.
Noticed by Catalin Marinas and Paul Mackerras.
Signed-off-by: David Dillow <dave@thedillows.org> Signed-off-by: David S. Miller <davem@davemloft.net>
What happens is that, when the tipc module in inserted it enters a standalone
node mode in which communication to its own address is allowed <0.0.0> but not
to other addresses, since the appropriate data structures have not been
allocated yet (specifically the tipc_net pointer). There is nothing stopping a
client from trying to send such a message however, and if that happens, we
attempt to dereference tipc_net.zones while the pointer is still NULL, and
explode. The fix is pretty straightforward. Since these oopses all arise from
the dereference of global pointers prior to their assignment to allocated
values, and since these allocations are small (about 2k total), lets convert
these pointers to static arrays of the appropriate size. All the accesses to
these bits consider 0/NULL to be a non match when searching, so all the lookups
still work properly, and there is no longer a chance of a bad dererence
anywhere. As a bonus, this lets us eliminate the setup/teardown routines for
those pointers, and elimnates the need to preform any locking around them to
prevent access while their being allocated/freed.
I've updated the tipc_net structure to behave this way to fix the exact reported
problem, and also fixed up the tipc_bearers and media_list arrays to fix an
obvious simmilar problem that arises from issuing tipc-config commands to
manipulate bearers/links prior to entering networked mode
I've tested this for a few hours by running the sanity tests and stress test
with the tipcutils suite, and nothing has fallen over. There have been a few
lockdep warnings, but those were there before, and can be addressed later, as
they didn't actually result in any deadlock.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com> CC: Allan Stephens <allan.stephens@windriver.com> CC: David S. Miller <davem@davemloft.net> CC: tipc-discussion@lists.sourceforge.net
bearer.c | 37 ++++++-------------------------------
bearer.h | 2 +-
net.c | 25 ++++---------------------
3 files changed, 11 insertions(+), 53 deletions(-) Signed-off-by: David S. Miller <davem@davemloft.net>
Timo Teräs [Wed, 3 Mar 2010 04:01:13 +0000 (04:01 +0000)]
gre: fix hard header destination address checking
ipgre_header() can be called with zero daddr when the gre device is
configured as multipoint tunnel and still has the NOARP flag set (which is
typically cleared by the userspace arp daemon). If the NOARP packets are
not dropped, ipgre_tunnel_xmit() will take rt->rt_gateway (= NBMA IP) and
use that for route look up (and may lead to bogus xfrm acquires).
The multicast address check is removed as sending to multicast group should
be ok. In fact, if gre device has a multicast address as destination
ipgre_header is always called with multicast address.
Signed-off-by: Timo Teras <timo.teras@iki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
IPv6: fix race between cleanup and add/delete address
This solves a potential race problem during the cleanup process.
The issue is that addrconf_ifdown() needs to traverse address list,
but then drop lock to call the notifier. The version in -next
could get confused if add/delete happened during this window.
Original code (2.6.32 and earlier) was okay because all addresses
were always deleted.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
My recent change in net-next to retain permanent addresses caused regression.
Device refcount would not go to zero when device was unregistered because
left over anycast reference would hold ipv6 dev reference which would hold
device references...
The correct procedure is to call notify chain when address is no longer
available for use. When interface comes back DAD timer will notify
back that address is available.
Also, link local addresses should be purged when interface is brought
down. The address might be changed.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
The Router Solicitation timer races with device state changes
because it doesn't lock the device. Use local variable to avoid
one repeated dereference.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Timer code runs in bottom half, so there is no need for
using _bh form of locking. Also check if device is not ready
to avoid race with address that is no longer active.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Helmut Schaa [Wed, 3 Mar 2010 16:42:55 +0000 (17:42 +0100)]
rt2x00: Export rt2x00soc_probe from rt2x00soc
Export rt2x00soc_probe from rt2x00soc as it is used in rt2800pci.
Otherwise loading rt2800pci gives "rt2800pci: Unknown symbol
rt2x00soc_probe".
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Sujith [Mon, 1 Mar 2010 09:12:57 +0000 (14:42 +0530)]
mac80211: Fix HT rate control configuration
Handling HT configuration changes involved setting the channel
with the new HT parameters and then issuing a rate_update()
notification to the driver.
This behavior changed after the off-channel changes. Now, the channel
is not updated with the new HT params in enable_ht() - instead, it
is now done when the scan work terminates. This results in the driver
depending on stale information, defaulting to non-HT mode always.
Fix this by passing the new channel type to the driver.
Cc: stable@kernel.org Signed-off-by: Sujith <Sujith.Manoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com> Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
projects / mirror_ubuntu-eoan-kernel.git / log