commit dc51cd2570468bb7bcf1815a60929023316ca868 Author: Greg Kroah-Hartman Date: Sun Aug 4 16:51:49 2013 +0800 Linux 3.10.5 commit b185162885bc2346101a7b79c7737d2683b44782 Author: Yinghai Lu Date: Thu Jun 13 15:33:35 2013 -0700 x86: Fix /proc/mtrr with base/size more than 44bits commit d5c78673b1b28467354c2c30c3d4f003666ff385 upstream. On one sytem that mtrr range is more then 44bits, in dmesg we have [ 0.000000] MTRR default type: write-back [ 0.000000] MTRR fixed ranges enabled: [ 0.000000] 00000-9FFFF write-back [ 0.000000] A0000-BFFFF uncachable [ 0.000000] C0000-DFFFF write-through [ 0.000000] E0000-FFFFF write-protect [ 0.000000] MTRR variable ranges enabled: [ 0.000000] 0 [000080000000-0000FFFFFFFF] mask 3FFF80000000 uncachable [ 0.000000] 1 [380000000000-38FFFFFFFFFF] mask 3F0000000000 uncachable [ 0.000000] 2 [000099000000-000099FFFFFF] mask 3FFFFF000000 write-through [ 0.000000] 3 [00009A000000-00009AFFFFFF] mask 3FFFFF000000 write-through [ 0.000000] 4 [381FFA000000-381FFBFFFFFF] mask 3FFFFE000000 write-through [ 0.000000] 5 [381FFC000000-381FFC0FFFFF] mask 3FFFFFF00000 write-through [ 0.000000] 6 [0000AD000000-0000ADFFFFFF] mask 3FFFFF000000 write-through [ 0.000000] 7 [0000BD000000-0000BDFFFFFF] mask 3FFFFF000000 write-through [ 0.000000] 8 disabled [ 0.000000] 9 disabled but /proc/mtrr report wrong: reg00: base=0x080000000 ( 2048MB), size= 2048MB, count=1: uncachable reg01: base=0x80000000000 (8388608MB), size=1048576MB, count=1: uncachable reg02: base=0x099000000 ( 2448MB), size= 16MB, count=1: write-through reg03: base=0x09a000000 ( 2464MB), size= 16MB, count=1: write-through reg04: base=0x81ffa000000 (8519584MB), size= 32MB, count=1: write-through reg05: base=0x81ffc000000 (8519616MB), size= 1MB, count=1: write-through reg06: base=0x0ad000000 ( 2768MB), size= 16MB, count=1: write-through reg07: base=0x0bd000000 ( 3024MB), size= 16MB, count=1: write-through reg08: base=0x09b000000 ( 2480MB), size= 16MB, count=1: write-combining so bit 44 and bit 45 get cut off. We have problems in arch/x86/kernel/cpu/mtrr/generic.c::generic_get_mtrr(). 1. for base, we miss cast base_lo to 64bit before shifting. Fix that by adding u64 casting. 2. for size, it only can handle 44 bits aka 32bits + page_shift Fix that with 64bit mask instead of 32bit mask_lo, then range could be more than 44bits. At the same time, we need to update size_or_mask for old cpus that does support cpuid 0x80000008 to get phys_addr. Need to set high 32bits to all 1s, otherwise will not get correct size for them. Also fix mtrr_add_page: it should check base and (base + size - 1) instead of base and size, as base and size could be small but base + size could bigger enough to be out of boundary. We can use boot_cpu_data.x86_phys_bits directly to avoid size_or_mask. So When are we going to have size more than 44bits? that is 16TiB. after patch we have right ouput: reg00: base=0x080000000 ( 2048MB), size= 2048MB, count=1: uncachable reg01: base=0x380000000000 (58720256MB), size=1048576MB, count=1: uncachable reg02: base=0x099000000 ( 2448MB), size= 16MB, count=1: write-through reg03: base=0x09a000000 ( 2464MB), size= 16MB, count=1: write-through reg04: base=0x381ffa000000 (58851232MB), size= 32MB, count=1: write-through reg05: base=0x381ffc000000 (58851264MB), size= 1MB, count=1: write-through reg06: base=0x0ad000000 ( 2768MB), size= 16MB, count=1: write-through reg07: base=0x0bd000000 ( 3024MB), size= 16MB, count=1: write-through reg08: base=0x09b000000 ( 2480MB), size= 16MB, count=1: write-combining -v2: simply checking in mtrr_add_page according to hpa. [ hpa: This probably wants to go into -stable only after having sat in mainline for a bit. It is not a regression. ] Signed-off-by: Yinghai Lu Link: http://lkml.kernel.org/r/1371162815-29931-1-git-send-email-yinghai@kernel.org Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 0915f45b1275f392665df955e2e93ec459dac538 Author: Xiong Zhang Date: Fri Jul 5 18:53:29 2013 +0800 drm/i915: Correct obj->mm_list link to dev_priv->dev_priv->mm.inactive_list commit 067556084a0e412013af6b0250a3143ae5afde6d upstream. obj->mm_list link to dev_priv->mm.inactive_list/active_list obj->global_list link to dev_priv->mm.unbound_list/bound_list This regression has been introduced in commit 93927ca52a55c23e0a6a305e7e9082e8411ac9fa Author: Daniel Vetter Date: Thu Jan 10 18:03:00 2013 +0100 drm/i915: Revert shrinker changes from "Track unbound pages" Cc: stable@vger.kernel.org Signed-off-by: Xiong Zhang [danvet: Add regression notice.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zhouping Liu commit 2652eb4444fc2965a428a07123b877be1637711a Author: Michael Witten Date: Wed Apr 17 02:23:16 2013 +0000 perf tools: Revert regression in configuration of Python support commit a363a9da65d253fa7354ce5fd630f4f94df934cc upstream. Among other things, the following: commit 31160d7feab786c991780d7f0ce2755a469e0e5e Date: Tue Jan 8 16:22:36 2013 -0500 perf tools: Fix GNU make v3.80 compatibility issue attempts to aid the user by tapping into an existing error message, as described in the commit message: ... Also fix an issue where _get_attempt was called with only one argument. This prevented the error message from printing the name of the variable that can be used to fix the problem. or more precisely: -$(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2))) +$(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2),$(1))) However, The "missing" argument was in fact missing on purpose; it's absence is a signal that the error message should be skipped, because the failure would be due to the default value, not any user-supplied value. This can be seen in how `_ge_attempt' uses `gea_err' (in the config/utilities.mak file): _ge_attempt = $(if $(get-executable),$(get-executable),$(_gea_warn)$(call _gea_err,$(2))) _gea_warn = $(warning The path '$(1)' is not executable.) _gea_err = $(if $(1),$(error Please set '$(1)' appropriately)) That is, because the argument is no longer missing, the value `$(1)' (associated with `_gea_err') always evaluates to true, thus always triggering the error condition that is meant to be reserved for only the case when a user explicitly supplies an invalid value. Concretely, the result is a regression in the Makefile's configuration of python support; rather than gracefully disable support when the relevant executables cannot be found according to default values, the build process halts in error as though the user explicitly supplied the values. This new commit simply reverts the offending one-line change. Reported-by: Pekka Enberg Link: http://lkml.kernel.org/r/CAOJsxLHv17Ys3M7P5q25imkUxQW6LE_vABxh1N3Tt7Mv6Ho4iw@mail.gmail.com Signed-off-by: Michael Witten Cc: Mark Brown Signed-off-by: Greg Kroah-Hartman commit adb97c299904814edb0bb26ae894139ca46ae446 Author: Nicholas Bellinger Date: Tue Jul 30 04:04:02 2013 +0000 iscsi-target: Fix iscsit_sequence_cmd reject handling for iser commit 561bf15892375597ee59d473a704a3e634c4f311 upstream This patch moves ISCSI_OP_REJECT failures into iscsit_sequence_cmd() in order to avoid external iscsit_reject_cmd() reject usage for all PDU types. It also updates PDU specific handlers for traditional iscsi-target code to not reset the session after posting a ISCSI_OP_REJECT during setup. (v2: Fix CMDSN_LOWER_THAN_EXP for ISCSI_OP_SCSI to call target_put_sess_cmd() after iscsit_sequence_cmd() failure) Signed-off-by: Nicholas Bellinger Cc: Or Gerlitz Cc: Mike Christie Signed-off-by: Greg Kroah-Hartman commit 1aa58ccd029fc75c115ae35c3fcb4d43043c0725 Author: Nicholas Bellinger Date: Tue Jul 30 04:04:01 2013 +0000 iscsi-target: Fix iscsit_add_reject* usage for iser commit ba159914086f06532079fc15141f46ffe7e04a41 upstream This patch changes iscsit_add_reject() + iscsit_add_reject_from_cmd() usage to not sleep on iscsi_cmd->reject_comp to address a free-after-use usage bug in v3.10 with iser-target code. It saves ->reject_reason for use within iscsit_build_reject() so the correct value for both transport cases. It also drops the legacy fail_conn parameter usage throughput iscsi-target code and adds two iscsit_add_reject_cmd() and iscsit_reject_cmd helper functions, along with various small cleanups. (v2: Re-enable target_put_sess_cmd() to be called from iscsit_add_reject_from_cmd() for rejects invoked after target_get_sess_cmd() has been called) Signed-off-by: Nicholas Bellinger Cc: Or Gerlitz Cc: Mike Christie Signed-off-by: Greg Kroah-Hartman commit 6655d76ecb91fa618c4d0d0dd653e94078b3f050 Author: Sergey Senozhatsky Date: Sun Jul 14 14:03:27 2013 +0300 radeon kms: do not flush uninitialized hotplug work commit a01c34f72e7cd2624570818f579b5ab464f93de2 upstream. Fix a warning from lockdep caused by calling flush_work() for uninitialized hotplug work. Initialize hotplug_work, audio_work and reset_work upon successful radeon_irq_kms_init() completion and thus perform hotplug flush_work only when rdev->irq.installed is true. [ 4.790019] [drm] Loading CEDAR Microcode [ 4.790943] r600_cp: Failed to load firmware "radeon/CEDAR_smc.bin" [ 4.791152] [drm:evergreen_startup] *ERROR* Failed to load firmware! [ 4.791330] radeon 0000:01:00.0: disabling GPU acceleration [ 4.792633] INFO: trying to register non-static key. [ 4.792792] the code is fine but needs lockdep annotation. [ 4.792953] turning off the locking correctness validator. [ 4.793114] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc0-dbg-10676-gfe56456-dirty #1816 [ 4.793314] Hardware name: Acer Aspire 5741G /Aspire 5741G , BIOS V1.20 02/08/2011 [ 4.793507] ffffffff821fd810 ffff8801530b9a18 ffffffff8160434e 0000000000000002 [ 4.794155] ffff8801530b9ad8 ffffffff810b8404 ffff8801530b0798 ffff8801530b0000 [ 4.794789] ffff8801530b9b00 0000000000000046 00000000000004c0 ffffffff00000000 [ 4.795418] Call Trace: [ 4.795573] [] dump_stack+0x4e/0x82 [ 4.795731] [] __lock_acquire+0x1a64/0x1d30 [ 4.795893] [] ? dev_vprintk_emit+0x50/0x60 [ 4.796034] [] lock_acquire+0xa4/0x200 [ 4.796216] [] ? flush_work+0x5/0x280 [ 4.796375] [] flush_work+0x3d/0x280 [ 4.796520] [] ? flush_work+0x5/0x280 [ 4.796682] [] ? trace_hardirqs_on_caller+0xfd/0x1c0 [ 4.796862] [] ? delay_tsc+0x95/0xf0 [ 4.797024] [] radeon_irq_kms_fini+0x2b/0x70 [ 4.797186] [] evergreen_init+0x2a9/0x2e0 [ 4.797347] [] radeon_device_init+0x5ef/0x700 [ 4.797511] [] ? pci_find_capability+0x47/0x50 [ 4.797672] [] radeon_driver_load_kms+0x8d/0x150 [ 4.797843] [] drm_get_pci_dev+0x166/0x280 [ 4.798007] [] ? kfree+0xf5/0x2e0 [ 4.798168] [] ? radeon_pci_probe+0x98/0xd0 [ 4.798329] [] radeon_pci_probe+0xaa/0xd0 [ 4.798489] [] pci_device_probe+0x84/0xe0 [ 4.798644] [] driver_probe_device+0x76/0x240 [ 4.798805] [] __driver_attach+0x93/0xa0 [ 4.798948] [] ? __device_attach+0x40/0x40 [ 4.799126] [] bus_for_each_dev+0x6b/0xb0 [ 4.799272] [] driver_attach+0x1e/0x20 [ 4.799434] [] bus_add_driver+0x1f0/0x280 [ 4.799596] [] driver_register+0x74/0x150 [ 4.799758] [] __pci_register_driver+0x5d/0x60 [ 4.799936] [] ? ttm_init+0x67/0x67 [ 4.800081] [] drm_pci_init+0x115/0x130 [ 4.800243] [] ? ttm_init+0x67/0x67 [ 4.800405] [] radeon_init+0x9c/0xba [ 4.800586] [] do_one_initcall+0xfa/0x150 [ 4.800746] [] ? parse_args+0x120/0x330 [ 4.800909] [] kernel_init_freeable+0x111/0x191 [ 4.801052] [] ? do_early_param+0x88/0x88 [ 4.801233] [] ? rest_init+0x140/0x140 [ 4.801393] [] kernel_init+0xe/0x180 [ 4.801556] [] ret_from_fork+0x7c/0xb0 [ 4.801718] [] ? rest_init+0x140/0x140 Signed-off-by: Sergey Senozhatsky Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 3d63d1e0fe8aeed27f6ef38fa6eaf518dee1bbab Author: David Vrabel Date: Fri Jul 19 15:51:58 2013 +0100 xen/evtchn: avoid a deadlock when unbinding an event channel commit 179fbd5a45f0d4034cc6fd37b8d367a3b79663c4 upstream. Unbinding an event channel (either with the ioctl or when the evtchn device is closed) may deadlock because disable_irq() is called with port_user_lock held which is also locked by the interrupt handler. Think of the IOCTL_EVTCHN_UNBIND is being serviced, the routine has just taken the lock, and an interrupt happens. The evtchn_interrupt is invoked, tries to take the lock and spins forever. A quick glance at the code shows that the spinlock is a local IRQ variant. Unfortunately that does not help as "disable_irq() waits for the interrupt handler on all CPUs to stop running. If the irq occurs on another VCPU, it tries to take port_user_lock and can't because the unbind ioctl is holding it." (from David). Hence we cannot depend on the said spinlock to protect us. We could make it a system wide IRQ disable spinlock but there is a better way. We can piggyback on the fact that the existence of the spinlock is to make get_port_user() checks be up-to-date. And we can alter those checks to not depend on the spin lock (as it's protected by u->bind_mutex in the ioctl) and can remove the unnecessary locking (this is IOCTL_EVTCHN_UNBIND) path. In the interrupt handler we cannot use the mutex, but we do not need it. "The unbind disables the irq before making the port user stale, so when you clear it you are guaranteed that the interrupt handler that might use that port cannot be running." (from David). Hence this patch removes the spinlock usage on the teardown path and piggybacks on disable_irq happening before we muck with the get_port_user() data. This ensures that the interrupt handler will never run on stale data. Signed-off-by: David Vrabel Signed-off-by: Konrad Rzeszutek Wilk [v1: Expanded the commit description a bit] Signed-off-by: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit d0f1a6e5be8d8ada73891832af1bd3ecb3f52bb7 Author: Al Viro Date: Sat Jul 20 03:13:55 2013 +0400 livelock avoidance in sget() commit acfec9a5a892f98461f52ed5770de99a3e571ae2 upstream. Eric Sandeen has found a nasty livelock in sget() - take a mount(2) about to fail. The superblock is on ->fs_supers, ->s_umount is held exclusive, ->s_active is 1. Along comes two more processes, trying to mount the same thing; sget() in each is picking that superblock, bumping ->s_count and trying to grab ->s_umount. ->s_active is 3 now. Original mount(2) finally gets to deactivate_locked_super() on failure; ->s_active is 2, superblock is still ->fs_supers because shutdown will *not* happen until ->s_active hits 0. ->s_umount is dropped and now we have two processes chasing each other: s_active = 2, A acquired ->s_umount, B blocked A sees that the damn thing is stillborn, does deactivate_locked_super() s_active = 1, A drops ->s_umount, B gets it A restarts the search and finds the same superblock. And bumps it ->s_active. s_active = 2, B holds ->s_umount, A blocked on trying to get it ... and we are in the earlier situation with A and B switched places. The root cause, of course, is that ->s_active should not grow until we'd got MS_BORN. Then failing ->mount() will have deactivate_locked_super() shut the damn thing down. Fortunately, it's easy to do - the key point is that grab_super() is called only for superblocks currently on ->fs_supers, so it can bump ->s_count and grab ->s_umount first, then check MS_BORN and bump ->s_active; we must never increment ->s_count for superblocks past ->kill_sb(), but grab_super() is never called for those. The bug is pretty old; we would've caught it by now, if not for accidental exclusion between sget() for block filesystems; the things like cgroup or e.g. mtd-based filesystems don't have anything of that sort, so they get bitten. The right way to deal with that is obviously to fix sget()... Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit ba9a3c3ce30b8c399d5bfeef1d48a26170dc499e Author: Gianluca Anzolin Date: Thu Jul 25 07:26:16 2013 +0200 tty_port: Fix refcounting leak in tty_port_tty_hangup() commit 1d9e689c934bd5ecb0f273c6c65e0655c5cfee5f upstream. The function tty_port_tty_hangup() could leak a reference to the tty_struct: struct tty_struct *tty = tty_port_tty_get(port); if (tty && (!check_clocal || !C_CLOCAL(tty))) { tty_hangup(tty); tty_kref_put(tty); } If tty != NULL and the second condition is false we never call tty_kref_put and the reference is leaked. Fix by always calling tty_kref_put() which accepts a NULL argument. The patch fixes a regression introduced by commit aa27a094. Acked-by: Gustavo Padovan Signed-off-by: Gianluca Anzolin Acked-by: Jiri Slaby Signed-off-by: Greg Kroah-Hartman commit 0bd6f78c3016704d2b6978eab835dcd0759dca36 Author: Oleg Nesterov Date: Wed Jul 31 13:53:28 2013 -0700 mm: mempolicy: fix mbind_range() && vma_adjust() interaction commit 3964acd0dbec123aa0a621973a2a0580034b4788 upstream. vma_adjust() does vma_set_policy(vma, vma_policy(next)) and this is doubly wrong: 1. This leaks vma->vm_policy if it is not NULL and not equal to next->vm_policy. This can happen if vma_merge() expands "area", not prev (case 8). 2. This sets the wrong policy if vma_merge() joins prev and area, area is the vma the caller needs to update and it still has the old policy. Revert commit 1444f92c8498 ("mm: merging memory blocks resets mempolicy") which introduced these problems. Change mbind_range() to recheck mpol_equal() after vma_merge() to fix the problem that commit tried to address. Signed-off-by: Oleg Nesterov Acked-by: KOSAKI Motohiro Cc: Steven T Hampson Cc: Mel Gorman Cc: KOSAKI Motohiro Cc: Rik van Riel Cc: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8fc2b1321b8fb0ed3d80de5303b8db99923bdecf Author: Rong Wang Date: Sun Jul 28 23:01:35 2013 +0800 usb: gadget: udc-core: fix the typo of udc state attribute commit 1894870eb4240399fabc6f0cb8c6fff4e6edbe83 upstream. The name of udc state attribute file under sysfs is registered as "state", while usb_gadget_set_state take it as "status" when it's going to update. This patch fixes the typo. Signed-off-by: Rong Wang Signed-off-by: Barry Song Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 2ff7687bca58a839fd36e5a0b167465b4fa8bf51 Author: Rick Farina (Zero_Chaos) Date: Mon Jul 29 15:17:59 2013 -0400 USB: serial: ftdi_sio: add more RT Systems ftdi devices commit fed1f1ed90bce42ea010e2904cbc04e7b8304940 upstream. RT Systems makes many usb serial cables based on the ftdi_sio driver for programming various amateur radios. This patch is a full listing of their current product offerings and should allow these cables to all be recognized. Signed-off-by: Rick Farina (Zero_Chaos) Signed-off-by: Greg Kroah-Hartman commit 758057d66f667d17034b6080d06a2c6b5b498544 Author: Larry Finger Date: Fri Jun 28 09:12:53 2013 -0500 rtlwifi: Initialize power-setting callback for USB devices commit bcfb879432094c267c35a7ff75d953d3a66c193a upstream. Commit a269913c5 entitled "rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue" has two bugs for USB drivers. Firstly, the work queue in question was not initialized. Secondly, the callback routine used by this queue is contained within the file used for PCI devices. As a result, it is not available for architectures without PCI hardware. Signed-off-by: Larry Finger Reported-by: Richard Genoud Tested-by: Richard Genoud Cc: Richard Genoud Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 6f8bbaf568c7f2c497558bfd04654c0b9841ad57 Author: Alex Deucher Date: Tue Jul 30 00:22:53 2013 -0400 drm/radeon/atom: initialize more atom interpretor elements to 0 commit 42a21826dc54583cdb79cc8477732e911ac9c376 upstream. The ProcessAuxChannel table on some rv635 boards assumes the divmul members are initialized to 0 otherwise we get an invalid fb offset since it has a bad mask set when setting the fb base. While here initialize all the atom interpretor elements to 0. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=60639 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 8414d407af75ccbd398898fdb108189afc22ded4 Author: Alex Deucher Date: Fri Jul 26 13:26:05 2013 -0400 drm/radeon: fix audio dto programming on DCE4+ commit 7d61d835824f73dc4097b51f800382467c8049c5 upstream. We need to set the dto source before setting the dividers otherwise we may get stability problems with the dto leading to audio playback problems. Signed-off-by: Alex Deucher Reviewed-by: Christian König Signed-off-by: Greg Kroah-Hartman commit 6a5213cb7db96dc498b6c3cf6642ab6c8b2e08a3 Author: Maarten Lankhorst Date: Tue Jul 23 15:49:39 2013 +0200 drm/nouveau: fix semaphore dmabuf obj commit 7a7da592cbb22a1d360638dbecc393470c5effe3 upstream. Fixes some dmabuf object errors on nv50 chipset and below. Signed-off-by: Maarten Lankhorst Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit c9af307d38974264922d35c77bb71087d171f8f8 Author: Ben Widawsky Date: Tue Jul 30 16:27:57 2013 -0700 drm/i915: fix missed hunk after GT access breakage commit e1b4d3036c07ff137955fb1c0197ab62534f46ec upstream. Upon some code refactoring, a hunk was missed. This was fixed for next, but missed the current trees, and hasn't yet been merged by Dave Airlie. It is fixed in: commit 907b28c56ea40629aa6595ddfa414ec2fc7da41c Author: Chris Wilson Date: Fri Jul 19 20:36:52 2013 +0100 drm/i915: Colocate all GT access routines in the same file It is introduced by: commit 181d1b9e31c668259d3798c521672afb8edd355c Author: Daniel Vetter Date: Sun Jul 21 13:16:24 2013 +0200 drm/i915: fix up gt init sequence fallout Reported-by: Dave Jones Signed-off-by: Ben Widawsky Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 9682e399d77f9bc0a5c9230bd1d69a3e75572ef1 Author: Daniel Vetter Date: Sun Jul 21 13:16:24 2013 +0200 drm/i915: fix up gt init sequence fallout commit 181d1b9e31c668259d3798c521672afb8edd355c upstream. The regression fix for gen6+ rps fallout commit 7dcd2677ea912573d9ed4bcd629b0023b2d11505 Author: Konstantin Khlebnikov Date: Wed Jul 17 10:22:58 2013 +0400 drm/i915: fix long-standing SNB regression in power consumption after resume unintentionally also changed the init sequence ordering between gt_init and gt_reset - we need to reset BIOS damage like leftover forcewake references before we run our own code. Otherwise we can get nasty dmesg noise like [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear. again. Since _reset suggests that we first need to have stuff initialized (which isn't the case here) call it sanitze instead. While at it also block out the rps disable introduced by the above commit on ilk: We don't have any knowledge of ilk rps being broken in similar ways. And the disable functions uses the default hw state which is only read out when we're enabling rps. So essentially we've been writing random grabage into that register. Reported-by: Chris Wilson Cc: Chris Wilson Cc: Konstantin Khlebnikov Cc: Jesse Barnes Tested-by: Chris Wilson Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 8bc91b60f77d174f2485e10be8708c2fd7b85bfb Author: Chris Wilson Date: Fri Jul 19 20:36:51 2013 +0100 drm/i915: Serialize almost all register access commit a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a upstream. In theory, the different register blocks were meant to be only ever touched when holding either the struct_mutex, mode_config.lock or even a specific localised lock. This does not seem to be the case, and the hardware reacts extremely badly if we attempt to concurrently access two registers within the same cacheline. The HSD suggests that we only need to do this workaround for display range registers. However, upon review we need to serialize the multiple stages in our register write functions - if only for preemption protection. Irrespective of the hardware requirements, the current io functions are a little too loose with respect to the combination of pre- and post-condition testing that we do in conjunction with the actual io. As a result, we may be pre-empted and generate both false-postive and false-negative errors. Note well that this is a "90%" solution, there remains a few direct users of ioread/iowrite which will be fixed up in the next few patches. Since they are more invasive and that this simple change will prevent almost all lockups on Haswell, we kept this patch simple to facilitate backporting to stable. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63914 Signed-off-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit f12155987bdc8d175b41b2fcbd88e8788c1af92d Author: Kamal Mostafa Date: Fri Jul 19 15:02:01 2013 -0700 drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight commit e85843bec6c2ea7c10ec61238396891cc2b753a9 upstream. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941 BugLink: https://bugs.launchpad.net/bugs/1163720 BugLink: https://bugs.launchpad.net/bugs/1162026 Some machines suffer from non-functional backlight controls if BLM_PCH_PWM_ENABLE is set, so provide a quirk to avoid doing so. Apply this quirk to Dell XPS 13 models. Tested-by: Eric Griffith Tested-by: Kent Baxley Signed-off-by: Kamal Mostafa Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 19a280cac37e30243023a7f53651504a135ac960 Author: Daniel Vetter Date: Wed Jul 17 14:51:28 2013 +0200 drm/i915: correctly restore fences with objects attached commit 94a335dba34ff47cad3d6d0c29b452d43a1be3c8 upstream. To avoid stalls we delay tiling changes and especially hold of committing the new fence state for as long as possible. Synchronization points are in the execbuf code and in our gtt fault handler. Unfortunately we've missed that tricky detail when adding proper fence restore code in commit 19b2dbde5732170a03bd82cc8bd442cf88d856f7 Author: Chris Wilson Date: Wed Jun 12 10:15:12 2013 +0100 drm/i915: Restore fences after resume and GPU resets The result was that we've restored fences for objects with no tiling, since the object<->fence link still existed after resume. Now that wouldn't have been too bad since any subsequent access would have fixed things up, but if we've changed from tiled to untiled real havoc happened: The tiling stride is stored -1 in the fence register, so a stride of 0 resulted in all 1s in the top 32bits, and so a completely bogus fence spanning everything from the start of the object to the top of the GTT. The tell-tale in the register dumps looks like: FENCE START 2: 0x0214d001 FENCE END 2: 0xfffff3ff Bit 11 isn't set since the hw doesn't store it, even when writing all 1s (at least on my snb here). To prevent such a gaffle in the future add a sanity check for fences with an untiled object attached in i915_gem_write_fence. v2: Fix the WARN, spotted by Chris. v3: Trying to reuse get_fences looked ugly and obfuscated the code. Instead reuse update_fence and to make it really dtrt also move the fence dirty state clearing into update_fence. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60530 Cc: Chris Wilson Cc: Stéphane Marchesin Reviewed-by: Chris Wilson Tested-by: Matthew Garrett Tested-by: Björn Bidar Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 6f973258b047d2913abe2bd1aad95f21cb47d5f6 Author: Chris Wilson Date: Wed Jul 17 12:14:40 2013 +0100 drm/i915: Fix dereferencing invalid connectors in is_crtc_connector_off() commit 2e57f47d317dd035b18634b0c602272529368fcc upstream. In commit e3de42b68478a8c95dd27520e9adead2af9477a5 Author: Imre Deak Date: Fri May 3 19:44:07 2013 +0200 drm/i915: force full modeset if the connector is in DPMS OFF mode a new function was added that walked over the set of connectors to see if any of the currently associated CRTC was switched off. This function walked an array of connectors, rather than the array of pointers to connectors contained in the drm_mode_set - i.e. it was dereferencing far past the end of the first connector. This only becomes an issue if we attempt to use a clone mode (i.e. more than one connector per CRTC) such that set->num_connectors > 1. Reported-by: Timo Aaltonen Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65927 Signed-off-by: Chris Wilson Cc: Imre Deak Cc: Egbert Eich Cc: Jesse Barnes Cc: Daniel Vetter Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit f4332be72bc7a2095a21057e9db2c38bd44486b2 Author: Konstantin Khlebnikov Date: Wed Jul 17 10:22:58 2013 +0400 drm/i915: fix long-standing SNB regression in power consumption after resume v2 commit 7dcd2677ea912573d9ed4bcd629b0023b2d11505 upstream. This patch fixes regression in power consumtion of sandy bridge gpu, which exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that it's extremely busy. After that it never reaches rc6 state. Bug exists since kernel v3.6: commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 Author: Jesse Barnes Date: Thu Jun 14 11:04:48 2012 -0700 drm/i915: load boot context at driver init time For some reason RC6 is already enabled at the beginning of resuming process. Following initliaztion breaks some internal state and confuses RPS engine. This patch disables RC6 at the beginnig of resume and initialization. I've rearranged initialization sequence, because intel_disable_gt_powersave() needs initialized force_wake_get/put and some locks from the dev_priv. Note: The culprit in the initialization sequence seems to be the write to MBCTL added in the above mentioned commit. The first version of this patch just held a forcewake reference across the clock gating init functions, which seems to have been enought to gather quite a few positive test reports. But since that smelled a bit like ad-hoc duct-tape v2 now just disables rps/rc6 across the entire hw setup. [danvet: Add note about v1 vs. v2 of this patch and use standard layout for the commit citation. Also add the tested-bys from v1 and a cc: stable.] References https://bugs.freedesktop.org/show_bug.cgi?id=54089 References https://bugzilla.kernel.org/show_bug.cgi?id=58971 References https://patchwork.kernel.org/patch/2827634/ (patch v1) Signed-off-by: Konstantin Khlebnikov Tested-by: Alexander Kaltsas (v1) Tested-by: rocko (v1) Tested-by: JohnMB (v1) Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 1177b868c8b99fa8e4d88ef8b9542741b0d60055 Author: Chris Wilson Date: Wed Jul 10 13:36:23 2013 +0100 drm/i915: Fix incoherence with fence updates on Sandybridge+ commit d18b9619034230b6f945e215276425636ca401fe upstream. This hopefully fixes the root cause behind the workaround added in commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06 Author: Chris Wilson Date: Thu Apr 4 21:31:03 2013 +0100 drm/i915: Workaround incoherence between fences and LLC across multiple CPUs Thanks to further investigation by Jon Bloomfield, he realised that the 64-bit register might be broken up by the hardware into two 32-bit writes (a problem we have encountered elsewhere). This non-atomicity would then cause an issue where a second thread would see an intermediate register state (new high dword, old low dword), and this register would randomly be used in preference to its own thread register. This would cause the second thread to read from and write into a fairly random tiled location. Breaking the operation into 3 explicit 32-bit updates (first disable the fence, poke the upper bits, then poke the lower bits and enable) ensures that, given proper serialisation between the 32-bit register write and the memory transfer, that the fence value is always consistent. Armed with this knowledge, we can explain how the previous workaround work. The key to the corruption is that a second thread sees an erroneous fence register that conflicts and overrides its own. By serialising the fence update across all CPUs, we have a small window where no GTT access is occurring and so hide the potential corruption. This also leads to the conclusion that the earlier workaround was incomplete. v2: Be overly paranoid about the order in which fence updates become visible to the GPU to make really sure that we turn the fence off before doing the update, and then only switch the fence on afterwards. Signed-off-by: Jon Bloomfield Signed-off-by: Chris Wilson Cc: Daniel Vetter Cc: Carsten Emde Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 8cdbac3c4f987bd260009d3a7b8c3c8c37b5acdb Author: Guenter Roeck Date: Tue Jul 9 16:00:31 2013 -0700 Partially revert "drm/i915: unconditionally use mt forcewake on hsw/ivb" commit c11e5f35ab490bd30591563816fbc83526521777 upstream. This patch partially reverts commit 36ec8f877481449bdfa072e6adf2060869e2b970 for IvyBridge CPUs. The original commit results in repeated 'Timed out waiting for forcewake old ack to clear' messages on a Supermicro C7H61 board (BIOS version 2.00 and 2.00b) with i7-3770K CPU. It ultimately results in a hangup if the system is highly loaded. Reverting the commit for IvyBridge CPUs fixes the issue. Issue a warning if the CPU is IvyBridge and mt forcewake is disabled, since this condition can result in secondary issues. v2: Only revert patch for Ivybridge CPUs Issue info message if mt forcewake is disabled on Ivybridge Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60541 Cc: Jesse Barnes Cc: Daniel Vetter Cc: Mika Kuoppala Signed-off-by: Guenter Roeck Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66139 Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit c33535efc0e1a637a7dbad918e1a0bf5a692dcdd Author: Chris Wilson Date: Tue Jul 9 09:22:39 2013 +0100 drm/i915: Fix write-read race with multiple rings commit 02978ff57a5bdfbf703d2bc5a4d933a53ede3144 upstream. Daniel noticed a problem where is we wrote to an object with ring A in the middle of a very long running batch, then executed a quick batch on ring B before a batch that reads from the same object, its obj->ring would now point to ring B, but its last_write_seqno would be still relative to ring A. This would allow for the user to read from the object before the GPU had completed the write, as set_domain would only check that ring B had passed the last_write_seqno. To fix this simply (and inelegantly), we bump the last_write_seqno when switching rings so that the last_write_seqno is always relative to the current obj->ring. This fixes igt/tests/gem_write_read_ring_switch. Signed-off-by: Chris Wilson Cc: Daniel Vetter [danvet: Add note about the newly created igt which exercises this bug.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 5ac4dd137c34860870e0c0438180c2836053eadf Author: Daniel Vetter Date: Fri Jul 5 23:39:50 2013 +0200 drm/i915: fix up ring cleanup for the i830/i845 CS tlb w/a commit aaf8a5167291b65e9116cb8736d862965b57c13a upstream. It's not a good idea to also run the pipe_control cleanup. This regression has been introduced whith the original cs tlb w/a in commit b45305fce5bb1abec263fcff9d81ebecd6306ede Author: Daniel Vetter Date: Mon Dec 17 16:21:27 2012 +0100 drm/i915: Implement workaround for broken CS tlb on i830/845 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64610 Cc: Chris Wilson Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit d54b22e585edd4401786e7c02cd85bc97fff5ffb Author: Alex Deucher Date: Fri Jul 19 17:44:43 2013 -0400 drm/radeon: improve dac adjust heuristics for legacy pdac commit 03ed8cf9b28d886c64c7e705c7bb1a365fd8fb95 upstream. Hopefully avoid more quirks in the future due to bogus vbios dac data. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 405a7ccac881355809e07a4f00e0e8528ee7cec5 Author: Mark Kettenis Date: Sun Jul 21 16:44:09 2013 -0400 drm/radeon: fix combios tables on older cards commit cef1d00cd56f600121ad121875655ad410a001b8 upstream. Noticed that my old Radeon 7500 hung after printing drm: GPU not posted. posting now... when it wasn't selected as the primary card the BIOS. Some digging revealed that it was hanging in combios_parse_mmio_table() while parsing the ASIC INIT 3 table. Looking at the BIOS ROM for the card, it becomes obvious that there is no ASIC INIT 3 table in the BIOS. The code is just processing random garbage. No surprise it hangs! Why do I say that there is no ASIC INIT 3 table is the BIOS? This table is found through the MISC INFO table. The MISC INFO table can be found at offset 0x5e in the COMBIOS header. But the header is smaller than that. The COMBIOS header starts at offset 0x126. The standard PCI Data Structure (the bit that starts with 'PCIR') lives at offset 0x180. That means that the COMBIOS header can not be larger than 0x5a bytes and therefore cannot contain a MISC INFO table. I looked at a dozen or so BIOS images, some my own, some downloaded from: It is fairly obvious that the size of the COMBIOS header can be found at offset 0x6 of the header. Not sure if it is a 16-bit number or just an 8-bit number, but that doesn't really matter since the tables seems to be always smaller than 256 bytes. So I think combios_get_table_offset() should check if the requested table is present. This can be done by checking the offset against the size of the header. See the diff below. The diff is against the WIP OpenBSD codebase that roughly corresponds to Linux 3.8.13 at this point. But I don't think this bit of the code changed much since then. For what it is worth: Signed-off-by: Mark Kettenis Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit d19ccc405c87c8ca17ea3e1091d6a6eb2d9ac674 Author: Ondrej Zary Date: Fri Jul 19 21:08:48 2013 +0200 drm/radeon: Another card with wrong primary dac adj commit f7929f34fa0e0bb6736a2484fdc07d77a1653081 upstream. Hello, got another card with "too bright" problem: Sapphire Radeon VE 7000 DDR (VGA+S-Video) lspci -vnn: 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] [1002:5159] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Sapphire Radeon VE 7000 DDR [174b:7c28] The patch below fixes the problem for this card. But I don't like the blacklist, couldn't some heuristic be used instead? The interesting thing is that the manufacturer is the same as the other card needing the same quirk. I wonder how many different types are broken this way. The "wrong" ps2_pdac_adj value that comes from BIOS on this card is 0x300. ==================== drm/radeon: Add primary dac adj quirk for Sapphire Radeon VE 7000 DDR Values from BIOS are wrong, causing too bright colors. Use default values instead. Signed-off-by: Ondrej Zary Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit f57cb1a2d0e5d88484616285a91560a6f5555e68 Author: Alex Deucher Date: Thu Jul 18 11:13:53 2013 -0400 drm/radeon: fix endian issues with DP handling (v3) commit 34be8c9af7b8728465963740fc11136ae90dfc36 upstream. The atom interpreter expects data in LE format, so swap the message buffer as apprioriate. v2: properly handle non-dw aligned byte counts. v3: properly handle remainder Signed-off-by: Alex Deucher Cc: Dong He Signed-off-by: Greg Kroah-Hartman commit f92c99de9db693786ffc0f44503eece2bc6a237a Author: Alex Deucher Date: Fri Jul 12 15:46:09 2013 -0400 drm/radeon: allow selection of alignment in the sub-allocator commit 6c4f978b357bc779c703fda1f200e9179623d3e9 upstream. There are cases where we need more than 4k alignment. No functional change with this commit. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit c35486752501196044bbc4a1c61c43f39b17c2ff Author: Christian König Date: Fri Jul 12 10:05:47 2013 +0200 drm/radeon: fix UVD fence emit commit c9a6ca4abd5f1978ef15b3ece3474f4372ae5fe7 upstream. Currently doesn't matter cause we allocate the fence in the lower 265MB anyway. Reported-by: Frank Huang Signed-off-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 1b4eafabcef5a74ccbc6edd201353cf23046a5a5 Author: Alex Deucher Date: Mon Jul 8 18:16:56 2013 -0400 drm/radeon/hdmi: make sure we have an afmt block assigned commit c2b4cacfe9816c1fe378c785ce8a678cf0635ec6 upstream. Prevents a segfault if an afmt block is not assigned to the encoder such as in the LVDS or eDP case. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=66714 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit dabd2582219f0b1b1724a42e7be4045fa3686598 Author: Mikulas Patocka Date: Wed Jul 10 23:41:16 2013 +0100 dm verity: fix inability to use a few specific devices sizes commit b1bf2de07271932326af847a3c6a01fdfd29d4be upstream. Fix a boundary condition that caused failure for certain device sizes. The problem is reported at http://code.google.com/p/cryptsetup/issues/detail?id=160 For certain device sizes the number of hashes at a specific level was calculated incorrectly. It happens for example for a device with data and metadata block size 4096 that has 16385 blocks and algorithm sha256. The user can test if he is affected by this bug by running the "veritysetup verify" command and also by activating the dm-verity kernel driver and reading the whole block device. If it passes without an error, then the user is not affected. The condition for the bug is: Split the total number of data blocks (data_block_bits) into bit strings, each string has hash_per_block_bits bits. hash_per_block_bits is rounddown(log2(metadata_block_size/hash_digest_size)). Equivalently, you can say that you convert data_blocks_bits to 2^hash_per_block_bits base. If there some zero bit string below the most significant bit string and at least one bit below this zero bit string is set, then the bug happens. The same bug exists in the userspace veritysetup tool, so you must use fixed veritysetup too if you want to use devices that are affected by this boundary condition. Signed-off-by: Mikulas Patocka Cc: Milan Broz Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit ba0e6dd5e64bbf820669f7451ac03f4f11cd64f7 Author: Mikulas Patocka Date: Wed Jul 10 23:41:15 2013 +0100 dm ioctl: set noio flag to avoid __vmalloc deadlock commit 1c0e883e86ece31880fac2f84b260545d66a39e0 upstream. Set noio flag while calling __vmalloc() because it doesn't fully respect gfp flags to avoid a possible deadlock (see commit 502624bdad3dba45dfaacaf36b7d83e39e74b2d2). This should be backported to stable kernels 3.8 and newer. The kernel 3.8 doesn't have memalloc_noio_save(), so we should set and restore process flag PF_MEMALLOC instead. Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit 565ff95cdc72f76d53d4e98d5e84254368b9a041 Author: Hannes Reinecke Date: Wed Jul 10 23:41:15 2013 +0100 dm mpath: fix ioctl deadlock when no paths commit 6c182cd88d179cbbd06f4f8a8a19b6977940753f upstream. When multipath needs to retry an ioctl the reference to the current live table needs to be dropped. Otherwise a deadlock occurs when all paths are down: - dm_blk_ioctl takes a reference to the current table and spins in multipath_ioctl(). - A new table is being loaded, but upon resume the process hangs in dm_table_destroy() waiting for references to drop to zero. With this patch the reference to the old table is dropped prior to retry, thereby avoiding the deadlock. Signed-off-by: Hannes Reinecke Cc: Mike Snitzer Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit f03519471a796be1c6d2aa9871928139828550c5 Author: Lan Tianyu Date: Tue Jul 16 10:07:21 2013 +0800 ACPI / video: ignore BIOS initial backlight value for Fujitsu E753 commit 9657a565a476d517451c10b0bcc106e300785aff upstream. The BIOS of FUjitsu E753 reports an incorrect initial backlight value for WIN8 compatible OS, causing backlight to be dark during startup. This change causes the incorrect initial value from BIOS to be ignored. References: https://bugzilla.kernel.org/show_bug.cgi?id=60161 Reported-and-tested-by: Jan Hinnerk Stosch Signed-off-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit bf59e1292e96b3dd4a2c58bbe8ac21e24e71dc42 Author: Toshi Kani Date: Wed Jul 10 10:47:13 2013 -0600 ACPI / memhotplug: Fix a stale pointer in error path commit d19f503e22316a84c39bc19445e0e4fdd49b3532 upstream. device->driver_data needs to be cleared when releasing its data, mem_device, in an error path of acpi_memory_device_add(). The function evaluates the _CRS of memory device objects, and fails when it gets an unexpected resource or cannot allocate memory. A kernel crash or data corruption may occur when the kernel accesses the stale pointer. Signed-off-by: Toshi Kani Reviewed-by: Yasuaki Ishimatsu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 85471df478e22dd96ca4756789abc795683addc9 Author: Rafael J. Wysocki Date: Fri Jul 12 13:45:59 2013 +0200 ACPI / scan: Do not try to attach scan handlers to devices having them commit 3a391a39593b48341f0908511590a6c0e55cc069 upstream. In acpi_bus_device_attach(), if there is an ACPI device object for the given handle and that device object has a scan handler attached to it already, there's nothing more to do for that handle. Moreover, if acpi_scan_attach_handler() is called then, it may execute the .attach() callback of the ACPI scan handler already attached to the device object and that may lead to interesting breakage. For this reason, make acpi_bus_device_attach() return success immediately when the handle's device object has a scan handler attached to it. Reported-by: Toshi Kani Signed-off-by: Rafael J. Wysocki Acked-by: Toshi Kani Signed-off-by: Greg Kroah-Hartman commit 9d80c9e6f3345b343b9a095e8591f7c8a164b2c0 Author: Rafael J. Wysocki Date: Mon Jul 8 02:01:53 2013 +0200 ACPI / scan: Always call acpi_bus_scan() for bus check notifications commit 8832f7e43fa7f0f19bd54e13766a825dd1ed4d6f upstream. An ACPI_NOTIFY_BUS_CHECK notification means that we should scan the entire namespace starting from the given handle even if the device represented by that handle is present (other devices below it may just have appeared). For this reason, modify acpi_scan_bus_device_check() to always run acpi_bus_scan() if the notification being handled is of type ACPI_NOTIFY_BUS_CHECK. Signed-off-by: Rafael J. Wysocki Acked-by: Toshi Kani Signed-off-by: Greg Kroah-Hartman commit 8acd5b1eaaf5b06ca149e697ed2a017a748bcd57 Author: Daniel Mack Date: Thu Jul 4 13:11:03 2013 +0200 regmap: cache: bail in regmap_async_complete() for bus-less maps commit f2e055e7c9c6084bfbaa68701e52562acf96419e upstream. Commit f8bd822cb ("regmap: cache: Factor out block sync") made regcache_rbtree_sync() call regmap_async_complete(), which in turn does not check for map->bus before dereferencing it. This causes a NULL pointer dereference on bus-less maps. Signed-off-by: Daniel Mack Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e39992ecaa7230126f96285a19493a9883294fdf Author: K. Y. Srinivasan Date: Sun Jul 14 22:38:12 2013 -0700 Drivers: hv: balloon: Do not post pressure status if interrupted commit c5e2254f8d63a6654149aa32ac5f2b7dd66a976d upstream. When we are posting pressure status, we may get interrupted and handle the un-balloon operation. In this case just don't post the status as we know the pressure status is stale. Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman commit 7b7295e5a040abf574110c14de67e6b463a1d921 Author: K. Y. Srinivasan Date: Sun Jul 14 22:38:11 2013 -0700 Drivers: hv: balloon: Fix a bug in the hot-add code commit ed07ec93e83ec471d365ce084e43ad90fd205903 upstream. As we hot-add 128 MB chunks of memory, we wait to ensure that the memory is onlined before attempting to hot-add the next chunk. If the udev rule for memory hot-add is not executed within the allowed time, we would rollback the state and abort further hot-add. Since the hot-add has succeeded and the only failure is that the memory is not onlined within the allowed time, we should not be rolling back the state. Fix this bug. Signed-off-by: K. Y. Srinivasan Acked-by: Jason Wang Signed-off-by: Greg Kroah-Hartman commit 0ac7e44316a38c618afb851e05e0b71d8c83fef7 Author: K. Y. Srinivasan Date: Thu Jul 11 12:03:31 2013 -0700 Tools: hv: KVP: Fix a bug in IPV6 subnet enumeration commit ed4bb9744b41d39ba35080c2390e201575121dc7 upstream. Each subnet string needs to be separated with a semicolon. Fix this bug. Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman commit ce4eb5e3eda7c0b8f2eeb07d83c5857c7b373d8c Author: Harshula Jayasuriya Date: Tue Jul 23 14:21:35 2013 +1000 nfsd: nfsd_open: when dentry_open returns an error do not propagate as struct file commit e4daf1ffbe6cc3b12aab4d604e627829e93e9914 upstream. The following call chain: ------------------------------------------------------------ nfs4_get_vfs_file - nfsd_open - dentry_open - do_dentry_open - __get_file_write_access - get_write_access - return atomic_inc_unless_negative(&inode->i_writecount) ? 0 : -ETXTBSY; ------------------------------------------------------------ can result in the following state: ------------------------------------------------------------ struct nfs4_file { ... fi_fds = {0xffff880c1fa65c80, 0xffffffffffffffe6, 0x0}, fi_access = {{ counter = 0x1 }, { counter = 0x0 }}, ... ------------------------------------------------------------ 1) First time around, in nfs4_get_vfs_file() fp->fi_fds[O_WRONLY] is NULL, hence nfsd_open() is called where we get status set to an error and fp->fi_fds[O_WRONLY] to -ETXTBSY. Thus we do not reach nfs4_file_get_access() and fi_access[O_WRONLY] is not incremented. 2) Second time around, in nfs4_get_vfs_file() fp->fi_fds[O_WRONLY] is NOT NULL (-ETXTBSY), so nfsd_open() is NOT called, but nfs4_file_get_access() IS called and fi_access[O_WRONLY] is incremented. Thus we leave a landmine in the form of the nfs4_file data structure in an incorrect state. 3) Eventually, when __nfs4_file_put_access() is called it finds fi_access[O_WRONLY] being non-zero, it decrements it and calls nfs4_file_put_fd() which tries to fput -ETXTBSY. ------------------------------------------------------------ ... [exception RIP: fput+0x9] RIP: ffffffff81177fa9 RSP: ffff88062e365c90 RFLAGS: 00010282 RAX: ffff880c2b3d99cc RBX: ffff880c2b3d9978 RCX: 0000000000000002 RDX: dead000000100101 RSI: 0000000000000001 RDI: ffffffffffffffe6 RBP: ffff88062e365c90 R8: ffff88041fe797d8 R9: ffff88062e365d58 R10: 0000000000000008 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000007 R14: 0000000000000000 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #9 [ffff88062e365c98] __nfs4_file_put_access at ffffffffa0562334 [nfsd] #10 [ffff88062e365cc8] nfs4_file_put_access at ffffffffa05623ab [nfsd] #11 [ffff88062e365ce8] free_generic_stateid at ffffffffa056634d [nfsd] #12 [ffff88062e365d18] release_open_stateid at ffffffffa0566e4b [nfsd] #13 [ffff88062e365d38] nfsd4_close at ffffffffa0567401 [nfsd] #14 [ffff88062e365d88] nfsd4_proc_compound at ffffffffa0557f28 [nfsd] #15 [ffff88062e365dd8] nfsd_dispatch at ffffffffa054543e [nfsd] #16 [ffff88062e365e18] svc_process_common at ffffffffa04ba5a4 [sunrpc] #17 [ffff88062e365e98] svc_process at ffffffffa04babe0 [sunrpc] #18 [ffff88062e365eb8] nfsd at ffffffffa0545b62 [nfsd] #19 [ffff88062e365ee8] kthread at ffffffff81090886 #20 [ffff88062e365f48] kernel_thread at ffffffff8100c14a ------------------------------------------------------------ Signed-off-by: Harshula Jayasuriya Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 2b29b0d2f36f54034b7c038367f6b8e06bdc17ce Author: Anton Blanchard Date: Mon Jul 15 14:04:50 2013 +1000 powerpc/modules: Module CRC relocation fix causes perf issues commit 0e0ed6406e61434d3f38fb58aa8464ec4722b77e upstream. Module CRCs are implemented as absolute symbols that get resolved by a linker script. We build an intermediate .o that contains an unresolved symbol for each CRC. genksysms parses this .o, calculates the CRCs and writes a linker script that "resolves" the symbols to the calculated CRC. Unfortunately the ppc64 relocatable kernel sees these CRCs as symbols that need relocating and relocates them at boot. Commit d4703aef (module: handle ppc64 relocating kcrctabs when CONFIG_RELOCATABLE=y) added a hook to reverse the bogus relocations. Part of this patch created a symbol at 0x0: # head -2 /proc/kallsyms 0000000000000000 T reloc_start c000000000000000 T .__start This reloc_start symbol is causing lots of confusion to perf. It thinks reloc_start is a massive function that stretches from 0x0 to 0xc000000000000000 and we get various cryptic errors out of perf, including: problem incrementing symbol count, skipping event This patch removes the reloc_start linker script label and instead defines it as PHYSICAL_START. We also need to wrap it with CONFIG_PPC64 because the ppc32 kernel can set a non zero PHYSICAL_START at compile time and we wouldn't want to subtract it from the CRCs in that case. Signed-off-by: Anton Blanchard Acked-by: Rusty Russell Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 85acabeb3c8170634eb69bee29ad58eec6d05482 Author: Vakul Garg Date: Wed Jul 10 06:26:13 2013 +0000 crypto: caam - Fixed the memory out of bound overwrite issue commit 9c23b7d3d6bda41e2a27375df705485523a96dc8 upstream. When kernel is compiled with CONFIG_SLUB_DEBUG=y and CRYPTO_MANAGER_DISABLE_TESTS=n, during kernel bootup, the kernel reports error given below. The root cause is that in function hash_digest_key(), for allocating descriptor, insufficient memory was being allocated. The required number of descriptor words apart from input and output pointers are 8 (instead of 6). ============================================================================= BUG dma-kmalloc-32 (Not tainted): Redzone overwritten ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: 0xdec5dec0-0xdec5dec3. First byte 0x0 instead of 0xcc INFO: Allocated in ahash_setkey+0x60/0x594 age=7 cpu=1 pid=1257 __kmalloc+0x154/0x1b4 ahash_setkey+0x60/0x594 test_hash+0x260/0x5a0 alg_test_hash+0x48/0xb0 alg_test+0x84/0x228 cryptomgr_test+0x4c/0x54 kthread+0x98/0x9c ret_from_kernel_thread+0x64/0x6c INFO: Slab 0xc0bd0ba0 objects=19 used=2 fp=0xdec5d0d0 flags=0x0081 INFO: Object 0xdec5dea0 @offset=3744 fp=0x5c200014 Bytes b4 dec5de90: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ Object dec5dea0: b0 80 00 0a 84 41 00 0d f0 40 00 00 00 67 3f c0 .....A...@...g?. Object dec5deb0: 00 00 00 50 2c 14 00 50 f8 40 00 00 1e c5 d0 00 ...P,..P.@...... Redzone dec5dec0: 00 00 00 14 .... Padding dec5df68: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ Call Trace: [dec65b60] [c00071b4] show_stack+0x4c/0x168 (unreliable) [dec65ba0] [c00d4ec8] check_bytes_and_report+0xe4/0x11c [dec65bd0] [c00d507c] check_object+0x17c/0x23c [dec65bf0] [c0550a00] free_debug_processing+0xf4/0x294 [dec65c20] [c0550bdc] __slab_free+0x3c/0x294 [dec65c80] [c03f0744] ahash_setkey+0x4e0/0x594 [dec65cd0] [c01ef138] test_hash+0x260/0x5a0 [dec65e50] [c01ef4c0] alg_test_hash+0x48/0xb0 [dec65e70] [c01eecc4] alg_test+0x84/0x228 [dec65ee0] [c01ec640] cryptomgr_test+0x4c/0x54 [dec65ef0] [c005adc0] kthread+0x98/0x9c [dec65f40] [c000e1ac] ret_from_kernel_thread+0x64/0x6c FIX dma-kmalloc-32: Restoring 0xdec5dec0-0xdec5dec3=0xcc Change-Id: I0c7a1048053e811025d1c3b487940f87345c8f5d Signed-off-by: Vakul Garg Reviewed-by: Geanta Neag Horia Ioan-B05471 Reviewed-by: Fleming Andrew-AFLEMING Tested-by: Fleming Andrew-AFLEMING Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit a4208aa227113be2e0ea81613c4f15d3bc2fc768 Author: Dan Carpenter Date: Fri Jul 12 09:39:03 2013 +0300 svcrdma: underflow issue in decode_write_list() commit b2781e1021525649c0b33fffd005ef219da33926 upstream. My static checker marks everything from ntohl() as untrusted and it complains we could have an underflow problem doing: return (u32 *)&ary->wc_array[nchunks]; Also on 32 bit systems the upper bound check could overflow. Signed-off-by: Dan Carpenter Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 2794edb180b726d9d8aedcc6c7034e2d877489fc Author: Tejun Heo Date: Mon Jul 22 16:53:36 2013 -0400 libata: make it clear that sata_inic162x is experimental commit bb9696192826a7d9279caf872e95b41bc26c7eff upstream. sata_inic162x never reached a state where it's reliable enough for production use and data corruption is a relatively common occurrence. Make the driver generate warning about the issues and mark the Kconfig option as experimental. If the situation doesn't improve, we'd be better off making it depend on CONFIG_BROKEN. Let's wait for several cycles and see if the kernel message draws any attention. Signed-off-by: Tejun Heo Reported-by: Martin Braure de Calignon Reported-by: Ben Hutchings Reported-by: risc4all@yahoo.com Signed-off-by: Greg Kroah-Hartman commit b1cd27dc900443c2f40abe30d7c97c153b5e3e7d Author: Youquan Song Date: Thu Jul 11 21:15:57 2013 -0400 ata: Fix DVD not dectected at some platform with Wellsburg PCH commit eac27f04a71e1f39f196f7e520d16dcefc955d77 upstream. There is a patch b55f84e2d527182e7c611d466cd0bb6ddce201de "ata_piix: Fix DVD not dectected at some Haswell platforms" to fix an issue of DVD not recognized on Haswell Desktop platform with Lynx Point. Recently, it is also found the same issue at some platformas with Wellsburg PCH. So deliver a similar patch to fix it by disables 32bit PIO in IDE mode. Signed-off-by: Youquan Song Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 5a4de615144fd87589783402cab3ecbc29865fc8 Author: NeilBrown Date: Wed Jul 24 15:37:42 2013 +1000 md/raid10: remove use-after-free bug. commit 0eb25bb027a100f5a9df8991f2f628e7d851bc1e upstream. We always need to be careful when calling generic_make_request, as it can start a chain of events which might free something that we are using. Here is one place I wasn't careful enough. If the wbio2 is not in use, then it might get freed at the first generic_make_request call. So perform all necessary tests first. This bug was introduced in 3.3-rc3 (24afd80d99) and can cause an oops, so fix is suitable for any -stable since then. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit c1dadcc1086bbbac1b5eeb4d5e157c76f2d8dfba Author: NeilBrown Date: Mon Jul 22 12:57:21 2013 +1000 md/raid5: fix interaction of 'replace' and 'recovery'. commit f94c0b6658c7edea8bc19d13be321e3860a3fa54 upstream. If a device in a RAID4/5/6 is being replaced while another is being recovered, then the writes to the replacement device currently don't happen, resulting in corruption when the replacement completes and the new drive takes over. This is because the replacement writes are only triggered when 's.replacing' is set and not when the similar 's.sync' is set (which is the case during resync and recovery - it means all devices need to be read). So schedule those writes when s.replacing is set as well. In this case we cannot use "STRIPE_INSYNC" to record that the replacement has happened as that is needed for recording that any parity calculation is complete. So introduce STRIPE_REPLACED to record if the replacement has happened. For safety we should also check that STRIPE_COMPUTE_RUN is not set. This has a similar effect to the "s.locked == 0" test. The latter ensure that now IO has been flagged but not started. The former checks if any parity calculation has been flagged by not started. We must wait for both of these to complete before triggering the 'replace'. Add a similar test to the subsequent check for "are we finished yet". This possibly isn't needed (is subsumed in the STRIPE_INSYNC test), but it makes it more obvious that the REPLACE will happen before we think we are finished. Finally if a NeedReplace device is not UPTODATE then that is an error. We really must trigger a warning. This bug was introduced in commit 9a3e1101b827a59ac9036a672f5fa8d5279d0fe2 (md/raid5: detect and handle replacements during recovery.) which introduced replacement for raid5. That was in 3.3-rc3, so any stable kernel since then would benefit from this fix. Reported-by: qindehua <13691222965@163.com> Tested-by: qindehua Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 8afb90da9f16abc5e577318544419bfcf3565391 Author: NeilBrown Date: Wed Jul 17 15:19:29 2013 +1000 md/raid1: fix bio handling problems in process_checks() commit 30bc9b53878a9921b02e3b5bc4283ac1c6de102a upstream. Recent change to use bio_copy_data() in raid1 when repairing an array is faulty. The underlying may have changed the bio in various ways using bio_advance and these need to be undone not just for the 'sbio' which is being copied to, but also the 'pbio' (primary) which is being copied from. So perform the reset on all bios that were read from and do it early. This also ensure that the sbio->bi_io_vec[j].bv_len passed to memcmp is correct. This fixes a crash during a 'check' of a RAID1 array. The crash was introduced in 3.10 so this is suitable for 3.10-stable. Reported-by: Joe Lawrence Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 1d83ab8548ff19bad94dcae62ba13ea476974e7f Author: NeilBrown Date: Wed Jul 17 14:55:31 2013 +1000 md: Remove recent change which allows devices to skip recovery. commit 5024c298311f3b97c85cb034f9edaa333fdb9338 upstream. commit 7ceb17e87bde79d285a8b988cfed9eaeebe60b86 md: Allow devices to be re-added to a read-only array. allowed a bit more than just that. It also allows devices to be added to a read-write array and to end up skipping recovery. This patch removes the offending piece of code pending a rewrite for a subsequent release. More specifically: If the array has a bitmap, then the device will still need a bitmap based resync ('saved_raid_disk' is set under different conditions is a bitmap is present). If the array doesn't have a bitmap, then this is correct as long as nothing has been written to the array since the metadata was checked by ->validate_super. However there is no locking to ensure that there was no write. Bug was introduced in 3.10 and causes data corruption so patch is suitable for 3.10-stable. Reported-by: Joe Lawrence Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 943741e352f8b0c524f542b93e8b62978dc0a9b0 Author: Kees Cook Date: Mon Jul 15 11:50:45 2013 -0700 x86: make sure IDT is page aligned based on 4df05f361937ee86e5a8c9ead8aeb6a19ea9b7d7 upstream. Since the IDT is referenced from a fixmap, make sure it is page aligned. This avoids the risk of the IDT ever being moved in the bss and having the mapping be offset, resulting in calling incorrect handlers. In the current upstream kernel this is not a manifested bug, but heavily patched kernels (such as those using the PaX patch series) did encounter this bug. Signed-off-by: Kees Cook Reported-by: PaX Team Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Yinghai Lu Cc: Seiji Aguchi Cc: Fenghua Yu Signed-off-by: Greg Kroah-Hartman commit 6d7d28443969512be95873d2fb155f4be9261ca5 Author: H. Peter Anvin Date: Fri Jul 12 16:48:12 2013 -0700 x86, suspend: Handle CPUs which fail to #GP on RDMSR commit 5ff560fd48d5b3d82fa0c3aff625c9da1a301911 upstream. There are CPUs which have errata causing RDMSR of a nonexistent MSR to not fault. We would then try to WRMSR to restore the value of that MSR, causing a crash. Specifically, some Pentium M variants would have this problem trying to save and restore the non-existent EFER, causing a crash on resume. Work around this by making sure we can write back the result at suspend time. Huge thanks to Christian Sünkenberg for finding the offending erratum that finally deciphered the mystery. Reported-and-tested-by: Johan Heinrich Debugged-by: Christian Sünkenberg Acked-by: Rafael J. Wysocki Link: http://lkml.kernel.org/r/51DDC972.3010005@student.kit.edu Signed-off-by: Greg Kroah-Hartman commit 07221c8c2109ae56d9f83cd0644498069ed7cfed Author: Konrad Rzeszutek Wilk Date: Wed Jan 16 11:33:52 2013 -0500 xen/blkback: Check device permissions before allowing OP_DISCARD commit 604c499cbbcc3d5fe5fb8d53306aa0fae1990109 upstream. We need to make sure that the device is not RO or that the request is not past the number of sectors we want to issue the DISCARD operation for. This fixes CVE-2013-2140. Acked-by: Jan Beulich Acked-by: Ian Campbell [v1: Made it pr_warn instead of pr_debug] Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit f4b5b99f18cd5984120ab2334aeadc5384f260cf Author: Jan Beulich Date: Wed Jul 17 08:09:37 2013 +0100 xen-netfront: pull on receive skb may need to happen earlier commit 093b9c71b6e450e375f4646ba86faed0195ec7df upstream. Due to commit 3683243b ("xen-netfront: use __pskb_pull_tail to ensure linear area is big enough on RX") xennet_fill_frags() may end up filling MAX_SKB_FRAGS + 1 fragments in a receive skb, and only reduce the fragment count subsequently via __pskb_pull_tail(). That's a result of xennet_get_responses() allowing a maximum of one more slot to be consumed (and intermediately transformed into a fragment) if the head slot has a size less than or equal to RX_COPY_THRESHOLD. Hence we need to adjust xennet_fill_frags() to pull earlier if we reached the maximum fragment count - due to the described behavior of xennet_get_responses() this guarantees that at least the first fragment will get completely consumed, and hence the fragment count reduced. In order to not needlessly call __pskb_pull_tail() twice, make the original call conditional upon the pull target not having been reached yet, and defer the newly added one as much as possible (an alternative would have been to always call the function right before the call to xennet_fill_frags(), but that would imply more frequent cases of needing to call it twice). Signed-off-by: Jan Beulich Acked-by: Wei Liu Cc: Ian Campbell Acked-by: Ian Campbell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0183a8ee8c5621a84b0e4ba0b627af73f563e37c Author: Josef Bacik Date: Wed Jul 17 19:30:20 2013 -0400 Btrfs: re-add root to dead root list if we stop dropping it commit d29a9f629e009c9b90e5859bce581070fd6247fc upstream. If we stop dropping a root for whatever reason we need to add it back to the dead root list so that we will re-start the dropping next transaction commit. The other case this happens is if we recover a drop because we will add a root without adding it to the fs radix tree, so we can leak it's root and commit root extent buffer, adding this to the dead root list makes this cleanup happen. Thanks, Reported-by: Alex Lyakas Signed-off-by: Josef Bacik Signed-off-by: Greg Kroah-Hartman commit 14e86565899d123a994d974560624b617d855ca8 Author: Josef Bacik Date: Mon Jul 15 12:41:42 2013 -0400 Btrfs: fix lock leak when resuming snapshot deletion commit fec386ac1428f9c0e672df952cbca5cebd4e4e2f upstream. We aren't setting path->locks[level] when we resume a snapshot deletion which means we won't unlock the buffer when we free the path. This causes deadlocks if we happen to re-allocate the block before we've evicted the extent buffer from cache. Thanks, Reported-by: Alex Lyakas Signed-off-by: Josef Bacik Signed-off-by: Greg Kroah-Hartman commit db60e49ae570b342d63f0bbda4d35b85a392da25 Author: Stefan Behrens Date: Thu Jul 4 16:14:23 2013 +0200 Btrfs: fix wrong write offset when replacing a device commit 115930cb2d444a684975cf2325759cb48ebf80cc upstream. Miao Xie reported the following issue: The filesystem was corrupted after we did a device replace. Steps to reproduce: # mkfs.btrfs -f -m single -d raid10 .. # mount # btrfs replace start -rfB 1 # umount # btrfsck The reason for the issue is that we changed the write offset by mistake, introduced by commit 625f1c8dc. We read the data from the source device at first, and then write the data into the corresponding place of the new device. In order to implement the "-r" option, the source location is remapped using btrfs_map_block(). The read takes place on the mapped location, and the write needs to take place on the unmapped location. Currently the write is using the mapped location, and this commit changes it back by undoing the change to the write address that the aforementioned commit added by mistake. Reported-by: Miao Xie Signed-off-by: Stefan Behrens Signed-off-by: Josef Bacik Signed-off-by: Greg Kroah-Hartman commit cb631ac7738411616e461ae43af9b6d4cb9d29d4 Author: Dirk Brandewie Date: Thu Jul 18 08:48:42 2013 -0700 cpufreq / intel_pstate: Change to scale off of max P-state commit 2134ed4d614349b2b4e8d7bb593baa9179b8dd1e upstream. Change to using max P-state instead of max turbo P-state. This change resolves two issues. On a quiet system intel_pstate can fail to respond to a load change. On CPU SKUs that have a limited number of P-states and no turbo range intel_pstate fails to select the highest available P-state. This change is suitable for stable v3.9+ References: https://bugzilla.kernel.org/show_bug.cgi?id=59481 Reported-and-tested-by: Arjan van de Ven Reported-and-tested-by: dsmythies@telus.net Signed-off-by: Dirk Brandewie Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit dbc31d4e7958e7539180b9f2d7c8446e4a0429d4 Author: Karlis Ogsts Date: Mon Jul 22 13:51:42 2013 -0700 staging: android: logger: Correct write offset reset on error commit 72bb99cfe9c57d2044445fb34bbc95b4c0bae6f2 upstream. In the situation that a writer fails to copy data from userspace it will reset the write offset to the value it had before it went to sleep. This discarding any messages written while aquiring the mutex. Therefore the reset offset needs to be retrieved after acquiring the mutex. Cc: Android Kernel Team Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 867ea7111553d42d7a1545d1c69998a1a53b3166 Author: Ian Abbott Date: Mon Jul 8 13:36:19 2013 +0100 staging: comedi: COMEDI_CANCEL ioctl should wake up read/write commit 69acbaac303e8cb948801a9ddd0ac24e86cc4a1b upstream. Comedi devices can do blocking read() or write() (or poll()) if an asynchronous command has been set up, blocking for data (for read()) or buffer space (for write()). Various events associated with the asynchronous command will wake up the blocked reader or writer (or poller). It is also possible to force the asynchronous command to terminate by issuing a `COMEDI_CANCEL` ioctl. That shuts down the asynchronous command, but does not currently wake up the blocked reader or writer (or poller). If the blocked task could be woken up, it would see that the command is no longer active and return. The caller of the `COMEDI_CANCEL` ioctl could attempt to wake up the blocked task by sending a signal, but that's a nasty workaround. Change `do_cancel_ioctl()` to wake up the wait queue after it returns from `do_cancel()`. `do_cancel()` can propagate an error return value from the low-level comedi driver's cancel routine, but it always shuts the command down regardless, so `do_cancel_ioctl()` can wake up he wait queue regardless of the return value from `do_cancel()`. Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit 2578ae7c4bbb8528caa3ea835c7451868b4f8607 Author: Ian Abbott Date: Fri Jul 5 16:49:34 2013 +0100 staging: comedi: fix a race between do_cmd_ioctl() and read/write commit 4b18f08be01a7b3c7b6df497137b6e3cb28adaa3 upstream. `do_cmd_ioctl()` is called with the comedi device's mutex locked to process the `COMEDI_CMD` ioctl to set up comedi's asynchronous command handling on a comedi subdevice. `comedi_read()` and `comedi_write()` are the `read` and `write` handlers for the comedi device, but do not lock the mutex (for performance reasons, as some things can hold the mutex for quite a long time). There is a race condition if `comedi_read()` or `comedi_write()` is running at the same time and for the same file object and comedi subdevice as `do_cmd_ioctl()`. `do_cmd_ioctl()` sets the subdevice's `busy` pointer to the file object way before it sets the `SRF_RUNNING` flag in the subdevice's `runflags` member. `comedi_read() and `comedi_write()` check the subdevice's `busy` pointer is pointing to the current file object, then if the `SRF_RUNNING` flag is not set, will call `do_become_nonbusy()` to shut down the asyncronous command. Bad things can happen if the asynchronous command is being shutdown and set up at the same time. To prevent the race, don't set the `busy` pointer until after the `SRF_RUNNING` flag has been set. Also, make sure the mutex is held in `comedi_read()` and `comedi_write()` while calling `do_become_nonbusy()` in order to avoid moving the race condition to a point within that function. Change some error handling `goto cleanup` statements in `do_cmd_ioctl()` to simple `return -ERRFOO` statements as a result of changing when the `busy` pointer is set. Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman commit 5deba4cf6db86cc902526d8b08fc5d56e9d43994 Author: Alan Stern Date: Thu Jul 11 14:58:04 2013 -0400 USB: global suspend and remote wakeup don't mix commit e583d9db9960cf40e0bc8afee4946baa9d71596e upstream. The hub driver was recently changed to use "global" suspend for system suspend transitions on non-SuperSpeed buses. This means that we don't suspend devices individually by setting the suspend feature on the upstream hub port; instead devices all go into suspend automatically when the root hub stops transmitting packets. The idea was to save time and to avoid certain kinds of wakeup races. Now it turns out that many hubs are buggy; they don't relay wakeup requests from a downstream port to their upstream port if the downstream port's suspend feature is not set (depending on the speed of the downstream port, whether or not the hub is enabled for remote wakeup, and possibly other factors). We can't have hubs dropping wakeup requests. Therefore this patch goes partway back to the old policy: It sets the suspend feature for a port if the device attached to that port or any of its descendants is enabled for wakeup. People will still be able to benefit from the time savings if they don't care about wakeup and leave it disabled on all their devices. In order to accomplish this, the patch adds a new field to the usb_hub structure: wakeup_enabled_descendants is a count of how many devices below a suspended hub are enabled for remote wakeup. A corresponding new subroutine determines the number of wakeup-enabled devices at or below an arbitrary suspended USB device. This should be applied to the 3.10 stable kernel. Signed-off-by: Alan Stern Reported-and-tested-by: Toralf Förster Signed-off-by: Greg Kroah-Hartman commit 889ba7bc28e5db5da40f648c91678dcc2d2837fd Author: William Gulland Date: Thu Jun 27 16:10:20 2013 -0700 usb: Clear both buffers when clearing a control transfer TT buffer. commit 2c7b871b9102c497ba8f972aa5d38532f05b654d upstream. Control transfers have both IN and OUT (or SETUP) packets, so when clearing TT buffers for a control transfer it's necessary to send two HUB_CLEAR_TT_BUFFER requests to the hub. Signed-off-by: William Gulland Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 909dccf772418ade21930910ab71327552049982 Author: Jóhann B. Guðmundsson Date: Thu Jul 4 21:47:52 2013 +0000 USB: misc: Add Manhattan Hi-Speed USB DVI Converter to sisusbvga commit 58fc90db8261b571c026bb8bf23aad48a7233118 upstream. Signed-off-by: Jóhann B. Guðmundsson Signed-off-by: Greg Kroah-Hartman commit 592bafa7e0741a4f211e61d5043f16cf59d0023c Author: Johan Hovold Date: Fri Jun 28 12:24:26 2013 +0200 USB: ti_usb_3410_5052: fix dynamic-id matching commit 1fad56424f5ad3ce4973505a357212b2e2282b3f upstream. The driver failed to take the dynamic ids into account when determining the device type and therefore all devices were detected as 2-port devices when using the dynamic-id interface. Match on the usb-serial-driver field instead of doing redundant id-table searches. Reported-by: Anders Hammarquist Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 003dda8a8dedc8a2e90f33fd0745b9529afdf161 Author: Felipe Balbi Date: Mon Jul 15 12:36:35 2013 +0300 usb: dwc3: gadget: don't prevent gadget from being probed if we fail commit cdcedd6981194e511cc206887db661d016069d68 upstream. In case we fail our ->udc_start() callback, we should be ready to accept another modprobe following the failed one. We had forgotten to clear dwc->gadget_driver back to NULL and, because of that, we were preventing gadget driver modprobe from being retried. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 41557736ac4acc112a1884177f62716c57852ddc Author: Huang Rui Date: Thu Jun 27 01:08:11 2013 +0800 usb: dwc3: fix wrong bit mask in dwc3_event_type commit 1974d494dea05ea227cb42f5e918828801e237aa upstream. Per dwc3 2.50a spec, the is_devspec bit is used to distinguish the Device Endpoint-Specific Event or Device-Specific Event (DEVT). If the bit is 1, the event is represented Device-Specific Event, then use [7:1] bits as Device Specific Event to marked the type. It has 7 bits, and we can see the reserved8_31 variable name which means from 8 to 31 bits marked reserved, actually there are 24 bits not 25 bits between that. And 1 + 7 + 24 = 32, the event size is 4 byes. So in dwc3_event_type, the bit mask should be: is_devspec [0] 1 bit type [7:1] 7 bits reserved8_31 [31:8] 24 bits This patch should be backported to kernels as old as 3.2, that contain the commit 72246da40f3719af3bfd104a2365b32537c27d83 "usb: Introduce DesignWare USB3 DRD Driver". Signed-off-by: Huang Rui Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit a53338faf612c0f3c0c4031b6844963540979ac4 Author: Ruchika Kharwar Date: Thu Jul 4 00:59:34 2013 -0500 usb: dwc3: fix the error returned with usb3_phy failure commit 315955d707b50c8aad20a32ec0dd4c9fe243cabe upstream. When there is an error with the usb3_phy probe or absence, the error returned is erroneously for usb2_phy. Signed-off-by: Ruchika Kharwar Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit d3fe9f67d94aaba648a3df948750658059340cde Author: Johan Hovold Date: Mon Jul 1 14:03:33 2013 +0200 USB: mos7840: fix memory leak in open commit 5f8a2e68b679b41cc8e9b642f2f5aa45dd678641 upstream. Allocated urbs and buffers were never freed on errors in open. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit c65b5f6ade7209fc5eda9f0779de4ee254a6bb78 Author: Roger Quadros Date: Tue Jul 9 17:03:50 2013 +0300 USB: EHCI: Fix resume signalling on remote wakeup commit 47a64a13d54f6c669b00542848d5550be3d3310e upstream. Set the ehci->resuming flag for the port we receive a remote wakeup on so that resume signalling can be completed. Without this, the root hub timer will not fire again to check if the resume was completed and there will be a never-ending wait on on the port. This effect is only observed if the HUB IRQ IN does not come after we have initiated the port resume. Signed-off-by: Roger Quadros Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 5dbb5d4f24bf6862a888637b7506d1e04c2d2276 Author: Sarah Sharp Date: Wed Jul 24 10:27:13 2013 -0700 xhci: Avoid NULL pointer deref when host dies. commit 203a86613fb3bf2767335659513fa98563a3eb71 upstream. When the host controller fails to respond to an Enable Slot command, and the host fails to respond to the register write to abort the command ring, the xHCI driver will assume the host is dead, and call usb_hc_died(). The USB device's slot_id is still set to zero, and the pointer stored at xhci->devs[0] will always be NULL. The call to xhci_check_args in xhci_free_dev should have caught the NULL virt_dev pointer. However, xhci_free_dev is designed to free the xhci_virt_device structures, even if the host is dead, so that we don't leak kernel memory. xhci_free_dev checks the return value from the generic xhci_check_args function. If the return value is -ENODEV, it carries on trying to free the virtual device. The issue is that xhci_check_args looks at the host controller state before it looks at the xhci_virt_device pointer. It will return -ENIVAL because the host is dead, and xhci_free_dev will ignore the return value, and happily dereference the NULL xhci_virt_device pointer. The fix is to make sure that xhci_check_args checks the xhci_virt_device pointer before it checks the host state. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203453 for further details. This patch doesn't solve the underlying issue, but will ensure we don't see any more NULL pointer dereferences because of the issue. This patch should be backported to kernels as old as 3.1, that contain the commit 7bd89b4017f46a9b92853940fd9771319acb578a "xhci: Don't submit commands or URBs to halted hosts." Signed-off-by: Sarah Sharp Reported-by: Vincent Thiele Signed-off-by: Greg Kroah-Hartman commit 10a1c13241f682cdc866f2aa8a0e5c5373470ecb Author: Oleksij Rempel Date: Sun Jul 21 15:36:19 2013 +0200 xhci: fix null pointer dereference on ring_doorbell_for_active_rings commit d66eaf9f89502971fddcb0de550b01fa6f409d83 upstream. in some cases where device is attched to xhci port and do not responding, for example ath9k_htc with stalled firmware, kernel will crash on ring_doorbell_for_active_rings. This patch check if pointer exist before it is used. This patch should be backported to kernels as old as 2.6.35, that contain the commit e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 "USB: xhci: Correct assumptions about number of rings per endpoint" Signed-off-by: Oleksij Rempel Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit a875d82eda58712d81caf78ebb515fb072187138 Author: George Cherian Date: Mon Jul 1 10:59:12 2013 +0530 usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0 commit 07f3cb7c28bf3f4dd80bfb136cf45810c46ac474 upstream. Xhci controllers with hci_version > 0.96 gives spurious success events on short packet completion. During webcam capture the "ERROR Transfer event TRB DMA ptr not part of current TD" was observed. The same application works fine with synopsis controllers hci_version 0.96. The same issue is seen with Intel Pantherpoint xhci controller. So enabling this quirk in xhci_gen_setup if controller verion is greater than 0.96. For xhci-pci move the quirk to much generic place xhci_gen_setup. Note from Sarah: The xHCI 1.0 spec changed how hardware handles short packets. The HW will notify SW of the TRB where the short packet occurred, and it will also give a successful status for the last TRB in a TD (the one with the IOC flag set). On the second successful status, that warning will be triggered in the driver. Software is now supposed to not assume the TD is not completed until it gets that last successful status. That means we have a slight race condition, although it should have little practical impact. This patch papers over that issue. It's on my long-term to-do list to fix this race condition, but it is a much more involved patch that will probably be too big for stable. This patch is needed for stable to avoid serious log spam. This patch should be backported to kernels as old as 3.0, that contain the commit ad808333d8201d53075a11bc8dd83b81f3d68f0b "Intel xhci: Ignore spurious successful event." The patch will have to be modified for kernels older than 3.2, since that kernel added the xhci_gen_setup function for xhci platform devices. The correct conflict resolution for kernels older than 3.2 is to set XHCI_SPURIOUS_SUCCESS in xhci_pci_quirks for all xHCI 1.0 hosts. Signed-off-by: George Cherian Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit c62771c88704f0814d0fead60eadc0397a5e832f Author: Steven Rostedt (Red Hat) Date: Tue Jul 23 22:21:59 2013 -0400 tracing: Remove locking trace_types_lock from tracing_reset_all_online_cpus() commit 09d8091c024ec88d1541d93eb8ddb2bd5cf10c39 upstream. Commit a82274151af "tracing: Protect ftrace_trace_arrays list in trace_events.c" added taking the trace_types_lock mutex in trace_events.c as there were several locations that needed it for protection. Unfortunately, it also encapsulated a call to tracing_reset_all_online_cpus() which also takes the trace_types_lock, causing a deadlock. This happens when a module has tracepoints and has been traced. When the module is removed, the trace events module notifier will grab the trace_types_lock, do a bunch of clean ups, and also clears the buffer by calling tracing_reset_all_online_cpus. This doesn't happen often which explains why it wasn't caught right away. Commit a82274151af was marked for stable, which means this must be sent to stable too. Link: http://lkml.kernel.org/r/51EEC646.7070306@broadcom.com Reported-by: Arend van Spril Tested-by: Arend van Spriel Cc: Alexander Z Lam Cc: Vaibhav Nagarnaik Cc: David Sharp Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit e55679914313bbfc003dcdf8ff74a16dec2fe24d Author: Oleg Nesterov Date: Fri Jul 19 17:36:44 2013 +0200 tracing: Kill the unbalanced tr->ref++ in tracing_buffers_open() commit e70e78e3c83b536730e31231dd9b979768d8df3c upstream. tracing_buffers_open() does trace_array_get() and then it wrongly inrcements tr->ref again under trace_types_lock. This means that every caller leaks trace_array: # cd /sys/kernel/debug/tracing/ # mkdir instances/X # true < instances/X/per_cpu/cpu0/trace_pipe_raw # rmdir instances/X rmdir: failed to remove `instances/X': Device or resource busy Link: http://lkml.kernel.org/r/20130719153644.GA18899@redhat.com Signed-off-by: Oleg Nesterov Cc: Ingo Molnar Cc: Frederic Weisbecker Cc: Masami Hiramatsu Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit e45ccd09b53e4cd60941891ad6992579ebc78024 Author: Alexander Z Lam Date: Thu Jul 18 11:18:44 2013 -0700 tracing: Miscellaneous fixes for trace_array ref counting commit f77d09a384676bde6445413949d9d2c508ff3e62 upstream. Some error paths did not handle ref counting properly, and some trace files need ref counting. Link: http://lkml.kernel.org/r/1374171524-11948-1-git-send-email-azl@google.com Signed-off-by: Alexander Z Lam Cc: Vaibhav Nagarnaik Cc: David Sharp Cc: Alexander Z Lam Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit a33eb1f5e1ae58418d9853c794a40d340605d752 Author: Alexander Z Lam Date: Wed Jul 10 17:34:34 2013 -0700 tracing: Fix error handling to ensure instances can always be removed commit 609e85a70bcd0eedf4ec60639dbcfb1ab011e054 upstream. Remove debugfs directories for tracing instances during creation if an error occurs causing the trace_array for that instance to not be added to ftrace_trace_arrays. If the directory continues to exist after the error, it cannot be removed because the respective trace_array is not in ftrace_trace_arrays. Link: http://lkml.kernel.org/r/1373502874-1706-2-git-send-email-azl@google.com Signed-off-by: Alexander Z Lam Cc: Vaibhav Nagarnaik Cc: David Sharp Cc: Alexander Z Lam Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 25ef812609dbc1a3db74f0f5912c94afdfd65d31 Author: Saurav Kashyap Date: Fri Jul 12 14:47:51 2013 -0400 SCSI: qla2xxx: Properly set the tagging for commands. commit c3ccb1d7cf4c4549151876dd37c0944a682fd9e1 upstream. This fixes a regression where Xyratex controllers and disks were lost by the driver: https://bugzilla.kernel.org/show_bug.cgi?id=59601 Reported-by: Jack Hill Signed-off-by: Saurav Kashyap Signed-off-by: Giridhar Malavali Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 8cf7b0b08a0bccbf3a72487b3b85ac233e83947f Author: Ewan D. Milne Date: Fri Nov 2 09:38:34 2012 -0400 SCSI: sd: fix crash when UA received on DIF enabled device commit 085b513f97d8d799d28491239be4b451bcd8c2c5 upstream. sd_prep_fn will allocate a larger CDB for the command via mempool_alloc for devices using DIF type 2 protection. This CDB was being freed in sd_done, which results in a kernel crash if the command is retried due to a UNIT ATTENTION. This change moves the code to free the larger CDB into sd_unprep_fn instead, which is invoked after the request is complete. It is no longer necessary to call scsi_print_command separately for this case as the ->cmnd will no longer be NULL in the normal code path. Also removed conditional test for DIF type 2 when freeing the larger CDB because the protection_type could have been changed via sysfs while the command was executing. Signed-off-by: Ewan D. Milne Acked-by: Martin K. Petersen Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit b01c4c2c2e5b7ecf14e10efabf65183d9565ff2f Author: Jeff Skirvin Date: Thu Jul 11 17:18:58 2013 -0700 SCSI: isci: Fix a race condition in the SSP task management path commit 96f15f29038e58e1b0a96483e2b369ff446becf1 upstream. This commit fixes a race condition in the isci driver abort task and SSP device task management path. The race is caused when an I/O termination in the SCU hardware is necessary because of an SSP target timeout condition, and the check of the I/O end state races against the HW-termination-driven end state. The failure of the race meant that no TMF was sent to the device to clean-up the pending I/O. Signed-off-by: Jeff Skirvin Reviewed-by: Lukasz Dorau Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 7ca674af75d75aa6755746327f1fd3222e54b338 Author: Gregory CLEMENT Date: Wed May 15 09:39:17 2013 +0100 ARM: 7722/1: zImage: Convert 32bits memory size and address from ATAG to 64bits DTB commit faefd550c45d8d314e8f260f21565320355c947f upstream. When CONFIG_ARM_APPENDED_DTB is selected, if the bootloader provides an ATAG_MEM it replaces the memory size and the memory address in the memory node of the device tree. In the case of a system which can handle more than 4GB, the memory node cell size is 4: each data (memory size and memory address) are 64 bits and then use 2 cells. The current code in atags_to_fdt.c made the assumption of a cell size of 2 (one cell for the memory size and one cell for the memory address), this leads to an improper write of the data and ends with a boot hang. This patch writes the memory size and the memory address on the memory node in the device tree depending of the size of the memory node (32 bits or 64 bits). It has been tested in the 2 cases: - with a dtb using skeleton.dtsi - and with a dtb using skeleton64.dtsi Signed-off-by: Gregory CLEMENT Acked-by: Nicolas Pitre Signed-off-by: Russell King Cc: Willy Tarreau Signed-off-by: Greg Kroah-Hartman commit e1e97450a25d46c665a634f5073f9555236b7b0b Author: Nicolin Chen Date: Fri Jun 14 12:34:50 2013 +0800 ASoC: wm8962: Remove remaining direct register cache accesses commit 2e7ee15ced914e109a1a5b6dfcd463d846a13bd5 upstream. Also fix return values for headphone switch updates. Signed-off-by: Nicolin Chen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit bceb4eb2756a33f87dfb0b86bd01f2af4b4b81ac Author: Richard Zhao Date: Sun Jul 21 10:34:09 2013 +0800 ASoC: tegra: correct playback_dma_data setup commit 647ab784c507763bfda79155f125b6edd1244806 upstream. The errors were caused by copy/paste mistake in below commit since v3.10: 3489d50 ASoC: tegra: Use common DAI DMA data struct It also corrects slave_id initialization in tegra20_ac97 driver. Signed-off-by: Richard Zhao Acked-by: Stephen Warren Acked-by: Lucas Stach Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit f7fce059bfbbf82f4889d367086402e81a79496b Author: Chih-Chung Chang Date: Mon Jul 15 09:38:46 2013 -0700 ASoC: max98088 - fix element type of the register cache. commit cb6f66a2d278e57a6c9d8fb59bd9ebd8ab3965c2 upstream. The registers of max98088 are 8 bits, not 16 bits. This bug causes the contents of registers to be overwritten with bad values when the codec is suspended and then resumed. Signed-off-by: Chih-Chung Chang Signed-off-by: Dylan Reid Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ed44e4d734910894c6d822d5dfbbb800fa2238ba Author: Fabio Estevam Date: Thu Jul 4 20:01:02 2013 -0300 ASoC: sglt5000: Fix the default value of CHIP_SSS_CTRL commit 016fcab8ff46fca29375d484226ec91932aa4a07 upstream. According to the sgtl5000 reference manual, the default value of CHIP_SSS_CTRL is 0x10. Reported-by: Oskar Schirmer Signed-off-by: Fabio Estevam Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit f8c974f6fbdef40d37f957292f3238552a8d3598 Author: Clemens Ladisch Date: Mon Jul 22 21:32:09 2013 +0200 firewire: fix libdc1394/FlyCap2 iso event regression commit 0699a73af3811b66b1ab5650575acee5eea841ab upstream. Commit 18d627113b83 (firewire: prevent dropping of completed iso packet header data) was intended to be an obvious bug fix, but libdc1394 and FlyCap2 depend on the old behaviour by ignoring all returned information and thus not noticing that not all packets have been received yet. The result was that the video frame buffers would be saved before they contained the correct data. Reintroduce the old behaviour for old clients. Tested-by: Stepan Salenikovich Tested-by: Josep Bosch Signed-off-by: Clemens Ladisch Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman commit 6d2c6593cf6592707c68e95f43982adbe573c6ac Author: David Henningsson Date: Fri Jun 28 11:09:56 2013 +0200 ALSA: hda - Guess what, it's two more Dell headset mic quirks commit cd6fb6793a33e2b02af6e05a8d3f735f7c88a943 upstream. Add two more machines that need quirks for headset mics to work. Tested-by: Shawn Wang BugLink: https://bugs.launchpad.net/bugs/1195636 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 49a845673d47cddd320ba9bd0d746c071d5ad39a Author: David Henningsson Date: Fri Jun 28 08:53:34 2013 +0200 ALSA: hda - Yet another Dell headset mic quirk commit 6c29d68a82ec68db18241b818d03e7864c052be9 upstream. This quirk is needed for the headset mic to work on this Dell machine. BugLink: https://bugs.launchpad.net/bugs/1195597 Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e1d2c40df6b0caed73187254e7be9af87cc98850 Author: Ren Bigcren Date: Tue Jul 2 13:34:30 2013 +0200 USB: storage: Add MicroVault Flash Drive to unusual_devs commit e7a6121f4929c17215f0cdca3726f4bf3e4e9529 upstream. The device report an error capacity when read_capacity_16(). Using read_capacity_10() can get the correct capacity. Signed-off-by: Ren Bigcren Cc: Matthew Dharm Signed-off-by: Oskar Andero Signed-off-by: Greg Kroah-Hartman commit c6ccbb9b6e24e35d71fd8706dfc5a8eab07f6937 Author: Nicholas Bellinger Date: Wed Jul 3 03:11:48 2013 -0700 iscsi-target: Fix ISCSI_OP_SCSI_TMFUNC handling for iser commit 186a9647019587b3784694894c4d136fd00cfd7b upstream. This patch adds target_get_sess_cmd reference counting for iscsit_handle_task_mgt_cmd(), and adds a target_put_sess_cmd() for the failure case. It also fixes a bug where ISCSI_OP_SCSI_TMFUNC type commands where leaking iscsi_cmd->i_conn_node and eventually triggering an OOPs during struct isert_conn shutdown. Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit d9e507c05ca19ad2ec166577edd8b47e17c8961e Author: Nicholas Bellinger Date: Wed Jul 3 03:05:37 2013 -0700 iser-target: Fix session reset bug with RDMA_CM_EVENT_DISCONNECTED commit b2cb96494d83b894a43ba8b9023eead8ff50684b upstream. This patch addresses a bug where RDMA_CM_EVENT_DISCONNECTED may occur before the connection shutdown has been completed by rx/tx threads, that causes isert_free_conn() to wait indefinately on ->conn_wait. This patch allows isert_disconnect_work code to invoke rdma_disconnect when isert_disconnect_work() process context is started by client session reset before isert_free_conn() code has been reached. It also adds isert_conn->conn_mutex protection for ->state within isert_disconnect_work(), isert_cq_comp_err() and isert_free_conn() code, along with isert_check_state() for wait_event usage. (v2: Add explicit iscsit_cause_connection_reinstatement call during isert_disconnect_work() to force conn reset) Cc: Or Gerlitz Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit a5d56a2217664c7bc06cb7deeac9a2a155ba4345 Author: Joern Engel Date: Wed Jul 3 11:35:11 2013 -0400 iscsi-target: Fix tfc_tpg_nacl_auth_cit configfs length overflow commit 0fbfc46fb0b2f543a8b539e94c6c293ebc0b05a6 upstream. This patch fixes a potential buffer overflow while processing iscsi_node_auth input for configfs attributes within NodeACL tfc_tpg_nacl_auth_cit context. Signed-off-by: Joern Engel Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit fff98879381243f59b6e9f630d55312aa34a89c9 Author: Nicholas Bellinger Date: Wed Jun 26 02:31:42 2013 -0700 iser-target: Fix isert_put_reject payload buffer post commit 3df8f68aaf7ebe3d136a22262b41b350b0a1858b upstream. This patch adds the missing isert_put_reject() logic to post a outgoing payload buffer to hold the 48 bytes of original PDU header request payload for the rejected cmd. It also fixes ISTATE_SEND_REJECT handling in isert_response_completion() -> isert_do_control_comp() code, and drops incorrect iscsi_cmd_t->reject_comp usage. Signed-off-by: Nicholas Bellinger Cc: Or Gerlitz Cc: Mike Christie Signed-off-by: Greg Kroah-Hartman commit 78077c226f0ab20fcd0a85a8f0de42b96973382b Author: Vineet Gupta Date: Wed Jul 3 15:03:31 2013 -0700 mm: fix the TLB range flushed when __tlb_remove_page() runs out of slots commit e6c495a96ce02574e765d5140039a64c8d4e8c9e upstream. zap_pte_range loops from @addr to @end. In the middle, if it runs out of batching slots, TLB entries needs to be flushed for @start to @interim, NOT @interim to @end. Since ARC port doesn't use page free batching I can't test it myself but this seems like the right thing to do. Observed this when working on a fix for the issue at thread: http://www.spinics.net/lists/linux-arch/msg21736.html Signed-off-by: Vineet Gupta Cc: Mel Gorman Cc: Hugh Dickins Cc: Rik van Riel Cc: David Rientjes Cc: Peter Zijlstra Acked-by: Catalin Marinas Cc: Max Filippov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman