commit 398cabc86ead423ba7a808f45a82a95c2ac5a9d9 Author: Ben Hutchings Date: Wed Jun 19 02:17:03 2013 +0100 Linux 3.2.47 commit e4f37de094d8c0a55af0fe63d7f715457b2de3e6 Author: Paul Mackerras Date: Fri Jun 14 20:07:41 2013 +1000 powerpc: Fix emulation of illegal instructions on PowerNV platform commit bf593907f7236e95698a76b7c7a2bbf8b1165327 upstream. Normally, the kernel emulates a few instructions that are unimplemented on some processors (e.g. the old dcba instruction), or privileged (e.g. mfpvr). The emulation of unimplemented instructions is currently not working on the PowerNV platform. The reason is that on these machines, unimplemented and illegal instructions cause a hypervisor emulation assist interrupt, rather than a program interrupt as on older CPUs. Our vector for the emulation assist interrupt just calls program_check_exception() directly, without setting the bit in SRR1 that indicates an illegal instruction interrupt. This fixes it by making the emulation assist interrupt set that bit before calling program_check_interrupt(). With this, old programs that use no-longer implemented instructions such as dcba now work again. Signed-off-by: Paul Mackerras Signed-off-by: Benjamin Herrenschmidt [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 08647d0f99db39f73f37e00ebafc24ff3d3f4948 Author: Nithin Sujir Date: Wed Jun 12 11:08:59 2013 -0700 tg3: Wait for boot code to finish after power on commit df465abfe06f7dc4f33f4a96d17f096e9e8ac917 upstream. Some systems that don't need wake-on-lan may choose to power down the chip on system standby. Upon resume, the power on causes the boot code to startup and initialize the hardware. On one new platform, this is causing the device to go into a bad state due to a race between the driver and boot code, once every several hundred resumes. The same race exists on open since we come up from a power on. This patch adds a wait for boot code signature at the beginning of tg3_init_hw() which is common to both cases. If there has not been a power-off or the boot code has already completed, the signature will be present and poll_fw() returns immediately. Also return immediately if the device does not have firmware. Signed-off-by: Nithin Nayak Sujir Signed-off-by: Michael Chan Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 58e06b1d5e77f6cbed3cddc39e7d782d462e1883 Author: Alex Lyakas Date: Tue Jun 4 20:42:21 2013 +0300 md/raid1: consider WRITE as successful only if at least one non-Faulty and non-rebuilding drive completed it. commit 3056e3aec8d8ba61a0710fb78b2d562600aa2ea7 upstream. Without that fix, the following scenario could happen: - RAID1 with drives A and B; drive B was freshly-added and is rebuilding - Drive A fails - WRITE request arrives to the array. It is failed by drive A, so r1_bio is marked as R1BIO_WriteError, but the rebuilding drive B succeeds in writing it, so the same r1_bio is marked as R1BIO_Uptodate. - r1_bio arrives to handle_write_finished, badblocks are disabled, md_error()->error() does nothing because we don't fail the last drive of raid1 - raid_end_bio_io() calls call_bio_endio() - As a result, in call_bio_endio(): if (!test_bit(R1BIO_Uptodate, &r1_bio->state)) clear_bit(BIO_UPTODATE, &bio->bi_flags); this code doesn't clear the BIO_UPTODATE flag, and the whole master WRITE succeeds, back to the upper layer. So we returned success to the upper layer, even though we had written the data onto the rebuilding drive only. But when we want to read the data back, we would not read from the rebuilding drive, so this data is lost. [neilb - applied identical change to raid10 as well] This bug can result in lost data, so it is suitable for any -stable kernel. Signed-off-by: Alex Lyakas Signed-off-by: NeilBrown [bwh: Backported to 3.2: for raid10, s/rdev/conf->mirrors[dev].rdev/] Signed-off-by: Ben Hutchings commit c161265b6435d331954ffe056559dfda7f9f7ba1 Author: Kees Cook Date: Wed Jun 5 11:47:18 2013 -0700 x86: Fix typo in kexec register clearing commit c8a22d19dd238ede87aa0ac4f7dbea8da039b9c1 upstream. Fixes a typo in register clearing code. Thanks to PaX Team for fixing this originally, and James Troup for pointing it out. Signed-off-by: Kees Cook Link: http://lkml.kernel.org/r/20130605184718.GA8396@www.outflux.net Cc: PaX Team Signed-off-by: H. Peter Anvin Signed-off-by: Ben Hutchings commit 0f9613bfc25a11c5ed61c2213031b209381619cc Author: Johan Hovold Date: Mon Jun 10 18:29:38 2013 +0200 USB: pl2303: fix device initialisation at open commit 2d8f4447b58bba5f8cb895c07690434c02307eaf upstream. Do not use uninitialised termios data to determine when to configure the device at open. This also prevents stack data from leaking to userspace in the OOM error path. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: tty_struct::termios is a pointer, not a struct] Signed-off-by: Ben Hutchings commit 9e5adb3632ba5664767ff5f41d3f584d9de102b8 Author: Johan Hovold Date: Mon Jun 10 18:29:39 2013 +0200 USB: spcp8x5: fix device initialisation at open commit 5e4211f1c47560c36a8b3d4544dfd866dcf7ccd0 upstream. Do not use uninitialised termios data to determine when to configure the device at open. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: tty_struct::termios is a pointer, not a struct] Signed-off-by: Ben Hutchings commit 4207b3f2766e3862d8a0406898236a1eaf226678 Author: Naoya Horiguchi Date: Wed Jun 12 14:05:04 2013 -0700 mm: migration: add migrate_entry_wait_huge() commit 30dad30922ccc733cfdbfe232090cf674dc374dc upstream. When we have a page fault for the address which is backed by a hugepage under migration, the kernel can't wait correctly and do busy looping on hugepage fault until the migration finishes. As a result, users who try to kick hugepage migration (via soft offlining, for example) occasionally experience long delay or soft lockup. This is because pte_offset_map_lock() can't get a correct migration entry or a correct page table lock for hugepage. This patch introduces migration_entry_wait_huge() to solve this. Signed-off-by: Naoya Horiguchi Reviewed-by: Rik van Riel Reviewed-by: Wanpeng Li Reviewed-by: Michal Hocko Cc: Mel Gorman Cc: Andi Kleen Cc: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 1d9910635dfc24ecac41129b5f4752b403194ab4 Author: Rafael Aquini Date: Wed Jun 12 14:04:49 2013 -0700 swap: avoid read_swap_cache_async() race to deadlock while waiting on discard I/O completion commit cbab0e4eec299e9059199ebe6daf48730be46d2b upstream. read_swap_cache_async() can race against get_swap_page(), and stumble across a SWAP_HAS_CACHE entry in the swap map whose page wasn't brought into the swapcache yet. This transient swap_map state is expected to be transitory, but the actual placement of discard at scan_swap_map() inserts a wait for I/O completion thus making the thread at read_swap_cache_async() to loop around its -EEXIST case, while the other end at get_swap_page() is scheduled away at scan_swap_map(). This can leave the system deadlocked if the I/O completion happens to be waiting on the CPU waitqueue where read_swap_cache_async() is busy looping and !CONFIG_PREEMPT. This patch introduces a cond_resched() call to make the aforementioned read_swap_cache_async() busy loop condition to bail out when necessary, thus avoiding the subtle race window. Signed-off-by: Rafael Aquini Acked-by: Johannes Weiner Acked-by: KOSAKI Motohiro Acked-by: Hugh Dickins Cc: Shaohua Li Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit d3bfb85149dc6f19e914125c65167861c05b1511 Author: Tony Lindgren Date: Wed Jun 12 14:04:48 2013 -0700 drivers/rtc/rtc-twl.c: fix missing device_init_wakeup() when booted with device tree commit 24b8256a1fb28d357bc6fa09184ba29b4255ba5c upstream. When booted in legacy mode device_init_wakeup() gets called by drivers/mfd/twl-core.c when the children are initialized. However, when booted using device tree, the children are created with of_platform_populate() instead add_children(). This means that the RTC driver will not have device_init_wakeup() set, and we need to call it from the driver probe like RTC drivers typically do. Without this we cannot test PM wake-up events on omaps for cases where there may not be any physical wake-up event. Signed-off-by: Tony Lindgren Reported-by: Kevin Hilman Cc: Alessandro Zummo Cc: Jingoo Han Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 0704e88cdcd7eb0363374ba9443991b1021b62fc Author: Stephen M. Cameron Date: Wed Jun 12 14:04:47 2013 -0700 cciss: fix broken mutex usage in ioctl commit 03f47e888daf56c8e9046c674719a0bcc644eed5 upstream. If a new logical drive is added and the CCISS_REGNEWD ioctl is invoked (as is normal with the Array Configuration Utility) the process will hang as below. It attempts to acquire the same mutex twice, once in do_ioctl() and once in cciss_unlocked_open(). The BKL was recursive, the mutex isn't. Linux version 3.10.0-rc2 (scameron@localhost.localdomain) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) ) #1 SMP Fri May 24 14:32:12 CDT 2013 [...] acu D 0000000000000001 0 3246 3191 0x00000080 Call Trace: schedule+0x29/0x70 schedule_preempt_disabled+0xe/0x10 __mutex_lock_slowpath+0x17b/0x220 mutex_lock+0x2b/0x50 cciss_unlocked_open+0x2f/0x110 [cciss] __blkdev_get+0xd3/0x470 blkdev_get+0x5c/0x1e0 register_disk+0x182/0x1a0 add_disk+0x17c/0x310 cciss_add_disk+0x13a/0x170 [cciss] cciss_update_drive_info+0x39b/0x480 [cciss] rebuild_lun_table+0x258/0x370 [cciss] cciss_ioctl+0x34f/0x470 [cciss] do_ioctl+0x49/0x70 [cciss] __blkdev_driver_ioctl+0x28/0x30 blkdev_ioctl+0x200/0x7b0 block_ioctl+0x3c/0x40 do_vfs_ioctl+0x89/0x350 SyS_ioctl+0xa1/0xb0 system_call_fastpath+0x16/0x1b This mutex usage was added into the ioctl path when the big kernel lock was removed. As it turns out, these paths are all thread safe anyway (or can easily be made so) and we don't want ioctl() to be single threaded in any case. Signed-off-by: Stephen M. Cameron Cc: Jens Axboe Cc: Mike Miller Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 4d839b14d2091a224a6d0a6fa1cffa58fc00d8a7 Author: Oleg Nesterov Date: Wed Jun 12 14:04:46 2013 -0700 audit: wait_for_auditd() should use TASK_UNINTERRUPTIBLE commit f000cfdde5de4fc15dead5ccf524359c07eadf2b upstream. audit_log_start() does wait_for_auditd() in a loop until audit_backlog_wait_time passes or audit_skb_queue has a room. If signal_pending() is true this becomes a busy-wait loop, schedule() in TASK_INTERRUPTIBLE won't block. Thanks to Guy for fully investigating and explaining the problem. (akpm: that'll cause the system to lock up on a non-preemptible uniprocessor kernel) (Guy: "Our customer was in fact running a uniprocessor machine, and they reported a system hang.") Signed-off-by: Oleg Nesterov Reported-by: Guy Streeter Cc: Eric Paris Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: adjust context, indentation] Signed-off-by: Ben Hutchings commit c32d723b2c7aa214602b626a5af32f8fc4ec5571 Author: Robin Holt Date: Wed Jun 12 14:04:37 2013 -0700 reboot: rigrate shutdown/reboot to boot cpu commit cf7df378aa4ff7da3a44769b7ff6e9eef1a9f3db upstream. We recently noticed that reboot of a 1024 cpu machine takes approx 16 minutes of just stopping the cpus. The slowdown was tracked to commit f96972f2dc63 ("kernel/sys.c: call disable_nonboot_cpus() in kernel_restart()"). The current implementation does all the work of hot removing the cpus before halting the system. We are switching to just migrating to the boot cpu and then continuing with shutdown/reboot. This also has the effect of not breaking x86's command line parameter for specifying the reboot cpu. Note, this code was shamelessly copied from arch/x86/kernel/reboot.c with bits removed pertaining to the reboot_cpu command line parameter. Signed-off-by: Robin Holt Tested-by: Shawn Guo Cc: "Srivatsa S. Bhat" Cc: H. Peter Anvin Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Russ Anderson Cc: Robin Holt Cc: Russell King Cc: Guan Xuetao Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 1b3b08bec4f7bdf1c8b3a822439b070862179415 Author: Srivatsa S. Bhat Date: Wed Jun 12 14:04:36 2013 -0700 CPU hotplug: provide a generic helper to disable/enable CPU hotplug commit 16e53dbf10a2d7e228709a7286310e629ede5e45 upstream. There are instances in the kernel where we would like to disable CPU hotplug (from sysfs) during some important operation. Today the freezer code depends on this and the code to do it was kinda tailor-made for that. Restructure the code and make it generic enough to be useful for other usecases too. Signed-off-by: Srivatsa S. Bhat Signed-off-by: Robin Holt Cc: H. Peter Anvin Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Russ Anderson Cc: Robin Holt Cc: Russell King Cc: Guan Xuetao Cc: Shawn Guo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit bfb624e7fd41437a2c256adaf4041fe4414f8f26 Author: Kees Cook Date: Fri May 10 14:48:21 2013 -0700 b43: stop format string leaking into error msgs commit e0e29b683d6784ef59bbc914eac85a04b650e63c upstream. The module parameter "fwpostfix" is userspace controllable, unfiltered, and is used to define the firmware filename. b43_do_request_fw() populates ctx->errors[] on error, containing the firmware filename. b43err() parses its arguments as a format string. For systems with b43 hardware, this could lead to a uid-0 to ring-0 escalation. CVE-2013-2852 Signed-off-by: Kees Cook Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit 9fa72f6b1b0faa477a8317902e6f6eb2b32c832d Author: Sujith Manoharan Date: Thu Jun 6 10:06:29 2013 +0530 ath9k: Use minstrel rate control by default commit 5efac94999ff218e0101f67a059e44abb4b0b523 upstream. The ath9k rate control algorithm has various architectural issues that make it a poor fit in scenarios like congested environments etc. An example: https://bugzilla.redhat.com/show_bug.cgi?id=927191 Change the default to minstrel which is more robust in such cases. The ath9k RC code is left in the driver for now, maybe it can be removed altogether later on. Cc: Jouni Malinen Cc: Linus Torvalds Signed-off-by: Sujith Manoharan Signed-off-by: John W. Linville [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit ee586238738e79c05ad7c079f4a0e907ed93dfbc Author: Sujith Manoharan Date: Sat Jun 1 07:08:09 2013 +0530 ath9k: Disable PowerSave by default commit 531671cb17af07281e6f28c1425f754346e65c41 upstream. Almost all the DMA issues which have plagued ath9k (in station mode) for years are related to PS. Disabling PS usually "fixes" the user's connection stablility. Reports of DMA problems are still trickling in and are sitting in the kernel bugzilla. Until the PS code in ath9k is given a thorough review, disbale it by default. The slight increase in chip power consumption is a small price to pay for improved link stability. Signed-off-by: Sujith Manoharan Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit 90647b580ec248f93a3b8dceb4bcc4ca6dc325d3 Author: Johan Hedberg Date: Tue May 28 13:46:30 2013 +0300 Bluetooth: Fix missing length checks for L2CAP signalling PDUs commit cb3b3152b2f5939d67005cff841a1ca748b19888 upstream. There has been code in place to check that the L2CAP length header matches the amount of data received, but many PDU handlers have not been checking that the data received actually matches that expected by the specific PDU. This patch adds passing the length header to the specific handler functions and ensures that those functions fail cleanly in the case of an incorrect amount of data. Signed-off-by: Johan Hedberg Signed-off-by: Gustavo Padovan Signed-off-by: John W. Linville [bwh: Backported to 3.2: - Adjust context - Move uses of *req below the new check in l2cap_connect_req] Signed-off-by: Ben Hutchings commit 8548c6942cbce6a38d3dd9e218e043dd1e1941d0 Author: Daniel Vetter Date: Mon Jun 10 09:47:58 2013 +0200 drm/i915: prefer VBT modes for SVDO-LVDS over EDID commit c3456fb3e4712d0448592af3c5d644c9472cd3c1 upstream. In commit 53d3b4d7778daf15900867336c85d3f8dd70600c Author: Egbert Eich Date: Tue Jun 4 17:13:21 2013 +0200 drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC Egbert Eich fixed a long-standing bug where we simply used a non-working i2c controller to read the EDID for SDVO-LVDS panels. Unfortunately some machines seem to not be able to cope with the mode provided in the EDID. Specifically they seem to not be able to cope with a 4x pixel mutliplier instead of a 2x one, which seems to have been worked around by slightly changing the panels native mode in the VBT so that the dotclock is just barely above 50MHz. Since it took forever to notice the breakage it's fairly safe to assume that at least for SDVO-LVDS panels the VBT contains fairly sane data. So just switch around the order and use VBT modes first. v2: Also add EDID modes just in case, and spell Egbert correctly. v3: Elaborate a bit more about what's going on on Chris' machine. Cc: Egbert Eich Cc: Chris Wilson Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65524 Reported-and-tested-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Ben Hutchings commit 872f4ee92a00483332e5bfe7983716d132b5e9ec Author: Patrik Jakobsson Date: Sat Jun 8 20:23:08 2013 +0200 drm/gma500/cdv: Unpin framebuffer on crtc disable commit 22e7c385a80d771aaf3a15ae7ccea3b0686bbe10 upstream. The framebuffer needs to be unpinned in the crtc->disable callback because of previous pinning in psb_intel_pipe_set_base(). This will fix a memory leak where the framebuffer was released but not unpinned properly. This patch only affects Cedarview. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=889511 Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=812113 Reviewed-by: Daniel Vetter Signed-off-by: Patrik Jakobsson [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings commit f5c265c7952623969967def921652c12448cbf66 Author: Patrik Jakobsson Date: Wed Jun 5 14:24:01 2013 +0200 drm/gma500/psb: Unpin framebuffer on crtc disable commit 820de86a90089ee607d7864538c98a23b503c846 upstream. The framebuffer needs to be unpinned in the crtc->disable callback because of previous pinning in psb_intel_pipe_set_base(). This will fix a memory leak where the framebuffer was released but not unpinned properly. This patch only affects Poulsbo. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=889511 Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=812113 Reviewed-by: Daniel Vetter Signed-off-by: Patrik Jakobsson [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings commit 696a09ee1eaf62178a4e2c75af61048a6acdea5f Author: Guenter Roeck Date: Wed Jun 5 14:09:30 2013 -0700 hwmon: (adm1021) Strengthen chip detection for ADM1021, LM84 and MAX1617 commit 591bfcfc334a003ba31c0deff03b22e73349939b upstream. On a system with both MAX1617 and JC42 sensors, JC42 sensors can be misdetected as LM84. Strengthen detection sufficiently enough to avoid this misdetection. Also improve detection for ADM1021. Modeled after chip detection code in sensors-detect command. Signed-off-by: Guenter Roeck Tested-by: Jean Delvare Acked-by: Jean Delvare Signed-off-by: Ben Hutchings commit 3c52ce97a62a6b5fcf5b89a67fdb667f52705e29 Author: Bjørn Mork Date: Thu Jun 6 12:57:24 2013 +0200 USB: option: blacklist network interface on Huawei E1820 commit b8a24e6281d37243c06b9497dcbfaa98c1e2ad35 upstream. The mode used by Windows for the Huawei E1820 will use the same ff/ff/ff class codes for both serial and network functions. Reported-by: Graham Inggs Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit d5567ec48e25d29d61a33bccd6047e1f7bd82da9 Author: Johan Hovold Date: Thu Jun 6 13:32:47 2013 +0200 USB: whiteheat: fix broken port configuration commit 9eecf22d2b375b9064a20421c6c307b760b03d46 upstream. When configuring the port (e.g. set_termios) the port minor number rather than the port number was used in the request (and they only coincide for minor number 0). Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 5b9ca6b68cfa7fffcf9db83dbca90bbcad57d040 Author: Arnd Bergmann Date: Fri May 31 22:50:47 2013 +0100 ARM: 7743/1: compressed/head.S: work around new binutils warning commit da94a829305f1c217cfdf6771cb1faca0917e3b9 upstream. In August 2012, Matthew Gretton-Dann checked a change into binutils labelled "Error on obsolete & warn on deprecated registers", apparently as part of ARMv8 support. Apparently, this was supposed to emit the message "Warning: This coprocessor register access is deprecated in ARMv8" when using certain mcr/mrc instructions and building for ARMv8. Unfortunately, the message that is actually emitted appears to be '(null)', which is less helpful in comparison. Even more unfortunately, this is biting us on every single kernel build with a new gas, because arch/arm/boot/compressed/head.S and some other files in that directory are built with -march=all since kernel commit 80cec14a8 "[ARM] Add -march=all to assembly file build in arch/arm/boot/compressed" back in v2.6.28. This patch reverts Russell's nice solution and instead marks the head.S file to be built for armv7-a, which fortunately lets us build all instructions in that file without warnings even on the broken binutils. Without this patch, building anything results in: arch/arm/boot/compressed/head.S: Assembler messages: arch/arm/boot/compressed/head.S:565: Warning: (null) arch/arm/boot/compressed/head.S:676: Warning: (null) arch/arm/boot/compressed/head.S:698: Warning: (null) arch/arm/boot/compressed/head.S:722: Warning: (null) arch/arm/boot/compressed/head.S:726: Warning: (null) arch/arm/boot/compressed/head.S:957: Warning: (null) arch/arm/boot/compressed/head.S:996: Warning: (null) arch/arm/boot/compressed/head.S:997: Warning: (null) arch/arm/boot/compressed/head.S:1027: Warning: (null) arch/arm/boot/compressed/head.S:1035: Warning: (null) arch/arm/boot/compressed/head.S:1046: Warning: (null) arch/arm/boot/compressed/head.S:1060: Warning: (null) arch/arm/boot/compressed/head.S:1092: Warning: (null) arch/arm/boot/compressed/head.S:1094: Warning: (null) arch/arm/boot/compressed/head.S:1095: Warning: (null) arch/arm/boot/compressed/head.S:1102: Warning: (null) arch/arm/boot/compressed/head.S:1134: Warning: (null) Signed-off-by: Arnd Bergmann Cc: Matthew Gretton-Dann Signed-off-by: Russell King [bwh: Backported to 3.2: - Adjust context - Remove definition of asflags-y as it is now empty] Signed-off-by: Ben Hutchings commit 17db9f4f88581b83762735eba9c64f06a85ac069 Author: Arnd Bergmann Date: Fri May 31 22:49:22 2013 +0100 ARM: 7742/1: topology: export cpu_topology commit 92bdd3f5eba299b33c2f4407977d6fa2e2a6a0da upstream. The cpu_topology symbol is required by any driver using the topology interfaces, which leads to a couple of build errors: ERROR: "cpu_topology" [drivers/net/ethernet/sfc/sfc.ko] undefined! ERROR: "cpu_topology" [drivers/cpufreq/arm_big_little.ko] undefined! ERROR: "cpu_topology" [drivers/block/mtip32xx/mtip32xx.ko] undefined! The obvious solution is to export this symbol. Signed-off-by: Arnd Bergmann Acked-by: Will Deacon Cc: Nicolas Pitre Cc: Vincent Guittot Signed-off-by: Russell King Signed-off-by: Ben Hutchings commit 89dc57e2f08f9dca506ca7b023d62ab46b8b196c Author: Takashi Iwai Date: Wed Jun 5 08:35:26 2013 +0200 ALSA: usb-audio - Fix invalid volume resolution on Logitech HD webcam c270 commit 11e7064f35bb87da8f427d1aa4bbd8b7473a3993 upstream. USB audio driver spews an error message when probing Logitech HD webcam c270: ALSA mixer.c:1300 usb_audio: Warning! Unlikely big volume range (=6144), cval->res is probably wrong. ALSA mixer.c:1304 usb_audio: [5] FU [Mic Capture Volume] ch = 1, val = 1536/7680/1 Obviously the device needs a fixed volume resolution (cval->res = 384) like other Logitech devices. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=821735 Reported-and-tested-by: Cristian Rodríguez Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 9c0c3f80d5a7e370920841d471b797e123fe3c4c Author: Johan Hovold Date: Tue Jun 4 18:50:31 2013 +0200 USB: mos7720: fix hardware flow control commit a26f009a070e840fadacb91013b2391ba7ab6cc2 upstream. The register access to enable hardware flow control depends on the device port number and not the port minor number. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 698cb96b51f336c18f4ca48597565bd3097f5d48 Author: Johan Hovold Date: Tue Jun 4 18:50:29 2013 +0200 USB: keyspan: fix bogus array index commit a07088098a650267b2eda689538133a324b9523f upstream. The outcont_endpoints array was indexed using the port minor number (which can be greater than the array size) rather than the device port number. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 94dbc341c33589c6cb3c2e60414250c9e1535968 Author: Egbert Eich Date: Tue Jun 4 17:13:21 2013 +0200 drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC. commit 53d3b4d7778daf15900867336c85d3f8dd70600c upstream. In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used for DDC. Thus the code will always have to rely on a LVDS panel mode supplied by VBT. In most cases this succeeds, so this didn't get detected for quite a while. This regression seems to have been introduced in commit f899fc64cda8569d0529452aafc0da31c042df2e Author: Chris Wilson Date: Tue Jul 20 15:44:45 2010 -0700 drm/i915: use GMBUS to manage i2c links Signed-off-by: Egbert Eich Reviewed-by: Chris Wilson [danvet: Add note about which commit likely introduced this issue.] Signed-off-by: Daniel Vetter Signed-off-by: Ben Hutchings commit e1041b322c19e1b0ca1b7c993d517615655c6743 Author: Takashi Iwai Date: Tue Jun 4 16:02:54 2013 +0200 ALSA: usb-audio - Apply Logitech QuickCam Pro 9000 quirk only to audio iface commit 8eafc0a161123d90617c9ca2eddfe87b382b1b89 upstream. ... instead of applying to all interfaces. Reference: http://forums.gentoo.org/viewtopic-p-6886404.html Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 7d578af04ddac58f49ee90b56625a45090745de7 Author: Richard Weinberger Date: Fri May 24 12:01:51 2013 +0200 USB: serial: Add Option GTM681W to qcserial device table. commit 8a2f132a01c2dd4c3905fa560f92019761ed72b1 upstream. The Option GTM681W uses a qualcomm chip and can be served by the qcserial device driver. Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 01113ba9a590626c4aefc4743e49e280ec089496 Author: Robert Butora Date: Fri May 31 18:09:51 2013 +0300 USB: Serial: cypress_M8: Enable FRWD Dongle hidcom device commit 6529591e3eef65f0f528a81ac169f6e294b947a7 upstream. The patch adds a new HIDCOM device and does not affect other devices driven by the cypress_M8 module. Changes are: - add VendorID ProductID to device tables - skip unstable speed check because FRWD uses 115200bps - skip reset at probe which is an issue workaround for this particular device. Signed-off-by: Robert Butora Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 62f5e8156da4e5373a10c7c1d15a4327283f64f2 Author: Adis Hamzić Date: Sun Jun 2 16:47:54 2013 +0200 radeon: Fix system hang issue when using KMS with older cards commit e49f3959a96dc279860af7e86e6dbcfda50580a5 upstream. The current radeon driver initialization routines, when using KMS, are written so that the IRQ installation routine is called before initializing the WB buffer and the CP rings. With some ASICs, though, the IRQ routine tries to access the GFX_INDEX ring causing a call to RREG32 with the value of -1 in radeon_fence_read. This, in turn causes the system to completely hang with some cards, requiring a hard reset. A call stack that can cause such a hang looks like this (using rv515 ASIC for the example here): * rv515_init (rv515.c) * radeon_irq_kms_init (radeon_irq_kms.c) * drm_irq_install (drm_irq.c) * radeon_driver_irq_preinstall_kms (radeon_irq_kms.c) * rs600_irq_process (rs600.c) * radeon_fence_process - due to SW interrupt (radeon_fence.c) * radeon_fence_read (radeon_fence.c) * hang due to RREG32(-1) The patch moves the IRQ installation to the card startup routine, after the ring has been initialized, but before the IRQ has been set. This fixes the issue, but requires a check to see if the IRQ is already installed, as is the case in the system resume codepath. I have tested the patch on three machines using the rv515, the rv770 and the evergreen ASIC. They worked without issues. This seems to be a known issue and has been reported on several bug tracking sites by various distributions (see links below). Most of reports recommend booting the system with KMS disabled and then enabling KMS by reloading the radeon module. For some reason, this was indeed a usable workaround, however, UMS is now deprecated and disabled by default. Bug reports: https://bugzilla.redhat.com/show_bug.cgi?id=845745 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/561789 https://bbs.archlinux.org/viewtopic.php?id=156964 Signed-off-by: Adis Hamzić Signed-off-by: Alex Deucher [bwh: Backported to 3.2: - Adjust context - Drop changes for Southern Islands] Signed-off-by: Ben Hutchings commit a95372a5c25fcc392422ae00e54ec8a557624de7 Author: Ben Mesman Date: Tue Apr 16 20:00:28 2013 +0200 drm/i915: no lvds quirk for hp t5740 commit 45a211d75137b1ac869a8a758a6667f15827a115 upstream. Last year, a patch was made for the "HP t5740e Thin Client" (see http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html). This device reports an lvds panel, but does not really have one. The predecessor of this device is the "hp t5740", which also does not have an lvds panel. This patch will add the same quirk for this device. Signed-off-by: Ben Mesman Signed-off-by: Daniel Vetter Signed-off-by: Ben Hutchings commit 8766964c1daea3b743f8e3c12c331b528ade278c Author: Huacai Chen Date: Tue May 21 06:23:43 2013 +0000 drm: fix a use-after-free when GPU acceleration disabled commit b7ea85a4fed37835eec78a7be3039c8dc22b8178 upstream. When GPU acceleration is disabled, drm_vblank_cleanup() will free the vblank-related data, such as vblank_refcount, vblank_inmodeset, etc. But we found that drm_vblank_post_modeset() may be called after the cleanup, which use vblank_refcount and vblank_inmodeset. And this will cause a kernel panic. Fix this by return immediately if dev->num_crtcs is zero. This is the same thing that drm_vblank_pre_modeset() does. Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup(): [ 62.628906] [] drm_vblank_post_modeset+0x34/0xb4 [ 62.628906] [] atombios_crtc_dpms+0xb4/0x174 [ 62.628906] [] atombios_crtc_commit+0x18/0x38 [ 62.628906] [] drm_crtc_helper_set_mode+0x304/0x3cc [ 62.628906] [] drm_crtc_helper_set_config+0x6d8/0x988 [ 62.628906] [] drm_fb_helper_set_par+0x94/0x104 [ 62.628906] [] fbcon_init+0x424/0x57c [ 62.628906] [] visual_init+0xb8/0x118 [ 62.628906] [] take_over_console+0x238/0x384 [ 62.628906] [] fbcon_takeover+0x7c/0xdc [ 62.628906] [] notifier_call_chain+0x44/0x94 [ 62.628906] [] __blocking_notifier_call_chain+0x48/0x68 [ 62.628906] [] register_framebuffer+0x228/0x260 [ 62.628906] [] drm_fb_helper_single_fb_probe+0x260/0x314 [ 62.628906] [] drm_fb_helper_initial_config+0x200/0x234 [ 62.628906] [] radeon_fbdev_init+0xd4/0xf4 [ 62.628906] [] radeon_modeset_init+0x9bc/0xa18 [ 62.628906] [] radeon_driver_load_kms+0xdc/0x12c [ 62.628906] [] drm_get_pci_dev+0x148/0x238 [ 62.628906] [] local_pci_probe+0x5c/0xd0 [ 62.628906] [] work_for_cpu_fn+0x1c/0x30 [ 62.628906] [] process_one_work+0x274/0x3bc [ 62.628906] [] process_scheduled_works+0x24/0x44 [ 62.628906] [] worker_thread+0x31c/0x3f4 [ 62.628906] [] kthread+0x88/0x90 [ 62.628906] [] kernel_thread_helper+0x10/0x18 Signed-off-by: Huacai Chen Signed-off-by: Binbin Zhou Reviewed-by: Michel Dänzer Acked-by: Paul Menzel Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings commit 8de5f8abdee26b1dc13e98c401a68637df2ad0dc Author: Ash Willis Date: Wed May 29 01:27:59 2013 +0000 ACPI / video: ignore BIOS initial backlight value for HP Pavilion g6 commit 780a6ec640a3fed671fc2c40e4dd30c03eca3ac3 upstream. This patch addresses kernel bug 56661. BIOS reports an incorrect backlight value, causing the driver to switch off the backlight completely during startup. This patch ignores the incorrect value from BIOS. References: https://bugzilla.kernel.org/show_bug.cgi?id=56661 Signed-off-by: Ash Willis Signed-off-by: Rafael J. Wysocki Signed-off-by: Ben Hutchings commit 10254e3d0182b24685f1043183194c7a6d26a2e9 Author: Alex Hung Date: Tue May 28 02:05:09 2013 +0000 ACPI / video: ignore BIOS initial backlight value for HP m4 commit fedbe9bc6fd3e14b1ffbb3dac407777ac4a3650c upstream. On HP m4 lapops, BIOS reports minimum backlight on boot and causes backlight to dim completely. This ignores the initial backlight values and set to max brightness. References: https://bugs.launchpad.net/bugs/1184501 Signed-off-by: Alex Hung Signed-off-by: Rafael J. Wysocki Signed-off-by: Ben Hutchings commit 36466ac6c36c955ec1e4eaf8f4ed6a192f430f9a Author: Alex Hung Date: Mon May 6 08:23:43 2013 +0000 ACPI video: ignore BIOS initial backlight value for HP 1000 commit 4ef366c583d6180b1c951147869ee5a3038834f2 upstream. On HP 1000 lapops, BIOS reports minimum backlight on boot and causes backlight to dim completely. This ignores the initial backlight values and set to max brightness. References:: https://bugs.launchpad.net/bugs/1167760 Signed-off-by: Alex Hung Signed-off-by: Rafael J. Wysocki Signed-off-by: Ben Hutchings commit c58c2d2597e052789db8fb0864355b3e504d286b Author: Gustavo Maciel Dias Vieira Date: Mon Mar 4 15:23:37 2013 +0000 ACPI video: ignore BIOS backlight value for HP dm4 commit 771d09b3c4c45d4d534a83a68e6331b97fd82e15 upstream. On a HP Pavilion dm4 laptop the BIOS sets minimum backlight on boot, completely dimming the screen. Ignore this initial value for this machine. Signed-off-by: Gustavo Maciel Dias Vieira Signed-off-by: Rafael J. Wysocki Signed-off-by: Ben Hutchings commit 85b69eb4a04bb04920f7a133f90c6c58ecdf0ec2 Author: Johan Hovold Date: Mon May 27 14:44:43 2013 +0200 USB: mos7720: fix message timeouts commit 849513a7809175420d353625b6f651d961e99d49 upstream. The control and bulk-message timeouts are specified in milliseconds and should not depend on HZ. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit ab85bbe6df2d4f3c983d9cc9429273a0f83e271d Author: Johan Hovold Date: Mon May 27 14:44:42 2013 +0200 USB: iuu_phoenix: fix bulk-message timeout commit 6c13ff68a7ce01da7a51b44241a7aad8eaaedde7 upstream. The bulk-message timeout is specified in milliseconds and should not depend on HZ. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 56eb0cfb33b99dc253bc3743c418fb2814aa7981 Author: Johan Hovold Date: Mon May 27 14:44:41 2013 +0200 USB: ark3116: fix control-message timeout commit 634371911730a462626071065b64cd6e1fe213e0 upstream. The control-message timeout is specified in milliseconds and should not depend on HZ. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 14c40df542c6c80538b1e707aabe9d42792f89ac Author: Johan Hovold Date: Mon May 27 14:44:39 2013 +0200 USB: mos7720: fix DMA to stack commit 72ea18a558ed7a63a50bb121ba60d73b5b38ae30 upstream. The read_mos_reg function is called with stack-allocated buffers, which must not be used for control messages. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit afc11b7e5278ac5ec3728f3eef43517e987eb51a Author: Johan Hovold Date: Mon May 27 14:44:38 2013 +0200 USB: visor: fix initialisation of Treo/Kyocera devices commit 420021a395ce38b7ab2cceb52dee4038be7d8fa3 upstream. Fix regression introduced by commit 214916f2e ("USB: visor: reimplement using generic framework") which broke initialisation of Treo/Kyocera devices that re-mapped bulk-in endpoints. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: only copy bulk_in_size as the other new fields don't exist here] Signed-off-by: Ben Hutchings commit 796b5b05e3d6b8925ef0e8bc5f63ee8fd38e5e7a Author: Johan Hovold Date: Mon May 27 14:44:37 2013 +0200 USB: serial: fix Treo/Kyocera interrrupt-in urb context commit 5f8e2c07d75967ee49a5da1d21ddf5f50d48cda0 upstream. The first and second interrupt-in urbs are swapped for some Treo/Kyocera devices, but the urb context was never updated with the new port. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit f35b59d2c166210f442a791be1061b181e924ccf Author: Alan Stern Date: Tue May 28 14:03:10 2013 -0400 USB: revert periodic scheduling bugfix commit fdc03438f53a00294ed9939eb3a1f6db6f3d8963 upstream. This patch reverts commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d (USB: EHCI: fix bug in scheduling periodic split transfers). The commit was valid -- it fixed a real bug -- but the periodic scheduler in ehci-hcd is in such bad shape (especially the part that handles split transactions) that fixing one bug is very likely to cause another to surface. That's what happened in this case; the result was choppy and noisy playback on certain 24-bit audio devices. The only real fix will be to rewrite this entire section of code. My next project... This fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110. Thanks to Tim Richardson for extra testing and feedback, and to Joseph Salisbury and Tyson Tan for tracking down the original source of the problem. Signed-off-by: Alan Stern CC: Joseph Salisbury CC: Tim Richardson Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 5b9ce8be3223c6d68e7581b0de59f6a92ccdd02d Author: George Cherian Date: Mon May 27 14:35:49 2013 +0530 usb: dwc3: gadget: free trb pool only from epnum 2 commit 5bf8fae33d14cc5c3c53a926f9079f92c8b082b0 upstream. we never allocate a TRB pool for physical endpoints 0 and 1 so trying to free it (a invalid TRB pool pointer) will lead us in a warning while removing dwc3.ko module. In order to fix the situation, all we have to do is skip dwc3_free_trb_pool() for physical endpoints 0 and 1 just as we while deleting endpoints from the endpoints list. Signed-off-by: George Cherian Signed-off-by: Felipe Balbi [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 50e293cfbfee3a048ce0f6c04bca8899b20ca353 Author: Tony Camuso Date: Thu Feb 21 16:11:27 2013 -0500 xhci - correct comp_mode_recovery_timer on return from hibernate commit 77df9e0b799b03e1d5d9c68062709af5f637e834 upstream. Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware) was a workaround for systems using the SN65LVPE502CP, controller, but it introduced a bug in resume from hibernate. The fix created a timer, comp_mode_recovery_timer, which is deleted from a timer list when xhci_suspend() is called. However, the hibernate image, including the timer list containing the comp_mode_recovery_timer, had already been saved before the timer was deleted. Upon resume from hibernate, the list containing the comp_mode_recovery_timer is restored from the image saved to disk, and xhci_resume(), assuming that the timer had been deleted by xhci_suspend(), makes a call to compliance_mode_recoery_timer_init(), which creates a new instance of the comp_mode_recovery_timer and attempts to place it into the same list in which it is already active, thus corrupting the list during the list_add() call. At this point, a call trace is emitted indicating the list corruption. Soon afterward, the system locks up, the watchdog times out, and the ensuing NMI crashes the system. The problem did not occur when resuming from suspend. In suspend, the image in RAM remains exactly as it was when xhci_suspend() deleted the comp_mode_recovery_timer, so there is no problem when xhci_resume() creates a new instance of this timer and places it in the still empty list. This patch avoids the problem by deleting the timer in xhci_resume() when resuming from hibernate. Now xhci_resume() can safely make the call to create a new instance of this timer, whether returning from suspend or hibernate. Thanks to Alan Stern for his help with understanding the problem. [Sarah reworked this patch to cover the case where the xHCI restore register operation fails, and (temp & STS_SRE) is true (and we re-init the host, including re-init for the compliance mode), but hibernate is false. The original patch would have caused list corruption in this case.] This patch should be backported to kernels as old as 3.2, that contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware" Signed-off-by: Tony Camuso Tested-by: Tony Camuso Acked-by: Don Zickus Signed-off-by: Sarah Sharp Signed-off-by: Ben Hutchings commit ecc05abda92e00b32c88707b38c85182cf4b2725 Author: Vladimir Murzin Date: Tue Apr 9 22:33:31 2013 +0400 xhci: fix list access before init commit 88696ae432ce7321540ac53d9caab3de9118b094 upstream. If for whatever reason we fall into fail path in xhci_mem_init() before bw table gets initialized we may access the uninitialized lists in xhci_mem_cleanup(). Check for bw table before traversing lists in cleanup routine. This patch should be backported to kernels as old as 3.2, that contain the commit 839c817ce67178ca3c7c7ad534c571bba1e69ebe "xhci: Store information about roothubs and TTs." Reported-by: Sergey Dyasly Tested-by: Sergey Dyasly Signed-off-by: Vladimir Murzin Signed-off-by: Sarah Sharp Signed-off-by: Ben Hutchings commit a1580a95fd066e3cbe9057ad2b87bfd5ace521bf Author: Sergio Aguirre Date: Thu Apr 4 10:32:13 2013 -0700 xhci-mem: init list heads at the beginning of init commit 331de00a64e5027365145bdf51da27b9ce15dfd5 upstream. It is possible that we fail on xhci_mem_init, just before doing the INIT_LIST_HEAD, and calling xhci_mem_cleanup. Problem is that, the list_for_each_entry_safe macro, assumes list heads are initialized (not NULL), and dereferences their 'next' pointer, causing a kernel panic if this is not yet initialized. Let's protect from that by moving inits to the beginning. This patch should be backported to kernels as old as 3.2, that contain the commit 9574323c39d1f8359a04843075d89c9f32d8b7e6 "xHCI: test USB2 software LPM". Signed-off-by: Sergio Aguirre Acked-by: David Cohen Signed-off-by: Sarah Sharp [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit b698c01da50a55f495687146d4e72bc0d5746c04 Author: Patrik Jakobsson Date: Thu Apr 25 22:23:36 2013 +0200 drm/gma500: Increase max resolution for mode setting commit cbbd379aa43890f36da934f5af619d2fb8ec3d87 upstream. By having a higher max resolution we can now set up a virtual framebuffer that spans several monitors. 4096 should be ok since we're gen 3 or higher and should be enough for most dual head setups. Signed-off-by: Patrik Jakobsson [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings commit 1c779312a17a2126bb01001d8aa119a0346a567a Author: Ying Xue Date: Mon Aug 6 17:46:37 2012 +0800 USB: ftdi_sio: Quiet sparse noise about using plain integer was NULL pointer commit a816e3113b63753c330ca4751ea1d208e93e3015 upstream. Pointers should not be compared to plain integers. Quiets the sparse warning: warning: Using plain integer as NULL pointer Signed-off-by: Ying Xue Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 2046bf5429e670095315355d263f35ad85a1a209 Author: Andrew Worsley Date: Tue Nov 22 20:00:19 2011 +1100 USB: serial: ftdi_sio: Handle the old_termios == 0 case e.g. uart_resume_port() commit c515598e0f5769916c31c00392cc2bfe6af74e55 upstream. Handle null old_termios in ftdi_set_termios() calls from uart_resume_port(). Signed-off-by: Andrew Worsley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 57321c3df5c8c3f1a485db064282eefb06504ead Author: Steven Rostedt (Red Hat) Date: Fri Apr 12 16:40:13 2013 -0400 ftrace: Move ftrace_filter_lseek out of CONFIG_DYNAMIC_FTRACE section commit 7f49ef69db6bbf756c0abca7e9b65b32e999eec8 upstream. As ftrace_filter_lseek is now used with ftrace_pid_fops, it needs to be moved out of the #ifdef CONFIG_DYNAMIC_FTRACE section as the ftrace_pid_fops is defined when DYNAMIC_FTRACE is not. Cc: Namhyung Kim Signed-off-by: Steven Rostedt [bwh: Backported to 3.2: - ftrace_filter_lseek() is static and not declared in ftrace.h - 'whence' parameter was called 'origin'] Signed-off-by: Ben Hutchings commit d1e52f9d3ae27fcc72a4da98f1ccbe56e30d8358 Author: Manoj Iyer Date: Mon Aug 6 18:15:37 2012 -0500 thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR commit a4f46bb9fa84642e356898ee44b670989622f8bb upstream. In the latest V-series bios DMI_PRODUCT_VERSION does not contain the string Lenovo or Thinkpad, but is set to the model number, this causes the thinkpad_acpi module to fail to load. Recognize laptop as Lenovo using DMI_BIOS_VENDOR instead, which is set to Lenovo. Test on V490u ============= == After the patch == [ 1350.295757] thinkpad_acpi: ThinkPad ACPI Extras v0.24 [ 1350.295760] thinkpad_acpi: http://ibm-acpi.sf.net/ [ 1350.295761] thinkpad_acpi: ThinkPad BIOS H7ET21WW (1.00 ), EC unknown [ 1350.295763] thinkpad_acpi: Lenovo LENOVO, model LV5DXXX [ 1350.296086] thinkpad_acpi: detected a 8-level brightness capable ThinkPad [ 1350.296694] thinkpad_acpi: radio switch found; radios are enabled [ 1350.296703] thinkpad_acpi: possible tablet mode switch found; ThinkPad in laptop mode [ 1350.306466] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [ 1350.307082] Registered led device: tpacpi::thinklight [ 1350.307215] Registered led device: tpacpi::power [ 1350.307255] Registered led device: tpacpi::standby [ 1350.307294] Registered led device: tpacpi::thinkvantage [ 1350.308160] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one [ 1350.308333] thinkpad_acpi: Console audio control enabled, mode: monitor (read only) [ 1350.312287] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input14 == Before the patch == sudo modprobe thinkpad_acpi FATAL: Error inserting thinkpad_acpi (/lib/modules/3.2.0-27-generic/kernel/drivers/platform/x86/thinkpad_acpi.ko): No such device Test on B485 ============= This patch was also test in a B485 where the thinkpad_acpi module does not have any issues loading. But, I tested it to make sure this patch does not break on already functioning models of Lenovo products. [13486.746359] thinkpad_acpi: ThinkPad ACPI Extras v0.24 [13486.746364] thinkpad_acpi: http://ibm-acpi.sf.net/ [13486.746368] thinkpad_acpi: ThinkPad BIOS HJET15WW(1.01), EC unknown [13486.746373] thinkpad_acpi: Lenovo Lenovo LB485, model 814TR01 [13486.747300] thinkpad_acpi: detected a 8-level brightness capable ThinkPad [13486.752435] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [13486.752883] Registered led device: tpacpi::thinklight [13486.752915] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one [13486.753216] thinkpad_acpi: Console audio control enabled, mode: monitor (read only) [13486.757147] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input15 Signed-off-by: Manoj Iyer Signed-off-by: Matthew Garrett Signed-off-by: Ben Hutchings commit 547bb54d9d41a867765cb414754472a437ad279f Author: Theodore Ts'o Date: Thu Dec 27 01:42:48 2012 -0500 ext4: lock i_mutex when truncating orphan inodes commit 721e3eba21e43532e438652dd8f1fcdfce3187e7 upstream. Commit c278531d39 added a warning when ext4_flush_unwritten_io() is called without i_mutex being taken. It had previously not been taken during orphan cleanup since races weren't possible at that point in the mount process, but as a result of this c278531d39, we will now see a kernel WARN_ON in this case. Take the i_mutex in ext4_orphan_cleanup() to suppress this warning. Reported-by: Alexander Beregalov Signed-off-by: "Theodore Ts'o" Reviewed-by: Zheng Liu Signed-off-by: Ben Hutchings commit e12eeedd93b12913386430ead7dc6b2b948ce31f Author: Larry Finger Date: Wed Sep 26 12:32:02 2012 -0500 b43legacy: Fix crash on unload when firmware not available commit 2d838bb608e2d1f6cb4280e76748cb812dc822e7 upstream. When b43legacy is loaded without the firmware being available, a following unload generates a kernel NULL pointer dereference BUG as follows: [ 214.330789] BUG: unable to handle kernel NULL pointer dereference at 0000004c [ 214.330997] IP: [] drain_workqueue+0x15/0x170 [ 214.331179] *pde = 00000000 [ 214.331311] Oops: 0000 [#1] SMP [ 214.331471] Modules linked in: b43legacy(-) ssb pcmcia mac80211 cfg80211 af_packet mperf arc4 ppdev sr_mod cdrom sg shpchp yenta_socket pcmcia_rsrc pci_hotplug pcmcia_core battery parport_pc parport floppy container ac button edd autofs4 ohci_hcd ehci_hcd usbcore usb_common thermal processor scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_dh fan thermal_sys hwmon ata_generic pata_ali libata [last unloaded: cfg80211] [ 214.333421] Pid: 3639, comm: modprobe Not tainted 3.6.0-rc6-wl+ #163 Source Technology VIC 9921/ALI Based Notebook [ 214.333580] EIP: 0060:[] EFLAGS: 00010246 CPU: 0 [ 214.333687] EIP is at drain_workqueue+0x15/0x170 [ 214.333788] EAX: c162ac40 EBX: cdfb8360 ECX: 0000002a EDX: 00002a2a [ 214.333890] ESI: 00000000 EDI: 00000000 EBP: cd767e7c ESP: cd767e5c [ 214.333957] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 214.333957] CR0: 8005003b CR2: 0000004c CR3: 0c96a000 CR4: 00000090 [ 214.333957] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ 214.333957] DR6: ffff0ff0 DR7: 00000400 [ 214.333957] Process modprobe (pid: 3639, ti=cd766000 task=cf802e90 task.ti=cd766000) [ 214.333957] Stack: [ 214.333957] 00000292 cd767e74 c12c5e09 00000296 00000296 cdfb8360 cdfb9220 00000000 [ 214.333957] cd767e90 c104c4fd cdfb8360 cdfb9220 cd682800 cd767ea4 d0c10184 cd682800 [ 214.333957] cd767ea4 cba31064 cd767eb8 d0867908 cba31064 d087e09c cd96f034 cd767ec4 [ 214.333957] Call Trace: [ 214.333957] [] ? skb_dequeue+0x49/0x60 [ 214.333957] [] destroy_workqueue+0xd/0x150 [ 214.333957] [] ieee80211_unregister_hw+0xc4/0x100 [mac80211] [ 214.333957] [] b43legacy_remove+0x78/0x80 [b43legacy] [ 214.333957] [] ssb_device_remove+0x1d/0x30 [ssb] [ 214.333957] [] __device_release_driver+0x5a/0xb0 [ 214.333957] [] driver_detach+0x87/0x90 [ 214.333957] [] bus_remove_driver+0x6c/0xe0 [ 214.333957] [] driver_unregister+0x40/0x70 [ 214.333957] [] ssb_driver_unregister+0xb/0x10 [ssb] [ 214.333957] [] b43legacy_exit+0xd/0xf [b43legacy] [ 214.333957] [] sys_delete_module+0x14e/0x2b0 [ 214.333957] [] ? vfs_write+0xf7/0x150 [ 214.333957] [] ? tty_write_lock+0x50/0x50 [ 214.333957] [] ? sys_write+0x38/0x70 [ 214.333957] [] syscall_call+0x7/0xb [ 214.333957] Code: bc 27 00 00 00 00 a1 74 61 56 c1 55 89 e5 e8 a3 fc ff ff 5d c3 90 55 89 e5 57 56 89 c6 53 b8 40 ac 62 c1 83 ec 14 e8 bb b7 34 00 <8b> 46 4c 8d 50 01 85 c0 89 56 4c 75 03 83 0e 40 80 05 40 ac 62 [ 214.333957] EIP: [] drain_workqueue+0x15/0x170 SS:ESP 0068:cd767e5c [ 214.333957] CR2: 000000000000004c [ 214.341110] ---[ end trace c7e90ec026d875a6 ]---Index: wireless-testing/drivers/net/wireless/b43legacy/main.c The problem is fixed by making certain that the ucode pointer is not NULL before deregistering the driver in mac80211. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit a92f19e2c38ae57d363ef92cbbd3f9b3c30b87e5 Author: Keir Fraser Date: Thu Mar 28 10:03:36 2013 -0400 xen/events: Handle VIRQ_TIMER before any other hardirq in event loop. This avoids any other hardirq handler seeing a very stale jiffies value immediately after wakeup from a long idle period. The one observable symptom of this was a USB keyboard, with software keyboard repeat, which would always repeat a key immediately that it was pressed. This is due to the key press waking the guest, the key handler immediately runs, sees an old jiffies value, and then that jiffies value significantly updated, before the key is unpressed. Reviewed-by: David Vrabel Signed-off-by: Keir Fraser Signed-off-by: Konrad Rzeszutek Wilk (cherry picked from commit bee980d9e9642e96351fa3ca9077b853ecf62f57) Signed-off-by: Ben Hutchings commit b4b9150c21cd3babf406f40f7b29933c1c5f0f99 Author: Dave Kleikamp Date: Wed May 1 11:08:38 2013 -0500 jfs: fix a couple races commit 73aaa22d5ffb2630456bac2f9a4ed9b81d0d7271 upstream. This patch fixes races uncovered by xfstests testcase 068. One race is the result of jfs_sync() trying to write a sync point to the journal after it has been frozen (or possibly in the process). Since freezing sync's the journal, there is no need to write a sync point so we simply want to return. The second involves jfs_write_inode() being called on a deleted inode. It calls jfs_flush_journal which is held up by the jfs_commit thread doing the final iput on the same deleted inode, which itself is waiting for the I_SYNC flag to be cleared. jfs_write_inode need not do anything when i_nlink is zero, which is the easy fix. Reported-by: Michael L. Semon Signed-off-by: Dave Kleikamp Signed-off-by: Ben Hutchings commit 23005ee8bad9bc505bb15006c02cab01a8718550 Author: Wei Liu Date: Mon Apr 22 02:20:41 2013 +0000 xen-netfront: reduce gso_max_size to account for max TCP header commit 9ecd1a75d977e2e8c48139c7d3efed183f898d94 upstream. The maximum packet including header that can be handled by netfront / netback wire format is 65535. Reduce gso_max_size accordingly. Drop skb and print warning when skb->len > 65535. This can 1) save the effort to send malformed packet to netback, 2) help spotting misconfiguration of netfront in the future. Signed-off-by: Wei Liu Acked-by: Ian Campbell Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 3eddd6c470e225ba02d670a2c76d13cd05aabc0c Author: Joe Perches Date: Sun May 13 21:56:25 2012 +0000 net: Add net_ratelimited_function and net__ratelimited macros commit 3a3bfb61e64476ff1e4ac3122cb6dec9c79b795c upstream. __ratelimit() can be considered an inverted bool test because it returns true when not ratelimited. Several tests in the kernel tree use this __ratelimit() function incorrectly. No net_ratelimit uses are incorrect currently though. Most uses of net_ratelimit are to log something via printk or pr_. In order to minimize the uses of net_ratelimit, and to start standardizing the code style used for __ratelimit() and net_ratelimit(), add a net_ratelimited_function() macro and net__ratelimited() logging macros similar to pr__ratelimited that use the global net_ratelimit instead of a static per call site "struct ratelimit_state". Signed-off-by: Joe Perches Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit a1db4d774b1deab5a4f1a4a950c3523298ab4cd6 Author: Wei Liu Date: Thu May 2 00:43:59 2013 +0000 xen-netback: better names for thresholds commit 376414945d15aa636e65f7e773c1e398b7a21cb9 upstream. This patch only changes some names to avoid confusion. In this patch we have: MAX_SKB_SLOTS_DEFAULT -> FATAL_SKB_SLOTS_DEFAULT max_skb_slots -> fatal_skb_slots #define XEN_NETBK_LEGACY_SLOTS_MAX XEN_NETIF_NR_SLOTS_MIN The fatal_skb_slots is the threshold to determine whether a packet is malicious. XEN_NETBK_LEGACY_SLOTS_MAX is the maximum slots a valid packet can have at this point. It is defined to be XEN_NETIF_NR_SLOTS_MIN because that's guaranteed to be supported by all backends. Suggested-by: Ian Campbell Signed-off-by: Wei Liu Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 9b372fb74740a61a30e2f2e17212e8b3fcee520f Author: Wei Liu Date: Thu May 2 00:43:58 2013 +0000 xen-netback: avoid allocating variable size array on stack commit 59ccb4ebbc35e36a3c143f2d1355deb75c2e628f upstream. Tune xen_netbk_count_requests to not touch working array beyond limit, so that we can make working array size constant. Suggested-by: Jan Beulich Signed-off-by: Wei Liu Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 83a5c25c27aac582c035d1b71bec4fdc47d4451f Author: Wei Liu Date: Thu May 2 00:43:57 2013 +0000 xen-netback: remove redundent parameter in netbk_count_requests commit ac69c26e7accb04ae2cb9ab0872068983a42b3c8 upstream. Tracking down from the caller, first_idx is always equal to vif->tx.req_cons. Remove it to avoid confusion. Suggested-by: Jan Beulich Signed-off-by: Wei Liu Acked-by: Ian Campbell Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 276d632e34fcf94042dd4182e4398a8b6cbdc07f Author: Wei Liu Date: Mon Apr 22 02:20:43 2013 +0000 xen-netback: don't disconnect frontend when seeing oversize packet commit 03393fd5cc2b6cdeec32b704ecba64dbb0feae3c upstream. Some frontend drivers are sending packets > 64 KiB in length. This length overflows the length field in the first slot making the following slots have an invalid length. Turn this error back into a non-fatal error by dropping the packet. To avoid having the following slots having fatal errors, consume all slots in the packet. This does not reopen the security hole in XSA-39 as if the packet as an invalid number of slots it will still hit fatal error case. Signed-off-by: David Vrabel Signed-off-by: Wei Liu Acked-by: Ian Campbell Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit bccc108d67244797827c61870e12d84f66a212fe Author: Wei Liu Date: Mon Apr 22 02:20:42 2013 +0000 xen-netback: coalesce slots in TX path and fix regressions commit 2810e5b9a7731ca5fce22bfbe12c96e16ac44b6f upstream. This patch tries to coalesce tx requests when constructing grant copy structures. It enables netback to deal with situation when frontend's MAX_SKB_FRAGS is larger than backend's MAX_SKB_FRAGS. With the help of coalescing, this patch tries to address two regressions avoid reopening the security hole in XSA-39. Regression 1. The reduction of the number of supported ring entries (slots) per packet (from 18 to 17). This regression has been around for some time but remains unnoticed until XSA-39 security fix. This is fixed by coalescing slots. Regression 2. The XSA-39 security fix turning "too many frags" errors from just dropping the packet to a fatal error and disabling the VIF. This is fixed by coalescing slots (handling 18 slots when backend's MAX_SKB_FRAGS is 17) which rules out false positive (using 18 slots is legit) and dropping packets using 19 to `max_skb_slots` slots. To avoid reopening security hole in XSA-39, frontend sending packet using more than max_skb_slots is considered malicious. The behavior of netback for packet is thus: 1-18 slots: valid 19-max_skb_slots slots: drop and respond with an error max_skb_slots+ slots: fatal error max_skb_slots is configurable by admin, default value is 20. Also change variable name from "frags" to "slots" in netbk_count_requests. Please note that RX path still has dependency on MAX_SKB_FRAGS. This will be fixed with separate patch. Signed-off-by: Wei Liu Acked-by: Ian Campbell Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 4ea6949b9f6e783e3b053266d308582b8ae83c9e Author: stephen hemminger Date: Wed Apr 10 10:54:46 2013 +0000 xen-netback: fix sparse warning commit 9eaee8beeeb3bca0d9b14324fd9d467d48db784c upstream. Fix warning about 0 used as NULL. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit db55769e8e9405e101f49446fbbb378e1ba6151b Author: Wei Liu Date: Tue Dec 6 00:08:20 2011 +0000 netback: remove redundant assignment commit 16ecba2605a3bbd374cd993e532264e2d8de49e5 upstream. New value for netbk->mmap_pages[pending_idx] is assigned in xen_netbk_alloc_page(), no need for a second assignment which exposes internal to the outside world. Signed-off-by: Wei Liu Acked-by: Ian Campbell Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 83a4602ace11c7e394212d535b55ef734219eadb Author: Wei Liu Date: Mon Mar 25 01:08:20 2013 +0000 xen-netback: remove skb in xen_netbk_alloc_page commit 27f852282ab9a028f57da96d05c26f38c424a315 upstream. This variable is never used. Signed-off-by: Wei Liu Acked-by: Ian Campbell Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 2c8d23aefec3e8b6a8717a0ea469c332a03b1a8a Author: Xi Wang Date: Tue Feb 14 05:18:48 2012 -0500 ALSA: usb-audio: avoid integer overflow in create_fixed_stream_quirk() commit 8866f405efd4171f9d9c91901d2dd02f01bacb60 upstream. A malicious USB device could feed in a large nr_rates value. This would cause the subsequent call to kmemdup() to allocate a smaller buffer than expected, leading to out-of-bounds access. This patch validates the nr_rates value and reuses the limit introduced in commit 4fa0e81b ("ALSA: usb-audio: fix possible hang and overflow in parse_uac2_sample_rate_range()"). Signed-off-by: Xi Wang Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit c25a53781f61c78bf2a2fa308bbd35b42ba346f6 Author: Xi Wang Date: Sun Jan 8 09:02:52 2012 -0500 ALSA: usb-audio: fix possible hang and overflow in parse_uac2_sample_rate_range() commit 4fa0e81b83503900be277e6273a79651b375e288 upstream. A malicious USB device may feed in carefully crafted min/max/res values, so that the inner loop in parse_uac2_sample_rate_range() could run for a long time or even never terminate, e.g., given max = INT_MAX. Also nr_rates could be a large integer, which causes an integer overflow in the subsequent call to kmalloc() in parse_audio_format_rates_v2(). Thus, kmalloc() would allocate a smaller buffer than expected, leading to a memory corruption. To exploit the two vulnerabilities, an attacker needs physical access to the machine to plug in a malicious USB device. This patch makes two changes. 1) The type of "rate" is changed to unsigned int, so that the loop could stop once "rate" is larger than INT_MAX. 2) Limit nr_rates to 1024. Suggested-by: Takashi Iwai Signed-off-by: Xi Wang Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit c818d4b8f41d2c568bb240a2d18773adf4f55270 Author: Nithin Sujir Date: Mon Jun 3 09:19:34 2013 +0000 tg3: Add read dma workaround for 5720 commit 9bc297ea0622bb2a6b3abfa2fa84f0a3b86ef8c8 upstream. Commit 091f0ea30074bc43f9250961b3247af713024bc6 "tg3: Add New 5719 Read DMA workaround" added a workaround for TX DMA stall on the 5719. This workaround needs to be applied to the 5720 as well. Reported-by: Roland Dreier Tested-by: Roland Dreier Signed-off-by: Nithin Nayak Sujir Signed-off-by: Michael Chan Signed-off-by: David S. Miller [bwh: Backported to 3.2: use GET_ASIC_REV() instead of tg3_asic_rev()] Signed-off-by: Ben Hutchings commit 638030fe4b54431ac8deadecfd54b435336c0c69 Author: Michael Chan Date: Sun Jul 29 19:15:43 2012 +0000 tg3: Add New 5719 Read DMA workaround commit 091f0ea30074bc43f9250961b3247af713024bc6 upstream. After Power-on-reset, the 5719's TX DMA length registers may contain uninitialized values and cause TX DMA to stall. Check for invalid values and set a register bit to flush the TX channels. The bit needs to be turned off after the DMA channels have been flushed. Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit ba73be1c56e3a459f5cd4580177e865b362d76a7 Author: Kees Cook Date: Thu May 23 10:32:17 2013 -0700 iscsi-target: fix heap buffer overflow on error commit cea4dcfdad926a27a18e188720efe0f2c9403456 upstream. If a key was larger than 64 bytes, as checked by iscsi_check_key(), the error response packet, generated by iscsi_add_notunderstood_response(), would still attempt to copy the entire key into the packet, overflowing the structure on the heap. Remote preauthentication kernel memory corruption was possible if a target was configured and listening on the network. CVE-2013-2850 Signed-off-by: Kees Cook Signed-off-by: Nicholas Bellinger Signed-off-by: Ben Hutchings commit 81428790d5392ba103ff27a8e0ac0bc0a4959713 Author: Dave Chinner Date: Mon May 27 16:38:25 2013 +1000 xfs: kill suid/sgid through the truncate path. commit 2962f5a5dcc56f69cbf62121a7be67cc15d6940b upstream. XFS has failed to kill suid/sgid bits correctly when truncating files of non-zero size since commit c4ed4243 ("xfs: split xfs_setattr") introduced in the 3.1 kernel. Fix it. Fix it. Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Signed-off-by: Ben Myers (cherry picked from commit 56c19e89b38618390addfc743d822f99519055c6) Signed-off-by: Ben Hutchings commit e597b7c39df9cf5a66e740bc6a5cf10fa083dee8 Author: Alex Deucher Date: Wed May 22 11:22:51 2013 -0400 drm/radeon: fix card_posted check for newer asics commit 09fb8bd1a63b0f9f15e655c4fe8d047e5d2bf67a upstream. Newer asics have variable numbers of crtcs. Use that rather than the asic family to determine which crtcs to check. This avoids checking non-existent crtcs or missing crtcs on certain asics. Reviewed-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Ben Hutchings commit d9403f4bd2de6bd5acc2a1e8b55591167ab94d33 Author: Emmanuel Grumbach Date: Wed May 22 10:48:10 2013 +0300 iwlwifi: dvm: fix zero LQ CMD sending avoidance commit a87783699b23395c46bbeeb5d28f6db24897bf26 upstream. In 63b77bf489881747c5118476918cc8c29378ee63 iwlwifi: dvm: don't send zeroed LQ cmd I tried to avoid to send zeroed LQ cmd, but I made a (very) stupid mistake in the memcmp. Since this patch has been ported to stable, the fix should go to stable too. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=58341 Reported-by: Hinnerk van Bruinehsen Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings commit c0f02bada67863c524e69190d4dbee5d9b7307af Author: Johannes Berg Date: Fri May 24 01:06:09 2013 +0200 mac80211: close AP_VLAN interfaces before unregistering all commit c8aa22db0112f640ac6631347f850879c621840b upstream. Since Eric's commit efe117ab8 ("Speedup ieee80211_remove_interfaces") there's a bug in mac80211 when it unregisters with AP_VLAN interfaces up. If the AP_VLAN interface was registered after the AP it belongs to (which is the typical case) and then we get into this code path, unregister_netdevice_many() will crash because it isn't prepared to deal with interfaces being closed in the middle of it. Exactly this happens though, because we iterate the list, find the AP master this AP_VLAN belongs to and dev_close() the dependent VLANs. After this, unregister_netdevice_many() won't pick up the fact that the AP_VLAN is already down and will do it again, causing a crash. Cc: Eric Dumazet Signed-off-by: Johannes Berg Signed-off-by: Ben Hutchings commit 4a762b7f53a5e6bd6f6568b904ffcf2fd1811ef5 Author: Jeff Layton Date: Fri May 24 07:40:04 2013 -0400 cifs: fix potential buffer overrun when composing a new options string commit 166faf21bd14bc5c5295a44874bf7f3930c30b20 upstream. Consider the case where we have a very short ip= string in the original mount options, and when we chase a referral we end up with a very long IPv6 address. Be sure to allow for that possibility when estimating the size of the string to allocate. Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Ben Hutchings commit 71eac9d144bec44c29340b0d9905bcba3f4128e6 Author: Johannes Berg Date: Thu May 23 18:10:21 2013 +0200 cfg80211: check wdev->netdev in connection work commit c815797663b72e3ac1736f1886538152bc48e4af upstream. If a P2P-Device is present and another virtual interface triggers the connection work, the system crash because it tries to check if the P2P-Device's netdev (which doesn't exist) is up. Skip any wdevs that have no netdev to fix this. Reported-by: YanBo Signed-off-by: Johannes Berg [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 7e41cd93c89b061cfd4421153b74013b6e9de250 Author: Vincent Pelletier Date: Sat May 18 18:44:04 2013 +0200 libata: make ata_exec_internal_sg honor DMADIR commit e771451c0a831d96a7c14b0ca8a8ec671d98567b upstream. libata honors DMADIR for regular commands, but not for internal commands used (among other) during device initialisation. This makes SATA-host-to-PATA-device bridges based on Silicon Image SiL3611 (such as "Abit Serillel 2") end up disabled when used with an ATAPI device after a few tries. Log output of the bridge being hot-plugged with an ATAPI drive: [ 9631.212901] ata1: exception Emask 0x10 SAct 0x0 SErr 0x40c0000 action 0xe frozen [ 9631.212913] ata1: irq_stat 0x00000040, connection status changed [ 9631.212923] ata1: SError: { CommWake 10B8B DevExch } [ 9631.212939] ata1: hard resetting link [ 9632.104962] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 9632.106393] ata1.00: ATAPI: PIONEER DVD-RW DVR-115, 1.06, max UDMA/33 [ 9632.106407] ata1.00: applying bridge limits [ 9632.108151] ata1.00: configured for UDMA/33 [ 9637.105303] ata1.00: qc timeout (cmd 0xa0) [ 9637.105324] ata1.00: failed to clear UNIT ATTENTION (err_mask=0x5) [ 9637.105335] ata1: hard resetting link [ 9638.044599] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 9638.047878] ata1.00: configured for UDMA/33 [ 9643.044933] ata1.00: qc timeout (cmd 0xa0) [ 9643.044953] ata1.00: failed to clear UNIT ATTENTION (err_mask=0x5) [ 9643.044963] ata1: limiting SATA link speed to 1.5 Gbps [ 9643.044971] ata1.00: limiting speed to UDMA/33:PIO3 [ 9643.044979] ata1: hard resetting link [ 9643.984225] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 9643.987471] ata1.00: configured for UDMA/33 [ 9648.984591] ata1.00: qc timeout (cmd 0xa0) [ 9648.984612] ata1.00: failed to clear UNIT ATTENTION (err_mask=0x5) [ 9648.984619] ata1.00: disabled [ 9649.000593] ata1: hard resetting link [ 9649.939902] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 9649.955864] ata1: EH complete With this patch, the drive enumerates correctly when libata is loaded with atapi_dmadir=1: [ 9891.810863] ata1: exception Emask 0x10 SAct 0x0 SErr 0x40c0000 action 0xe frozen [ 9891.810874] ata1: irq_stat 0x00000040, connection status changed [ 9891.810884] ata1: SError: { CommWake 10B8B DevExch } [ 9891.810900] ata1: hard resetting link [ 9892.762105] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 9892.763544] ata1.00: ATAPI: PIONEER DVD-RW DVR-115, 1.06, max UDMA/33, DMADIR [ 9892.763558] ata1.00: applying bridge limits [ 9892.765393] ata1.00: configured for UDMA/33 [ 9892.786063] ata1: EH complete [ 9892.792062] scsi 0:0:0:0: CD-ROM PIONEER DVD-RW DVR-115 1.06 PQ: 0 ANSI: 5 [ 9892.798455] sr2: scsi3-mmc drive: 12x/12x writer dvd-ram cd/rw xa/form2 cdda tray [ 9892.798837] sr 0:0:0:0: Attached scsi CD-ROM sr2 [ 9892.799109] sr 0:0:0:0: Attached scsi generic sg6 type 5 Based on a patch by Csaba Halász on linux-ide: http://marc.info/?l=linux-ide&m=136121147832295&w=2 tj: minor formatting changes. Signed-off-by: Vincent Pelletier Signed-off-by: Tejun Heo Signed-off-by: Ben Hutchings commit 05fea0c7ca9069158db2f5b0349dc9760662f62a Author: Chew, Chiau Ee Date: Thu May 16 15:33:29 2013 +0800 ata_piix: add PCI IDs for Intel BayTail commit fca8c90d519dedd4f4b19901d005c243f7f0bf2e upstream. Adds IDE-mode SATA Device IDs for the Intel BayTrail platform. Signed-off-by: Chew, Chiau Ee Signed-off-by: Artem Bityutskiy Signed-off-by: Tejun Heo Signed-off-by: Ben Hutchings commit 94e0104bca7d6927e85119030b8e6e31fde88a7a Author: Ben Hutchings Date: Sun Jun 2 03:34:36 2013 +0100 rapidio/tsi721: Fix interrupt mask when handling MSI Commit 1619f441963e 'rapidio/tsi721: fix bug in MSI interrupt handling' (commit 1ccc819da6fd upstream) makes the MSI handler disable and re-enable interrupts. When re-enabling interrupts, we should set the same flags as were originally set, but this changed in Linux 3.5 so the flags are now inconsistent in 3.2. In fact, the extra flag isn't even defined in 3.2. Remove the extra flag from the MSI handler. Reported-by: Steve Conklin Signed-off-by: Ben Hutchings