aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-08-13bnx2x: prevent crash in shutdown flow with CNICYuval Mintz1-2/+1
There might be a crash as during shutdown flow CNIC might try to access resources already freed by bnx2x. Change bnx2x_close() into dev_close() in __bnx2x_remove (shutdown flow) to guarantee CNIC is notified of the device's change of status. Signed-off-by: Yuval Mintz <[email protected]> Signed-off-by: Dmitry Kravkov <[email protected]> Signed-off-by: Ariel Elior <[email protected]> Signed-off-by: Eilon Greenstein <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-08-13bnx2x: fix PTE write access errorBarak Witkowsky3-0/+15
PTE write access error might occur in MF_ALLOWED mode when IOMMU is active. The patch adds rmmod HSI indicating to MFW to stop running queries which might trigger this failure. Signed-off-by: Barak Witkowsky <[email protected]> Signed-off-by: Dmitry Kravkov <[email protected]> Signed-off-by: Ariel Elior <[email protected]> Signed-off-by: Eilon Greenstein <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-08-13bnx2x: fix memory leak in VFAriel Elior1-1/+1
Signed-off-by: Ariel Elior <[email protected]> Signed-off-by: Dmitry Kravkov <[email protected]> Signed-off-by: Eilon Greenstein <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-08-13bnx2x: update fairness parameters following DCB negotiationDmitry Kravkov3-12/+24
ETS can be enabled as a result of DCB negotiation, then fairness must be recalculated after each negotiation. Signed-off-by: Dmitry Kravkov <[email protected]> Signed-off-by: Ariel Elior <[email protected]> Signed-off-by: Eilon Greenstein <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-08-13bnx2x: protect different statistics flowsDmitry Kravkov3-12/+57
Add locking to protect different statistics flows from running simultaneously. This in order to serialize statistics requests sent to FW, otherwise two outstanding queries may cause FW assert. Signed-off-by: Dmitry Kravkov <[email protected]> Signed-off-by: Ariel Elior <[email protected]> Signed-off-by: Eilon Greenstein <[email protected]> Acked-by: Neal Cardwell <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-08-14PM / QoS: Fix workqueue deadlock when using pm_qos_update_request_timeout()Stephen Boyd1-7/+13
pm_qos_update_request_timeout() updates a qos and then schedules a delayed work item to bring the qos back down to the default after the timeout. When the work item runs, pm_qos_work_fn() will call pm_qos_update_request() and deadlock because it tries to cancel itself via cancel_delayed_work_sync(). Future callers of that qos will also hang waiting to cancel the work that is canceling itself. Let's extract the little bit of code that does the real work of pm_qos_update_request() and call it from the work function so that we don't deadlock. Before ed1ac6e (PM: don't use [delayed_]work_pending()) this didn't happen because the work function wouldn't try to cancel itself. Signed-off-by: Stephen Boyd <[email protected]> Reviewed-by: Tejun Heo <[email protected]> Cc: 3.9+ <[email protected]> # 3.9+ Signed-off-by: Rafael J. Wysocki <[email protected]>
2013-08-13myri10ge: Update MAINTAINERSHyong-Youb Kim1-2/+2
Remove Andrew Gallatin, as he is no longer with Myricom. Add Hyong-Youb Kim as the new maintainer. Update the website URL. Signed-off-by: Hyong-Youb Kim <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-08-13skge: dma_sync the whole receive bufferstephen hemminger1-2/+4
The DMA sync should sync the whole receive buffer, not just part of it. Fixes log messages dma_sync_check. Signed-off-by: Stephen Hemminger <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-08-13Merge branch 'security-fixes' into fixesRussell King4-9/+14
2013-08-13ARM: 7807/1: kexec: validate CPU hotplug supportStephen Warren3-4/+29
Architectures should fully validate whether kexec is possible as part of machine_kexec_prepare(), so that user-space's kexec_load() operation can report any problems. Performing validation in machine_kexec() itself is too late, since it is not allowed to return. Prior to this patch, ARM's machine_kexec() was testing after-the-fact whether machine_kexec_prepare() was able to disable all but one CPU. Instead, modify machine_kexec_prepare() to validate all conditions necessary for machine_kexec_prepare()'s to succeed. BUG if the validation succeeded, yet disabling the CPUs didn't actually work. Signed-off-by: Stephen Warren <[email protected]> Acked-by: "Eric W. Biederman" <[email protected]> Signed-off-by: Russell King <[email protected]>
2013-08-13ARM: 7812/1: rwlocks: retry trylock operation if strex fails on free lockWill Deacon1-19/+30
Commit 15e7e5c1ebf5 ("ARM: 7749/1: spinlock: retry trylock operation if strex fails on free lock") modifying our arch_spin_trylock to retry the acquisition if the lock appeared uncontended, but the strex failed. This patch does the same for rwlocks, which were missed by the original patch. Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Russell King <[email protected]>
2013-08-13ARM: 7811/1: locks: use early clobber in arch_spin_trylockWill Deacon1-1/+1
The res variable is written before we've finished with the input operands (namely the lock address), so ensure that we mark it as `early clobber' to avoid unintended register sharing. Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Russell King <[email protected]>
2013-08-13ARM: 7810/1: perf: Fix array out of bounds access in armpmu_map_hw_event()Stephen Boyd1-1/+6
Vince Weaver reports an oops in the ARM perf event code while running his perf_fuzzer tool on a pandaboard running v3.11-rc4. Unable to handle kernel paging request at virtual address 73fd14cc pgd = eca6c000 [73fd14cc] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: snd_soc_omap_hdmi omapdss snd_soc_omap_abe_twl6040 snd_soc_twl6040 snd_soc_omap snd_soc_omap_hdmi_card snd_soc_omap_mcpdm snd_soc_omap_mcbsp snd_soc_core snd_compress regmap_spi snd_pcm snd_page_alloc snd_timer snd soundcore CPU: 1 PID: 2790 Comm: perf_fuzzer Not tainted 3.11.0-rc4 #6 task: eddcab80 ti: ed892000 task.ti: ed892000 PC is at armpmu_map_event+0x20/0x88 LR is at armpmu_event_init+0x38/0x280 pc : [<c001c3e4>] lr : [<c001c17c>] psr: 60000013 sp : ed893e40 ip : ecececec fp : edfaec00 r10: 00000000 r9 : 00000000 r8 : ed8c3ac0 r7 : ed8c3b5c r6 : edfaec00 r5 : 00000000 r4 : 00000000 r3 : 000000ff r2 : c0496144 r1 : c049611c r0 : edfaec00 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: aca6c04a DAC: 00000015 Process perf_fuzzer (pid: 2790, stack limit = 0xed892240) Stack: (0xed893e40 to 0xed894000) 3e40: 00000800 c001c17c 00000002 c008a748 00000001 00000000 00000000 c00bf078 3e60: 00000000 edfaee50 00000000 00000000 00000000 edfaec00 ed8c3ac0 edfaec00 3e80: 00000000 c073ffac ed893f20 c00bf180 00000001 00000000 c00bf078 ed893f20 3ea0: 00000000 ed8c3ac0 00000000 00000000 00000000 c0cb0818 eddcab80 c00bf440 3ec0: ed893f20 00000000 eddcab80 eca76800 00000000 eca76800 00000000 00000000 3ee0: 00000000 ec984c80 eddcab80 c00bfe68 00000000 00000000 00000000 00000080 3f00: 00000000 ed892000 00000000 ed892030 00000004 ecc7e3c8 ecc7e3c8 00000000 3f20: 00000000 00000048 ecececec 00000000 00000000 00000000 00000000 00000000 3f40: 00000000 00000000 00297810 00000000 00000000 00000000 00000000 00000000 3f60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3f80: 00000002 00000002 000103a4 00000002 0000016c c00128e8 ed892000 00000000 3fa0: 00090998 c0012700 00000002 000103a4 00090ab8 00000000 00000000 0000000f 3fc0: 00000002 000103a4 00000002 0000016c 00090ab0 00090ab8 000107a0 00090998 3fe0: bed92be0 bed92bd0 0000b785 b6e8f6d0 40000010 00090ab8 00000000 00000000 [<c001c3e4>] (armpmu_map_event+0x20/0x88) from [<c001c17c>] (armpmu_event_init+0x38/0x280) [<c001c17c>] (armpmu_event_init+0x38/0x280) from [<c00bf180>] (perf_init_event+0x108/0x180) [<c00bf180>] (perf_init_event+0x108/0x180) from [<c00bf440>] (perf_event_alloc+0x248/0x40c) [<c00bf440>] (perf_event_alloc+0x248/0x40c) from [<c00bfe68>] (SyS_perf_event_open+0x4f4/0x8fc) [<c00bfe68>] (SyS_perf_event_open+0x4f4/0x8fc) from [<c0012700>] (ret_fast_syscall+0x0/0x48) Code: 0a000005 e3540004 0a000016 e3540000 (0791010c) This is because event->attr.config in armpmu_event_init() contains a very large number copied directly from userspace and is never checked against the size of the array indexed in armpmu_map_hw_event(). Fix the problem by checking the value of config before indexing the array and rejecting invalid config values. Reported-by: Vince Weaver <[email protected]> Tested-by: Vince Weaver <[email protected]> Acked-by: Will Deacon <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Russell King <[email protected]>
2013-08-13ARM: 7809/1: perf: fix event validation for software group leadersWill Deacon1-0/+3
It is possible to construct an event group with a software event as a group leader and then subsequently add a hardware event to the group. This results in the event group being validated by adding all members of the group to a fake PMU and attempting to allocate each event on their respective PMU. Unfortunately, for software events wthout a corresponding arm_pmu, this results in a kernel crash attempting to dereference the ->get_event_idx function pointer. This patch fixes the problem by checking explicitly for software events and ignoring those in event validation (since they can always be scheduled). We will probably want to revisit this for 3.12, since the validation checks don't appear to work correctly when dealing with multiple hardware PMUs anyway. Cc: <[email protected]> Reported-by: Vince Weaver <[email protected]> Tested-by: Vince Weaver <[email protected]> Tested-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Russell King <[email protected]>
2013-08-13clk: exynos4: Add CLK_GET_RATE_NOCACHE flag for the Exynos4x12 ISP clocksSylwester Nawrocki1-30/+34
The ISP clock registers belong to the ISP power domain and may change their values if this power domain is switched off/on. Add CLK_GET_RATE_NOCACHE flags to ensure we do not rely on invalid cached data when setting or getting frequency of those clocks. Without this fix the FIMC-IS Cortex-A5 core and AXI bus clocks have incorrect frequencies, which breaks the ISP operation and starting the video pipeline fails with timeouts reported by the FIMC-IS firmware. See related commit 722a860ecb29aa34ec6f7d7f32b949209e8 "[media] exynos4-is: Fix FIMC-IS clocks initialization" for more details. Signed-off-by: Sylwester Nawrocki <[email protected]> Signed-off-by: Kyungmin Park <[email protected]> Signed-off-by: Mike Turquette <[email protected]>
2013-08-13clk/zynq/clkc: Add CLK_SET_RATE_PARENT flag to ethernet muxesSoren Brinkmann1-4/+6
Zynq's Ethernet clocks are created by the following hierarchy: mux0 ---> div0 ---> div1 ---> mux1 ---> gate Rate change requests on the gate have to propagate all the way up to div0 to properly leverage all dividers. Mux1 was missing the CLK_SET_RATE_PARENT flag, which is required to achieve this. This does not fix a specific regression but the clock driver was merged for 3.11-rc1, so best to fix the known bugs before the release. Signed-off-by: Soren Brinkmann <[email protected]> Signed-off-by: Michal Simek <[email protected]> Signed-off-by: Mike Turquette <[email protected]> [[email protected]: added to changelog]
2013-08-13clk/zynq/clkc: Add dedicated spinlock for the SWDTSoren Brinkmann1-1/+2
The clk_mux for the system watchdog timer reused the register lock dedicated to the Ethernet module - for no apparent reason. Add a lock dedicated to the SWDT's clock register to remove this wrong dependency. This does not fix a specific regression but the clock driver was merged for 3.11-rc1, so best to fix the known bugs before the release. Signed-off-by: Soren Brinkmann <[email protected]> Signed-off-by: Michal Simek <[email protected]> Signed-off-by: Mike Turquette <[email protected]> [[email protected]: added to changelog]
2013-08-13sched: fix the theoretical signal_wake_up() vs schedule() raceOleg Nesterov3-8/+24
This is only theoretical, but after try_to_wake_up(p) was changed to check p->state under p->pi_lock the code like __set_current_state(TASK_INTERRUPTIBLE); schedule(); can miss a signal. This is the special case of wait-for-condition, it relies on try_to_wake_up/schedule interaction and thus it does not need mb() between __set_current_state() and if(signal_pending). However, this __set_current_state() can move into the critical section protected by rq->lock, now that try_to_wake_up() takes another lock we need to ensure that it can't be reordered with "if (signal_pending(current))" check inside that section. The patch is actually one-liner, it simply adds smp_wmb() before spin_lock_irq(rq->lock). This is what try_to_wake_up() already does by the same reason. We turn this wmb() into the new helper, smp_mb__before_spinlock(), for better documentation and to allow the architectures to change the default implementation. While at it, kill smp_mb__after_lock(), it has no callers. Perhaps we can also add smp_mb__before/after_spinunlock() for prepare_to_wait(). Signed-off-by: Oleg Nesterov <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2013-08-13cpuset: fix the return value of cpuset_write_u64()Li Zefan1-2/+4
Writing to this file always returns -ENODEV: # echo 1 > cpuset.memory_pressure_enabled -bash: echo: write error: No such device Signed-off-by: Li Zefan <[email protected]> Cc: <[email protected]> # 3.9+ Signed-off-by: Tejun Heo <[email protected]>
2013-08-13genetlink: fix family dump raceJohannes Berg1-0/+7
When dumping generic netlink families, only the first dump call is locked with genl_lock(), which protects the list of families, and thus subsequent calls can access the data without locking, racing against family addition/removal. This can cause a crash. Fix it - the locking needs to be conditional because the first time around it's already locked. A similar bug was reported to me on an old kernel (3.4.47) but the exact scenario that happened there is no longer possible, on those kernels the first round wasn't locked either. Looking at the current code I found the race described above, which had also existed on the old kernel. Cc: [email protected] Reported-by: Andrei Otcheretianski <[email protected]> Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-08-12net: sctp: sctp_transport_destroy{, _rcu}: fix potential pointer corruptionDaniel Borkmann1-2/+2
Probably this one is quite unlikely to be triggered, but it's more safe to do the call_rcu() at the end after we have dropped the reference on the asoc and freed sctp packet chunks. The reason why is because in sctp_transport_destroy_rcu() the transport is being kfree()'d, and if we're unlucky enough we could run into corrupted pointers. Probably that's more of theoretical nature, but it's safer to have this simple fix. Introduced by commit 8c98653f ("sctp: sctp_close: fix release of bindings for deferred call_rcu's"). I also did the 8c98653f regression test and it's fine that way. Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Vlad Yasevich <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-08-12net: sctp: sctp_assoc_control_transport: fix MTU size in SCTP_PF stateDaniel Borkmann1-2/+2
The SCTP Quick failover draft [1] section 5.1, point 5 says that the cwnd should be 1 MTU. So, instead of 1, set it to 1 MTU. [1] https://tools.ietf.org/html/draft-nishida-tsvwg-sctp-failover-05 Reported-by: Karl Heiss <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Cc: Neil Horman <[email protected]> Acked-by: Vlad Yasevich <[email protected]> Acked-by: Neil Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-08-12stmmac: fix init_dma_desc_rings() to handle errorsBartlomiej Zolnierkiewicz1-19/+92
In stmmac_init_rx_buffers(): * add missing handling of dma_map_single() error * remove superfluous unlikely() optimization while at it Add stmmac_free_rx_buffers() helper and use it in dma_free_rx_skbufs(). In init_dma_desc_rings(): * add missing handling of kmalloc_array() errors * fix handling of dma_alloc_coherent() and stmmac_init_rx_buffers() errors * make function return an error value on error and 0 on success In stmmac_open(): * add handling of init_dma_desc_rings() return value Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]> Signed-off-by: Kyungmin Park <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-08-12Merge branch 'for-next' of git://git.samba.org/sfrench/cifs-2.6Linus Torvalds11-51/+98
Pull CIFS fixes from Steve French: "A set of small cifs fixes, including 3 relating to symlink handling" * 'for-next' of git://git.samba.org/sfrench/cifs-2.6: cifs: don't instantiate new dentries in readdir for inodes that need to be revalidated immediately cifs: set sb->s_d_op before calling d_make_root() cifs: fix bad error handling in crypto code cifs: file: initialize oparms.reconnect before using it Do not attempt to do cifs operations reading symlinks with SMB2 cifs: extend the buffer length enought for sprintf() using
2013-08-12Merge tag 'ext4_for_linus' of ↵Linus Torvalds2-4/+21
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 Pull more ext4 bugfixes from Ted Ts'o: "A number of miscellaneous ext4 bugs fixes for v3.11, including a fix so that if ext4 is built as a module, to allow it to be unloaded" * tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: ext4: flush the extent status cache during EXT4_IOC_SWAP_BOOT ext4: fix mount/remount error messages for incompatible mount options ext4: allow the mount options nodelalloc and data=journal
2013-08-12USB: ti_usb_3410_5052: fix big-endian firmware handlingJohan Hovold1-4/+5
Fix endianess bugs in firmware handling introduced by commits cb7a7c6a ("ti_usb_3410_5052: add Multi-Tech modem support") and 05a3d905 ("ti_usb_3410_5052: support alternate firmware") which made the driver use the wrong firmware for certain devices on big-endian machines. Cc: [email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-08-12USB: adutux: fix big-endian device-type reportingJohan Hovold1-1/+1
Make sure the reported device-type on big-endian machines is the same as on little-endian ones. Cc: [email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-08-12USB: usbtmc: fix big-endian probe of Rigol devicesJohan Hovold1-4/+4
Fix probe of Rigol devices on big-endian machines. A quirk for these devices was introduced by commit c2e314835 ("USB: usbtmc: Set rigol_quirk if device is listed") but was only enabled on little-endian machines. Cc: [email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-08-12USB: mos7840: fix big-endian probeJohan Hovold1-1/+1
Fix bug in device-type detection on big-endian machines originally introduced by commit 0eafe4de ("USB: serial: mos7840: add support for MCS7810 devices") which always matched on little-endian product ids. Reported-by: kbuild test robot <[email protected]> Cc: [email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-08-12USB-Serial: Fix error handling of usb_wwanMatt Burtch1-10/+10
This fixes an issue where the bulk-in urb used for incoming data transfer is not resubmitted if the packet recieved contains an error status. This results in the driver locking until the port is closed and re-opened. Tested on a custom board with a Cinterion GSM module. Signed-off-by: Matt Burtch <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-08-12wusbcore: fix kernel panic when disconnecting a wireless USB->serial deviceThomas Pugliese1-2/+7
This patch fixes a kernel panic that can occur when disconnecting a wireless USB->serial device. When the serial device disconnects, the device cleanup procedure ends up calling usb_hcd_disable_endpoint on the serial device's endpoints. The wusbcore uses the ABORT_RPIPE command to abort all transfers on the given endpoint but it does not properly give back the URBs when the transfer results return from the HWA. This patch prevents the transfer result processing code from bailing out when it sees a WA_XFER_STATUS_ABORTED result code so that these urbs are flushed properly by usb_hcd_disable_endpoint. It also updates wa_urb_dequeue to handle the case where the endpoint has already been cleaned up when usb_kill_urb is called which is where the panic originally occurred. Signed-off-by: Thomas Pugliese <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-08-12USB: EHCI: accept very late isochronous URBsAlan Stern1-7/+6
Since commits 4005ad4390bf (EHCI: implement new semantics for URB_ISO_ASAP) and c75c5ab575af (ALSA: USB: adjust for changed 3.8 USB API) became widely distributed, people have been experiencing problems with audio transfers. The slightest underrun causes complete failure, requiring the audio stream to be restarted. It turns out that the current isochronous API doesn't handle underruns in the best way. The ALSA developers would much rather have transfers that are submitted too late be accepted and complete in the normal fashion, rather than being refused outright. This patch implements the requested approach. When an isochronous URB submission is so late that all its scheduled slots have already expired, a debugging message will be printed in the log and the URB will be accepted as usual. Assuming it was submitted by a completion handler (which is normally the case), it will complete shortly thereafter with all the usb_iso_packet_descriptor status fields marked -EXDEV. This fixes (for ehci-hcd) https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191603 It should be applied to all kernels that include commit 4005ad4390bf. Signed-off-by: Alan Stern <[email protected]> Tested-by: Maksim Boyko <[email protected]> CC: Clemens Ladisch <[email protected]> CC: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2013-08-12Merge branch 'core-urgent-for-linus' of ↵Linus Torvalds1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull w/w mutex deadlock injection fix from Ingo Molnar. This bug made the CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y option largely useless, but wouldn't affect normal users. * 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: mutex: Fix w/w mutex deadlock injection
2013-08-12x86, microcode, AMD: Fix early microcode loadingTorsten Kaiser3-29/+27
load_microcode_amd() (and the helper it is using) should not have an cpu parameter. The microcode loading does not depend on the CPU wrt the patches loaded since they will end up in a global list for all CPUs anyway. The change from cpu to x86family in load_microcode_amd() now allows to drop the code messing with cpu_data(cpu) from collect_cpu_info_amd_early(), which is wrong anyway because at that point the per-cpu cpu_info is not yet setup (These values would later be overwritten by smp_store_boot_cpu_info() / smp_store_cpu_info()). Fold the rest of collect_cpu_info_amd_early() into load_ucode_amd_ap(), because its only used at one place and without the cpuinfo_x86 accesses it was not much left. Signed-off-by: Torsten Kaiser <[email protected]> [ Fengguang: build fix ] Signed-off-by: Fengguang Wu <[email protected]> [ Boris: adapt it to current tree. ] Signed-off-by: Borislav Petkov <[email protected]>
2013-08-12x86, microcode, AMD: Make cpu_has_amd_erratum() use the correct struct ↵Torsten Kaiser1-15/+5
cpuinfo_x86 cpu_has_amd_erratum() is buggy, because it uses the per-cpu cpu_info before it is filled by smp_store_boot_cpu_info() / smp_store_cpu_info(). If early microcode loading is enabled its collect_cpu_info_amd_early() will fill ->x86 and so the fallback to boot_cpu_data is not used. But ->x86_vendor was not filled and is still X86_VENDOR_INTEL resulting in no errata fixes getting applied and my system hangs on boot. Using cpu_info in cpu_has_amd_erratum() is wrong anyway: its only caller init_amd() will have a struct cpuinfo_x86 as parameter and the set_cpu_bug() that is controlled by cpu_has_amd_erratum() also only uses that struct. So pass the struct cpuinfo_x86 from init_amd() to cpu_has_amd_erratum() and the broken fallback can be dropped. [ Boris: Drop WARN_ON() since we're called only from init_amd() ] Signed-off-by: Torsten Kaiser <[email protected]> Signed-off-by: Borislav Petkov <[email protected]>
2013-08-12Merge branch 'fortglx/3.11/time' of ↵Ingo Molnar1-1/+1
git://git.linaro.org/people/jstultz/linux into timers/urgent Pull small fix for v3.11 from John Stultz. Signed-off-by: Ingo Molnar <[email protected]>
2013-08-12drm/radeon: fix UVD message buffer validationChristian König1-0/+8
When the message buffer is currently moving block until it is idle again. Signed-off-by: Christian König <[email protected]> Cc: [email protected] Signed-off-by: Alex Deucher <[email protected]>
2013-08-12jbd2: Fix use after free after error in jbd2_journal_dirty_metadata()Jan Kara1-4/+4
When jbd2_journal_dirty_metadata() returns error, __ext4_handle_dirty_metadata() stops the handle. However callers of this function do not count with that fact and still happily used now freed handle. This use after free can result in various issues but very likely we oops soon. The motivation of adding __ext4_journal_stop() into __ext4_handle_dirty_metadata() in commit 9ea7a0df seems to be only to improve error reporting. So replace __ext4_journal_stop() with ext4_journal_abort_handle() which was there before that commit and add WARN_ON_ONCE() to dump stack to provide useful information. Reported-by: Sage Weil <[email protected]> Signed-off-by: Jan Kara <[email protected]> Signed-off-by: "Theodore Ts'o" <[email protected]> Cc: [email protected] # 3.2+
2013-08-12ext4: flush the extent status cache during EXT4_IOC_SWAP_BOOTTheodore Ts'o1-2/+4
Previously we weren't swapping only some of the extent_status LRU fields during the processing of the EXT4_IOC_SWAP_BOOT ioctl. The much safer thing to do is to just completely flush the extent status tree when doing the swap. Signed-off-by: "Theodore Ts'o" <[email protected]> Cc: Zheng Liu <[email protected]> Cc: [email protected]
2013-08-12ALSA: usb-audio: Fix invalid volume resolution for Logitech HD Webcam C525Maksim A. Boyko1-0/+1
Add the volume control quirk for avoiding the kernel warning for the Logitech HD Webcam C525 as in the similar commit 36691e1be6ec551eef4a5225f126a281f8c051c2 for the Logitech HD Webcam C310. Reported-by: Maksim Boyko <[email protected]> Tested-by: Maksim Boyko <[email protected]> Cc: <[email protected]> # 3.10.5+ Signed-off-by: Maksim Boyko <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2013-08-12perf/x86: Add Haswell ULT model number used in Macbook Air and other systemsAndi Kleen1-0/+1
This one was missed earlier. Signed-off-by: Andi Kleen <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2013-08-12ALSA: hda - Fix missing mute controls for CX5051Takashi Iwai1-3/+3
We've added a fake mute control (setting the amp volume to zero) for CX5051 at commit [3868137e: ALSA: hda - Add a fake mute feature], but this feature was overlooked in the generic parser implementation. Now the driver lacks of mute controls on these codecs. The fix is just to check both AC_AMPCAP_MUTE and AC_AMPCAP_MIN_MUTE bits in each place checking the amp capabilities. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59001 Cc: <[email protected]> [v3.9+] Signed-off-by: Takashi Iwai <[email protected]>
2013-08-12ALSA: usb-audio: fix automatic Roland/Yamaha MIDI detectionClemens Ladisch1-3/+3
Commit aafe77cc45a5 (ALSA: usb-audio: add support for many Roland/Yamaha devices) had several logic errors that prevented create_auto_midi_quirk from enumerating any MIDI ports. Reported-by: Keith A. Milner <[email protected]> Signed-off-by: Clemens Ladisch <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2013-08-12ALSA: 6fire: make buffers DMA-able (midi)Torsten Schenk2-6/+16
Patch makes midi output buffer DMA-able by allocating it separately. Signed-off-by: Torsten Schenk <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2013-08-12ALSA: 6fire: make buffers DMA-able (pcm)Torsten Schenk2-2/+41
Patch makes pcm buffers DMA-able by allocating each one separately. Signed-off-by: Torsten Schenk <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2013-08-12ALSA: hda - Add pinfix for LG LW25 laptopTakashi Iwai1-0/+10
Correct the pins for a line-in and a headphone on LG LW25 laptop with ALC880 codec. Other pins seem fine. Reported-and-tested-by: Joonas Saarinen <[email protected]> Cc: <[email protected]> [v3.9+] Signed-off-by: Takashi Iwai <[email protected]>
2013-08-12Merge tag 'kvm-arm-fixes-3.11' of ↵Paolo Bonzini5-30/+44
git://git.linaro.org/people/cdall/linux-kvm-arm into kvm-master KVM/ARM Fixes for the Linux 3.11 release
2013-08-12Merge branch 'kvm-arm64/fixes-3.11-rc4' of ↵Paolo Bonzini713-6796/+10703
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into kvm-master
2013-08-11tipc: avoid possible deadlock while enable and disable bearerdingtianhong1-2/+7
We met lockdep warning when enable and disable the bearer for commands such as: tipc-config -netid=1234 -addr=1.1.3 -be=eth:eth0 tipc-config -netid=1234 -addr=1.1.3 -bd=eth:eth0 --------------------------------------------------- [ 327.693595] ====================================================== [ 327.693994] [ INFO: possible circular locking dependency detected ] [ 327.694519] 3.11.0-rc3-wwd-default #4 Tainted: G O [ 327.694882] ------------------------------------------------------- [ 327.695385] tipc-config/5825 is trying to acquire lock: [ 327.695754] (((timer))#2){+.-...}, at: [<ffffffff8105be80>] del_timer_sync+0x0/0xd0 [ 327.696018] [ 327.696018] but task is already holding lock: [ 327.696018] (&(&b_ptr->lock)->rlock){+.-...}, at: [<ffffffffa02be58d>] bearer_disable+ 0xdd/0x120 [tipc] [ 327.696018] [ 327.696018] which lock already depends on the new lock. [ 327.696018] [ 327.696018] [ 327.696018] the existing dependency chain (in reverse order) is: [ 327.696018] [ 327.696018] -> #1 (&(&b_ptr->lock)->rlock){+.-...}: [ 327.696018] [<ffffffff810b3b4d>] validate_chain+0x6dd/0x870 [ 327.696018] [<ffffffff810b40bb>] __lock_acquire+0x3db/0x670 [ 327.696018] [<ffffffff810b4453>] lock_acquire+0x103/0x130 [ 327.696018] [<ffffffff814d65b1>] _raw_spin_lock_bh+0x41/0x80 [ 327.696018] [<ffffffffa02c5d48>] disc_timeout+0x18/0xd0 [tipc] [ 327.696018] [<ffffffff8105b92a>] call_timer_fn+0xda/0x1e0 [ 327.696018] [<ffffffff8105bcd7>] run_timer_softirq+0x2a7/0x2d0 [ 327.696018] [<ffffffff8105379a>] __do_softirq+0x16a/0x2e0 [ 327.696018] [<ffffffff81053a35>] irq_exit+0xd5/0xe0 [ 327.696018] [<ffffffff81033005>] smp_apic_timer_interrupt+0x45/0x60 [ 327.696018] [<ffffffff814df4af>] apic_timer_interrupt+0x6f/0x80 [ 327.696018] [<ffffffff8100b70e>] arch_cpu_idle+0x1e/0x30 [ 327.696018] [<ffffffff810a039d>] cpu_idle_loop+0x1fd/0x280 [ 327.696018] [<ffffffff810a043e>] cpu_startup_entry+0x1e/0x20 [ 327.696018] [<ffffffff81031589>] start_secondary+0x89/0x90 [ 327.696018] [ 327.696018] -> #0 (((timer))#2){+.-...}: [ 327.696018] [<ffffffff810b33fe>] check_prev_add+0x43e/0x4b0 [ 327.696018] [<ffffffff810b3b4d>] validate_chain+0x6dd/0x870 [ 327.696018] [<ffffffff810b40bb>] __lock_acquire+0x3db/0x670 [ 327.696018] [<ffffffff810b4453>] lock_acquire+0x103/0x130 [ 327.696018] [<ffffffff8105bebd>] del_timer_sync+0x3d/0xd0 [ 327.696018] [<ffffffffa02c5855>] tipc_disc_delete+0x15/0x30 [tipc] [ 327.696018] [<ffffffffa02be59f>] bearer_disable+0xef/0x120 [tipc] [ 327.696018] [<ffffffffa02be74f>] tipc_disable_bearer+0x2f/0x60 [tipc] [ 327.696018] [<ffffffffa02bfb32>] tipc_cfg_do_cmd+0x2e2/0x550 [tipc] [ 327.696018] [<ffffffffa02c8c79>] handle_cmd+0x49/0xe0 [tipc] [ 327.696018] [<ffffffff8143e898>] genl_family_rcv_msg+0x268/0x340 [ 327.696018] [<ffffffff8143ed30>] genl_rcv_msg+0x70/0xd0 [ 327.696018] [<ffffffff8143d4c9>] netlink_rcv_skb+0x89/0xb0 [ 327.696018] [<ffffffff8143e617>] genl_rcv+0x27/0x40 [ 327.696018] [<ffffffff8143d21e>] netlink_unicast+0x15e/0x1b0 [ 327.696018] [<ffffffff8143ddcf>] netlink_sendmsg+0x22f/0x400 [ 327.696018] [<ffffffff813f7836>] __sock_sendmsg+0x66/0x80 [ 327.696018] [<ffffffff813f7957>] sock_aio_write+0x107/0x120 [ 327.696018] [<ffffffff8117f76d>] do_sync_write+0x7d/0xc0 [ 327.696018] [<ffffffff8117fc56>] vfs_write+0x186/0x190 [ 327.696018] [<ffffffff811803e0>] SyS_write+0x60/0xb0 [ 327.696018] [<ffffffff814de852>] system_call_fastpath+0x16/0x1b [ 327.696018] [ 327.696018] other info that might help us debug this: [ 327.696018] [ 327.696018] Possible unsafe locking scenario: [ 327.696018] [ 327.696018] CPU0 CPU1 [ 327.696018] ---- ---- [ 327.696018] lock(&(&b_ptr->lock)->rlock); [ 327.696018] lock(((timer))#2); [ 327.696018] lock(&(&b_ptr->lock)->rlock); [ 327.696018] lock(((timer))#2); [ 327.696018] [ 327.696018] *** DEADLOCK *** [ 327.696018] [ 327.696018] 5 locks held by tipc-config/5825: [ 327.696018] #0: (cb_lock){++++++}, at: [<ffffffff8143e608>] genl_rcv+0x18/0x40 [ 327.696018] #1: (genl_mutex){+.+.+.}, at: [<ffffffff8143ed66>] genl_rcv_msg+0xa6/0xd0 [ 327.696018] #2: (config_mutex){+.+.+.}, at: [<ffffffffa02bf889>] tipc_cfg_do_cmd+0x39/ 0x550 [tipc] [ 327.696018] #3: (tipc_net_lock){++.-..}, at: [<ffffffffa02be738>] tipc_disable_bearer+ 0x18/0x60 [tipc] [ 327.696018] #4: (&(&b_ptr->lock)->rlock){+.-...}, at: [<ffffffffa02be58d>] bearer_disable+0xdd/0x120 [tipc] [ 327.696018] [ 327.696018] stack backtrace: [ 327.696018] CPU: 2 PID: 5825 Comm: tipc-config Tainted: G O 3.11.0-rc3-wwd- default #4 [ 327.696018] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 [ 327.696018] 00000000ffffffff ffff880037fa77a8 ffffffff814d03dd 0000000000000000 [ 327.696018] ffff880037fa7808 ffff880037fa77e8 ffffffff810b1c4f 0000000037fa77e8 [ 327.696018] ffff880037fa7808 ffff880037e4db40 0000000000000000 ffff880037e4e318 [ 327.696018] Call Trace: [ 327.696018] [<ffffffff814d03dd>] dump_stack+0x4d/0xa0 [ 327.696018] [<ffffffff810b1c4f>] print_circular_bug+0x10f/0x120 [ 327.696018] [<ffffffff810b33fe>] check_prev_add+0x43e/0x4b0 [ 327.696018] [<ffffffff810b3b4d>] validate_chain+0x6dd/0x870 [ 327.696018] [<ffffffff81087a28>] ? sched_clock_cpu+0xd8/0x110 [ 327.696018] [<ffffffff810b40bb>] __lock_acquire+0x3db/0x670 [ 327.696018] [<ffffffff810b4453>] lock_acquire+0x103/0x130 [ 327.696018] [<ffffffff8105be80>] ? try_to_del_timer_sync+0x70/0x70 [ 327.696018] [<ffffffff8105bebd>] del_timer_sync+0x3d/0xd0 [ 327.696018] [<ffffffff8105be80>] ? try_to_del_timer_sync+0x70/0x70 [ 327.696018] [<ffffffffa02c5855>] tipc_disc_delete+0x15/0x30 [tipc] [ 327.696018] [<ffffffffa02be59f>] bearer_disable+0xef/0x120 [tipc] [ 327.696018] [<ffffffffa02be74f>] tipc_disable_bearer+0x2f/0x60 [tipc] [ 327.696018] [<ffffffffa02bfb32>] tipc_cfg_do_cmd+0x2e2/0x550 [tipc] [ 327.696018] [<ffffffff81218783>] ? security_capable+0x13/0x20 [ 327.696018] [<ffffffffa02c8c79>] handle_cmd+0x49/0xe0 [tipc] [ 327.696018] [<ffffffff8143e898>] genl_family_rcv_msg+0x268/0x340 [ 327.696018] [<ffffffff8143ed30>] genl_rcv_msg+0x70/0xd0 [ 327.696018] [<ffffffff8143ecc0>] ? genl_lock+0x20/0x20 [ 327.696018] [<ffffffff8143d4c9>] netlink_rcv_skb+0x89/0xb0 [ 327.696018] [<ffffffff8143e608>] ? genl_rcv+0x18/0x40 [ 327.696018] [<ffffffff8143e617>] genl_rcv+0x27/0x40 [ 327.696018] [<ffffffff8143d21e>] netlink_unicast+0x15e/0x1b0 [ 327.696018] [<ffffffff81289d7c>] ? memcpy_fromiovec+0x6c/0x90 [ 327.696018] [<ffffffff8143ddcf>] netlink_sendmsg+0x22f/0x400 [ 327.696018] [<ffffffff813f7836>] __sock_sendmsg+0x66/0x80 [ 327.696018] [<ffffffff813f7957>] sock_aio_write+0x107/0x120 [ 327.696018] [<ffffffff813fe29c>] ? release_sock+0x8c/0xa0 [ 327.696018] [<ffffffff8117f76d>] do_sync_write+0x7d/0xc0 [ 327.696018] [<ffffffff8117fa24>] ? rw_verify_area+0x54/0x100 [ 327.696018] [<ffffffff8117fc56>] vfs_write+0x186/0x190 [ 327.696018] [<ffffffff811803e0>] SyS_write+0x60/0xb0 [ 327.696018] [<ffffffff814de852>] system_call_fastpath+0x16/0x1b ----------------------------------------------------------------------- The problem is that the tipc_link_delete() will cancel the timer disc_timeout() when the b_ptr->lock is hold, but the disc_timeout() still call b_ptr->lock to finish the work, so the dead lock occurs. We should unlock the b_ptr->lock when del the disc_timeout(). Remove link_timeout() still met the same problem, the patch: http://article.gmane.org/gmane.network.tipc.general/4380 fix the problem, so no need to send patch for fix link_timeout() deadlock warming. Signed-off-by: Wang Weidong <[email protected]> Signed-off-by: Ding Tianhong <[email protected]> Acked-by: Ying Xue <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-08-11can: pcan_usb: fix wrong memcpy() bytes lengthStephane Grosjean1-1/+1
Fix possibly wrong memcpy() bytes length since some CAN records received from PCAN-USB could define a DLC field in range [9..15]. In that case, the real DLC value MUST be used to move forward the record pointer but, only 8 bytes max. MUST be copied into the data field of the struct can_frame object of the skb given to the network core. Cc: linux-stable <[email protected]> Signed-off-by: Stephane Grosjean <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.