- 16 Jul, 2012 32 commits
-
-
David S. Miller authored
[ Upstream commit 6a2b28ef ] This reverts commit efa230f2. BQL doesn't work with how this driver currently only takes TX interrupts every 1/4 of the TX ring. That behavior needs to be fixed, but that's a larger non-trivial task and for now we have to revert BQL support as this makes the device currently completely unusable. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
stephen hemminger authored
[ Upstream commit 5ff0feac ] The newer flavors of Yukon II use a different method for receive checksum offload. This is indicated in the driver by the SKY2_HW_NEW_LE flag. On these newer chips, the BMU_ENA_RX_CHKSUM should not be set. The driver would get incorrectly toggle the bit, enabling the old checksum logic on these chips and cause a BUG_ON() assertion. If receive checksum was toggled via ethtool. Reported-by:
Kirill Smelkov <kirr@mns.spb.ru> Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
-
Thomas Graf authored
[ Upstream commit d189634e ] /proc/net/ipv6_route reflects the contents of fib_table_hash. The proc handler is installed in ip6_route_net_init() whereas fib_table_hash is allocated in fib6_net_init() _after_ the proc handler has been installed. This opens up a short time frame to access fib_table_hash with its pants down. Move the registration of the proc files to a later point in the init order to avoid the race. Tested :-) Signed-off-by:
Thomas Graf <tgraf@suug.ch> Signed-off-by:
-
Thomas Graf authored
[ Upstream commit 8bd74516 ] Commit 5339ab8b (ipv6: fib: Convert fib6_age() to dst_neigh_lookup().) seems to have mistakenly inverted the exception for cached NTF_ROUTER routes. Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 4bd6683b ] Denys found out "ip neigh" output was truncated to about 54 neighbours. Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Denys Fedoryshchenko <denys@visp.net.lb> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 3f16da51 ] __lpc_handle_xmit() has two bugs : 1) It can leak skbs in case TXSTATUS_ERROR is set 2) It can wake up txqueue while no slot was freed. Signed-off-by:
Roland Stigge <stigge@antcom.de> Tested-by:
-
Eric Dumazet authored
[ Upstream commit e3047859 ] lpc_eth does a copy of transmitted skbs to DMA area, without checking skb lengths, so can trigger buffer overflows : memcpy(pldat->tx_buff_v + txidx * ENET_MAXF_SIZE, skb->data, len); One way to get bigger skbs is to allow MTU changes above the 1500 limit. Calling eth_change_mtu() in ndo_change_mtu() makes sure this cannot happen. Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 4399a4df ] Commit 081b1b1b (l2tp: fix l2tp_ip_sendmsg() route handling) added a race, in case IP route cache is disabled. In this case, we should not do the dst_release(&rt->dst), since it'll free the dst immediately, instead of waiting a RCU grace period. Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit a06998b8 ] We must prevent module unloading if some devices are still attached to l2tp_eth driver. Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 55432d2b ] commit 5faa5df1 (inetpeer: Invalidate the inetpeer tree along with the routing cache) added a race : Before freeing an inetpeer, we must respect a RCU grace period, and make sure no user will attempt to increase refcnt. inetpeer_invalidate_tree() waits for a RCU grace period before inserting inetpeer tree into gc_list and waking the worker. At that time, no concurrent lookup can find a inetpeer in this tree. Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit bec4596b ] drop_monitor calls several sleeping functions while in atomic context. BUG: sleeping function called from invalid context at mm/slub.c:943 in_atomic(): 1, irqs_disabled(): 0, pid: 2103, name: kworker/0:2 Pid: 2103, comm: kworker/0:2 Not tainted 3.5.0-rc1+ #55 Call Trace: [<ffffffff810697ca>] __might_sleep+0xca/0xf0 [<ffffffff811345a3>] kmem_cache_alloc_node+0x1b3/0x1c0 [<ffffffff8105578c>] ? queue_delayed_work_on+0x11c/0x130 [<ffffffff815343fb>] __alloc_skb+0x4b/0x230 [<ffffffffa00b0360>] ? reset_per_cpu_data+0x160/0x160 [drop_monitor] [<ffffffffa00b022f>] reset_per_cpu_data+0x2f/0x160 [drop_monitor] [<ffffffffa00b03ab>] send_dm_alert+0x4b/0xb0 [drop_monitor] [<ffffffff810568e0>] process_one_work+0x130/0x4c0 [<ffffffff81058249>] worker_thread+0x159/0x360 [<ffffffff810580f0>] ? manage_workers.isra.27+0x240/0x240 [<ffffffff8105d403>] kthread+0x93/0xa0 [<ffffffff816be6d4>] kernel_thread_helper+0x4/0x10 [<ffffffff8105d370>] ? kthread_freezable_should_stop+0x80/0x80 [<ffffffff816be6d0>] ? gs_change+0xb/0xb Rework the logic to call the sleeping functions in right context. Use standard timer/workqueue api to let system chose any cpu to perform the allocation and netlink send. Also avoid a loop if reset_per_cpu_data() cannot allocate memory : use mod_timer() to wait 1/10 second before next try. Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
Devendra Naga authored
[ Upstream commit ad1be8d3 ] when register_netdev fails, the init'ed NAPIs by netif_napi_add must be deleted with netif_napi_del, and also when driver unloads, it should delete the NAPI before unregistering netdevice using unregister_netdev. Signed-off-by:
Devendra Naga <devendra.aaru@gmail.com> Signed-off-by:
-
Paul Moore authored
[ Upstream commit 20e2a864 ] When NetLabel is not enabled, e.g. CONFIG_NETLABEL=n, and the system receives a CIPSO tagged packet it is dropped (cipso_v4_validate() returns non-zero). In most cases this is the correct and desired behavior, however, in the case where we are simply forwarding the traffic, e.g. acting as a network bridge, this becomes a problem. This patch fixes the forwarding problem by providing the basic CIPSO validation code directly in ip_options_compile() without the need for the NetLabel or CIPSO code. The new validation code can not perform any of the CIPSO option label/value verification that cipso_v4_validate() does, but it can verify the basic CIPSO option format. The behavior when NetLabel is enabled is unchanged. Signed-off-by:
Paul Moore <pmoore@redhat.com> Signed-off-by:
-
Jason Wang authored
[ Upstream commit cc9b17ad ] We need to validate the number of pages consumed by data_len, otherwise frags array could be overflowed by userspace. So this patch validate data_len and return -EMSGSIZE when data_len may occupies more frags than MAX_SKB_FRAGS. Signed-off-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
-
Hiroaki SHIMODA authored
[ Upstream commit 914bec10 ] dql->num_queued could change while processing dql_completed(). To provide consistent calculation, added an on stack variable. Signed-off-by:
Hiroaki SHIMODA <shimoda.hiroaki@gmail.com> Cc: Tom Herbert <therbert@google.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Denys Fedoryshchenko <denys@visp.net.lb> Signed-off-by:
-
Hiroaki SHIMODA authored
[ Upstream commit 25426b79 ] When below pattern is observed, TIME dql_queued() dql_completed() | a) initial state | | b) X bytes queued V c) Y bytes queued d) X bytes completed e) Z bytes queued f) Y bytes completed a) dql->limit has already some value and there is no in-flight packet. b) X bytes queued. c) Y bytes queued and excess limit. d) X bytes completed and dql->prev_ovlimit is set and also dql->prev_num_queued is set Y. e) Z bytes queued. f) Y bytes completed. inprogress and prev_inprogress are true. At f), according to the comment, all_prev_completed becomes true and limit should be increased. But POSDIFF() ignores (completed == dql->prev_num_queued) case, so limit is decreased. Signed-off-by:
-
Hiroaki SHIMODA authored
[ Upstream commit 0cfd32b7 ] POSDIFF() fails to take into account integer overflow case. Signed-off-by:
-
Michael Krufky authored
commit 3e1141e2 upstream. Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
Anton Blanchard authored
commit bc1d7702 upstream. We have a bug report where the kernel hits a warning in the cpumask code: WARNING: at include/linux/cpumask.h:107 Which is: WARN_ON_ONCE(cpu >= nr_cpumask_bits); The backtrace is: cpu_cmd cmds xmon_core xmon die xmon is iterating through 0 to NR_CPUS. I'm not sure why we are still open coding this but iterating above nr_cpu_ids is definitely a bug. This patch iterates through all possible cpus, in case we issue a system reset and CPUs in an offline state call in. Perhaps the old code was trying to handle CPUs that were in the partition but were never started (eg kexec into a kernel with an nr_cpus= boot option). They are going to die way before we get into xmon since we haven't set any kernel state up for them. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Michael Neuling authored
commit 2f584a14 upstream. Since we are taking a registers, this should never have been an sldi. Talking to paulus offline, this is the correct fix. Was introduced by: commit 19ccb76a Author: Paul Mackerras <paulus@samba.org> Date: Sat Jul 23 17:42:46 2011 +1000 Talking to paulus, this shouldn't be a literal. Signed-off-by:
Michael Neuling <mikey@neuling.org> Signed-off-by:
-
Nicolas Pitre authored
commit 19b52abe upstream. On ARM with the 2-level page table format, a PMD entry is represented by two consecutive section entries covering 2MB of virtual space. However, static mappings always were allowed to use separate 1MB section entries. This means in practice that a static mapping may create half populated PMDs via create_mapping(). Since commit 0536bdf3 (ARM: move iotable mappings within the vmalloc region) those static mappings are located in the vmalloc area. We must ensure no such half populated PMDs are accessible once vmalloc() or ioremap() start looking at the vmalloc area for nearby free virtual address ranges, or various things leading to a kernel crash will happen. Signed-off-by:
Nicolas Pitre <nico@linaro.org> Reported-by:
Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by:
"R, Sricharan" <r.sricharan@ti.com> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Jonghwan Choi authored
commit a5d8f476 upstream. On the error condition clk_get() returns ERR_PTR(). Signed-off-by:
Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by:
Kukjin Kim <kgene.kim@samsung.com> Signed-off-by:
-
Jose Miguel Goncalves authored
commit 3dca9386 upstream. While upgrading the kernel on a S3C2412 based board I've noted that it was impossible to boot the board with a 2.6.32 or upper kernel. I've tracked down the problem to the EBI virtual memory mapping that is in conflict with the IO mapping definition in arch/arm/mach-s3c24xx/s3c2412.c. Signed-off-by:
Jose Miguel Goncalves <jose.goncalves@inov.pt> Signed-off-by:
-
Anton Blanchard authored
commit 0b17ba72 upstream. Commit f948501b ("Make hard_irq_disable() actually hard-disable interrupts") caused check_and_cede_processor to stop working. ->irq_happened will never be zero right after a hard_irq_disable so the compiler removes the call to cede_processor completely. The bug was introduced back in the lazy interrupt handling rework of 3.4 but was hidden until recently because hard_irq_disable did nothing. This issue will eventually appear in 3.4 stable since the hard_irq_disable fix is marked stable, so mark this one for stable too. Signed-off-by:
-
Michael Neuling authored
commit bc6dc752 upstream. The following added support for powernv but broke pseries/BML: 1f1616e8 powerpc/powernv: Add TCE SW invalidation support TCE_PCI_SW_INVAL was split into FREE and CREATE flags but the tests in the pseries code were not updated to reflect this. Signed-off-by:
-
Michael Neuling authored
commit 82b2521d upstream. chroma_defconfig currently gives me this with gcc 4.6: arch/powerpc/mm/numa.c:638:13: error: 'dm' may be used uninitialized in this function [-Werror=uninitialized] It's a bogus warning/error since of_get_drconf_memory() only writes it anyway. Signed-off-by:
-
Steven Rostedt authored
commit 2d773aa4 upstream. As I was adding code that affects all archs, I started testing function tracer against PPC64 and found that it currently locks up with 3.4 kernel. I figured it was due to tracing a function that shouldn't be, so I went through the following process to bisect to find the culprit: cat /debug/tracing/available_filter_functions > t num=`wc -l t` sed -ne "1,${num}p" t > t1 let num=num+1 sed -ne "${num},$p" t > t2 cat t1 > /debug/tracing/set_ftrace_filter echo function /debug/tracing/current_tracer <failed? bisect t1, if not bisect t2> It finally came down to this function: restore_interrupts() I'm not sure why this locks up the system. It just seems to prevent scheduling from occurring. Interrupts seem to still work, as I can ping the box. But all user processes freeze. When restore_interrupts() is not traced, function tracing works fine. Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Takashi Iwai authored
commit 6e1c39c6 upstream. The recent fix for power-map controls (commit b0791dda) caused regressions on some other HP laptops. They have fixed pins but these pins are exposed as jack-detectable. Thus the driver tries to control the power-map dynamically per jack detection where it never gets on. This patch corrects the condition check for fixed pins so that the power-map is set always for these pins. NOTE: this is no simple backport from 3.5 kernel. Since 3.5 kernel had significant code change in the relevant part, I fixed this differently. BugLink: http://bugs.launchpad.net/bugs/1013183Reported-by:
Luis Henriques <luis.henriques@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit 59cad16b upstream. Some caches aren't released properly at module unloading time. Signed-off-by:
-
David Henningsson authored
commit befae82e upstream. This chip looks very similar to ALC269 and ALC27* variants. The bug reporter has verified that sound was working after this patch had been applied. BugLink: https://bugs.launchpad.net/bugs/1017017Tested-by:
Richard Crossley <richardcrossley@o2.co.uk> Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
Stephen Warren authored
commit 6355f25e upstream. This solves a section mismatch warning. I hadn't noticed this before, because my compiler was inlining tegra_cpu_reset_handler_enable() inside tegra_cpu_reset_handler_init(), which is already __init, but I switched compilers and it stopped doing that. Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Olaf Hering authored
commit bcc2c9c3 upstream. The SuSE security team suggested to use recvfrom instead of recv to be certain that the connector message is originated from kernel. CVE-2012-2669 Signed-off-by:
Olaf Hering <olaf@aepfle.de> Signed-off-by:
Marcus Meissner <meissner@suse.de> Signed-off-by:
Sebastian Krahmer <krahmer@suse.de> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
- 22 Jun, 2012 8 commits
-
-
Greg Kroah-Hartman authored
-
Roland Dreier authored
commit 59e4f541 upstream. The error paths in target_emulate_set_target_port_groups() are all essentially "rc = -EINVAL; goto out;" but the code at "out:" ignores rc and always returns success. This means that even if eg explicit ALUA is turned off, the initiator will always see a good SCSI status for SET TARGET PORT GROUPS. Fix this by returning rc as is intended. It appears this bug was added by the following patch: commit 05d1c7c0 Author: Andy Grover <agrover@redhat.com> Date: Wed Jul 20 19:13:28 2011 +0000 target: Make all control CDBs scatter-gather Signed-off-by:
Roland Dreier <roland@purestorage.com> Cc: Andy Grover <agrover@redhat.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> [bwh: Backported to 3.2: we have transport_complete_task() and not target_complete_cmd()] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Johannes Berg authored
commit a5fdde28 upstream. Since my commit iwlwifi: use valid TX/RX antenna from hw_params the config values are pure overrides, not the real values for all hardware. Therefore, the EEPROM TX power reading code checks the wrong values, it should check the hw_params values. Reviewed-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Meenakshi Venkataraman authored
commit d2c8b15d upstream. My patch iwlwifi: use correct released ucode version did not correctly report supported firmware for the 6035 device. This patch fixes it. The minimum supported firmware version for 6035 is v6. Also correct the minimum supported firmware version for the 6000g2 series of devices. Signed-off-by:
Meenakshi Venkataraman <meenakshi.venkataraman@intel.com> Reviewed-by:
-
Emmanuel Grumbach authored
commit ebed633c upstream. The logic that allows to have a short TFD queue was completely wrong. We do maintain 256 Transmit Frame Descriptors, but they point to recycled buffers. We used to attach and de-attach different TFDs for the same buffer and it worked since they pointed to the same buffer. Also zero the number of BDs after unmapping a TFD. This seems not necessary since we don't reclaim the same TFD twice, but I like housekeeping. This patch solves this warning: [ 6427.079855] WARNING: at lib/dma-debug.c:866 check_unmap+0x727/0x7a0() [ 6427.079859] Hardware name: Latitude E6410 [ 6427.079865] iwlwifi 0000:02:00.0: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x00000000296d393c] [size=8 bytes] [ 6427.079870] Modules linked in: ... [ 6427.079950] Pid: 6613, comm: ifconfig Tainted: G O 3.3.3 #5 [ 6427.079954] Call Trace: [ 6427.079963] [<c10337a2>] warn_slowpath_common+0x72/0xa0 [ 6427.079982] [<c1033873>] warn_slowpath_fmt+0x33/0x40 [ 6427.079988] [<c12dcb77>] check_unmap+0x727/0x7a0 [ 6427.079995] [<c12dcdaa>] debug_dma_unmap_page+0x5a/0x80 [ 6427.080024] [<fe2312ac>] iwlagn_unmap_tfd+0x12c/0x180 [iwlwifi] [ 6427.080048] [<fe231349>] iwlagn_txq_free_tfd+0x49/0xb0 [iwlwifi] [ 6427.080071] [<fe228e37>] iwl_tx_queue_unmap+0x67/0x90 [iwlwifi] [ 6427.080095] [<fe22d221>] iwl_trans_pcie_stop_device+0x341/0x7b0 [iwlwifi] [ 6427.080113] [<fe204b0e>] iwl_down+0x17e/0x260 [iwlwifi] [ 6427.080132] [<fe20efec>] iwlagn_mac_stop+0x6c/0xf0 [iwlwifi] [ 6427.080168] [<fd8480ce>] ieee80211_stop_device+0x5e/0x190 [mac80211] [ 6427.080198] [<fd833208>] ieee80211_do_stop+0x288/0x620 [mac80211] [ 6427.080243] [<fd8335b7>] ieee80211_stop+0x17/0x20 [mac80211] [ 6427.080250] [<c148dac1>] __dev_close_many+0x81/0xd0 [ 6427.080270] [<c148db3d>] __dev_close+0x2d/0x50 [ 6427.080276] [<c148d152>] __dev_change_flags+0x82/0x150 [ 6427.080282] [<c148e3e3>] dev_change_flags+0x23/0x60 [ 6427.080289] [<c14f6320>] devinet_ioctl+0x6a0/0x770 [ 6427.080296] [<c14f8705>] inet_ioctl+0x95/0xb0 [ 6427.080304] [<c147a0f0>] sock_ioctl+0x70/0x270 Reported-by:
Antonio Quartulli <ordex@autistici.org> Tested-by:
Wey-Yi W Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
Richard Cochran authored
commit dd48d708 upstream. When repeating a UTC time value during a leap second (when the UTC time should be 23:59:60), the TAI timescale should not stop. The kernel NTP code increments the TAI offset one second too late. This patch fixes the issue by incrementing the offset during the leap second itself. Signed-off-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
-
Chris Boot authored
commit 59aed952 upstream. For the 82573, ASPM L1 gets disabled wholesale so this special-case code is not required. For the 82574 the previous patch does the same as for the 82573, disabling L1 on the adapter. Thus, this code is no longer required and can be removed. Signed-off-by:
Chris Boot <bootc@bootc.net> Tested-by:
Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Chris Boot authored
commit d4a4206e upstream. ASPM on the 82574 causes trouble. Currently the driver disables L0s for this NIC but only disables L1 if the MTU is >1500. This patch simply causes L1 to be disabled regardless of the MTU setting. Signed-off-by:
-
