1. 04 May, 2016 12 commits
    • Mathias Nyman's avatar
      xhci: resume USB 3 roothub first · ba7aa9a9
      Mathias Nyman authored
      commit 671ffdff upstream.
      
      Give USB3 devices a better chance to enumerate at USB 3 speeds if
      they are connected to a suspended host.
      Solves an issue with NEC uPD720200 host hanging when partially
      enumerating a USB3 device as USB2 after host controller runtime resume.
      Tested-by: default avatarMike Murdoch <main.haarp@gmail.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ba7aa9a9
    • Rafal Redzimski's avatar
      usb: xhci: applying XHCI_PME_STUCK_QUIRK to Intel BXT B0 host · 6a20c0a0
      Rafal Redzimski authored
      commit 0d46faca upstream.
      
      Broxton B0 also requires XHCI_PME_STUCK_QUIRK.
      Adding PCI device ID for Broxton B and adding to quirk.
      Signed-off-by: default avatarRafal Redzimski <rafal.f.redzimski@intel.com>
      Signed-off-by: default avatarRobert Dobrowolski <robert.dobrowolski@linux.intel.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a20c0a0
    • Jerome Marchand's avatar
      assoc_array: don't call compare_object() on a node · 6905c7a4
      Jerome Marchand authored
      commit 8d4a2ec1 upstream.
      
      Changes since V1: fixed the description and added KASan warning.
      
      In assoc_array_insert_into_terminal_node(), we call the
      compare_object() method on all non-empty slots, even when they're
      not leaves, passing a pointer to an unexpected structure to
      compare_object(). Currently it causes an out-of-bound read access
      in keyring_compare_object detected by KASan (see below). The issue
      is easily reproduced with keyutils testsuite.
      Only call compare_object() when the slot is a leave.
      
      KASan warning:
      ==================================================================
      BUG: KASAN: slab-out-of-bounds in keyring_compare_object+0x213/0x240 at addr ffff880060a6f838
      Read of size 8 by task keyctl/1655
      =============================================================================
      BUG kmalloc-192 (Not tainted): kasan: bad access detected
      -----------------------------------------------------------------------------
      
      Disabling lock debugging due to kernel taint
      INFO: Allocated in assoc_array_insert+0xfd0/0x3a60 age=69 cpu=1 pid=1647
      	___slab_alloc+0x563/0x5c0
      	__slab_alloc+0x51/0x90
      	kmem_cache_alloc_trace+0x263/0x300
      	assoc_array_insert+0xfd0/0x3a60
      	__key_link_begin+0xfc/0x270
      	key_create_or_update+0x459/0xaf0
      	SyS_add_key+0x1ba/0x350
      	entry_SYSCALL_64_fastpath+0x12/0x76
      INFO: Slab 0xffffea0001829b80 objects=16 used=8 fp=0xffff880060a6f550 flags=0x3fff8000004080
      INFO: Object 0xffff880060a6f740 @offset=5952 fp=0xffff880060a6e5d1
      
      Bytes b4 ffff880060a6f730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880060a6f740: d1 e5 a6 60 00 88 ff ff 0e 00 00 00 00 00 00 00  ...`............
      Object ffff880060a6f750: 02 cf 8e 60 00 88 ff ff 02 c0 8e 60 00 88 ff ff  ...`.......`....
      Object ffff880060a6f760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880060a6f770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880060a6f790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880060a6f7a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880060a6f7b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880060a6f7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880060a6f7d0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880060a6f7e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880060a6f7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      CPU: 0 PID: 1655 Comm: keyctl Tainted: G    B           4.5.0-rc4-kasan+ #291
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
       0000000000000000 000000001b2800b4 ffff880060a179e0 ffffffff81b60491
       ffff88006c802900 ffff880060a6f740 ffff880060a17a10 ffffffff815e2969
       ffff88006c802900 ffffea0001829b80 ffff880060a6f740 ffff880060a6e650
      Call Trace:
       [<ffffffff81b60491>] dump_stack+0x85/0xc4
       [<ffffffff815e2969>] print_trailer+0xf9/0x150
       [<ffffffff815e9454>] object_err+0x34/0x40
       [<ffffffff815ebe50>] kasan_report_error+0x230/0x550
       [<ffffffff819949be>] ? keyring_get_key_chunk+0x13e/0x210
       [<ffffffff815ec62d>] __asan_report_load_n_noabort+0x5d/0x70
       [<ffffffff81994cc3>] ? keyring_compare_object+0x213/0x240
       [<ffffffff81994cc3>] keyring_compare_object+0x213/0x240
       [<ffffffff81bc238c>] assoc_array_insert+0x86c/0x3a60
       [<ffffffff81bc1b20>] ? assoc_array_cancel_edit+0x70/0x70
       [<ffffffff8199797d>] ? __key_link_begin+0x20d/0x270
       [<ffffffff8199786c>] __key_link_begin+0xfc/0x270
       [<ffffffff81993389>] key_create_or_update+0x459/0xaf0
       [<ffffffff8128ce0d>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff81992f30>] ? key_type_lookup+0xc0/0xc0
       [<ffffffff8199e19d>] ? lookup_user_key+0x13d/0xcd0
       [<ffffffff81534763>] ? memdup_user+0x53/0x80
       [<ffffffff819983ea>] SyS_add_key+0x1ba/0x350
       [<ffffffff81998230>] ? key_get_type_from_user.constprop.6+0xa0/0xa0
       [<ffffffff828bcf4e>] ? retint_user+0x18/0x23
       [<ffffffff8128cc7e>] ? trace_hardirqs_on_caller+0x3fe/0x580
       [<ffffffff81004017>] ? trace_hardirqs_on_thunk+0x17/0x19
       [<ffffffff828bc432>] entry_SYSCALL_64_fastpath+0x12/0x76
      Memory state around the buggy address:
       ffff880060a6f700: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
       ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc
      >ffff880060a6f800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                              ^
       ffff880060a6f880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff880060a6f900: fc fc fc fc fc fc 00 00 00 00 00 00 00 00 00 00
      ==================================================================
      Signed-off-by: default avatarJerome Marchand <jmarchan@redhat.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6905c7a4
    • Lokesh Vutla's avatar
      ARM: OMAP2+: hwmod: Fix updating of sysconfig register · 882e790b
      Lokesh Vutla authored
      commit 3ca4a238 upstream.
      
      Commit 127500cc ("ARM: OMAP2+: Only write the sysconfig on idle
      when necessary") talks about verification of sysconfig cache value before
      updating it, only during idle path. But the patch is adding the
      verification in the enable path. So, adding the check in a proper place
      as per the commit description.
      
      Not keeping this check during enable path as there is a chance of losing
      context and it is safe to do on idle as the context of the register will
      never be lost while the device is active.
      Signed-off-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
      Acked-by: default avatarTero Kristo <t-kristo@ti.com>
      Cc: Jon Hunter <jonathanh@nvidia.com>
      Fixes: commit 127500cc "ARM: OMAP2+: Only write the sysconfig on idle when necessary"
      [paul@pwsan.com: appears to have been caused by my own mismerge of the
       originally posted patch]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      882e790b
    • Nishanth Menon's avatar
      ARM: OMAP2: Fix up interconnect barrier initialization for DRA7 · 81b5ed00
      Nishanth Menon authored
      commit 456e8d53 upstream.
      
      The following commits:
      commit 3fa60975 ("ARM: omap2: restore OMAP4 barrier behaviour")
      commit f746929f ("Revert "ARM: OMAP4: remove dead kconfig option OMAP4_ERRATA_I688"")
      and
      commit ea827ad5 ("ARM: DRA7: Provide proper IO map table")
      came in around the same time, unfortunately this seem to have missed
      initializing the barrier for DRA7 platforms - omap5_map_io was reused
      for dra7 till it was split out by the last patch. barrier_init
      needs to be hence carried forward as it is valid for DRA7 family of
      processors as they are for OMAP5.
      
      Fixes: ea827ad5 ("ARM: DRA7: Provide proper IO map table")
      Reported-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Reported-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      81b5ed00
    • Patrick Uiterwijk's avatar
      ARM: mvebu: Correct unit address for linksys · c6cf3b71
      Patrick Uiterwijk authored
      commit 199831c7 upstream.
      
      The USB2 port for Armada 38x is defined to be at 58000, not at
      50000.
      
      Fixes: 2d0a7add ("ARM: Kirkwood: Add support for many Synology NAS devices")
      Signed-off-by: default avatarPatrick Uiterwijk <patrick@puiterwijk.org>
      Acked-by: default avatarImre Kaloz <kaloz@openwrt.org>
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c6cf3b71
    • Lokesh Vutla's avatar
      ARM: dts: AM43x-epos: Fix clk parent for synctimer · 4bb48b5f
      Lokesh Vutla authored
      commit cfe1580a upstream.
      
      commit 55ee7017 ("arm: omap2: board-generic: use omap4_local_timer_init
      for AM437x") makes synctimer32k as the clocksource on AM43xx. By default
      the synctimer32k is clocked by 32K RTC OSC on AM43xx. But this 32K RTC OSC
      is not available on epos boards which makes it fail to boot.
      
      Synctimer32k can also be clocked by a peripheral PLL, so making this as
      clock parent for synctimer3k on epos boards.
      
      Fixes: 55ee7017 ("arm: omap2: board-generic: use omap4_local_timer_init for AM437x")
      Reported-by: default avatarNishanth Menon <nm@ti.com>
      Signed-off-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4bb48b5f
    • Marc Zyngier's avatar
      KVM: arm/arm64: Handle forward time correction gracefully · 5716a93f
      Marc Zyngier authored
      commit 1c5631c7 upstream.
      
      On a host that runs NTP, corrections can have a direct impact on
      the background timer that we program on the behalf of a vcpu.
      
      In particular, NTP performing a forward correction will result in
      a timer expiring sooner than expected from a guest point of view.
      Not a big deal, we kick the vcpu anyway.
      
      But on wake-up, the vcpu thread is going to perform a check to
      find out whether or not it should block. And at that point, the
      timer check is going to say "timer has not expired yet, go back
      to sleep". This results in the timer event being lost forever.
      
      There are multiple ways to handle this. One would be record that
      the timer has expired and let kvm_cpu_has_pending_timer return
      true in that case, but that would be fairly invasive. Another is
      to check for the "short sleep" condition in the hrtimer callback,
      and restart the timer for the remaining time when the condition
      is detected.
      
      This patch implements the latter, with a bit of refactoring in
      order to avoid too much code duplication.
      Reported-by: default avatarAlexander Graf <agraf@suse.de>
      Reviewed-by: default avatarAlexander Graf <agraf@suse.de>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5716a93f
    • David Matlack's avatar
      kvm: x86: do not leak guest xcr0 into host interrupt handlers · 1c8497d2
      David Matlack authored
      commit fc5b7f3b upstream.
      
      An interrupt handler that uses the fpu can kill a KVM VM, if it runs
      under the following conditions:
       - the guest's xcr0 register is loaded on the cpu
       - the guest's fpu context is not loaded
       - the host is using eagerfpu
      
      Note that the guest's xcr0 register and fpu context are not loaded as
      part of the atomic world switch into "guest mode". They are loaded by
      KVM while the cpu is still in "host mode".
      
      Usage of the fpu in interrupt context is gated by irq_fpu_usable(). The
      interrupt handler will look something like this:
      
      if (irq_fpu_usable()) {
              kernel_fpu_begin();
      
              [... code that uses the fpu ...]
      
              kernel_fpu_end();
      }
      
      As long as the guest's fpu is not loaded and the host is using eager
      fpu, irq_fpu_usable() returns true (interrupted_kernel_fpu_idle()
      returns true). The interrupt handler proceeds to use the fpu with
      the guest's xcr0 live.
      
      kernel_fpu_begin() saves the current fpu context. If this uses
      XSAVE[OPT], it may leave the xsave area in an undesirable state.
      According to the SDM, during XSAVE bit i of XSTATE_BV is not modified
      if bit i is 0 in xcr0. So it's possible that XSTATE_BV[i] == 1 and
      xcr0[i] == 0 following an XSAVE.
      
      kernel_fpu_end() restores the fpu context. Now if any bit i in
      XSTATE_BV == 1 while xcr0[i] == 0, XRSTOR generates a #GP. The
      fault is trapped and SIGSEGV is delivered to the current process.
      
      Only pre-4.2 kernels appear to be vulnerable to this sequence of
      events. Commit 653f52c3 ("kvm,x86: load guest FPU context more eagerly")
      from 4.2 forces the guest's fpu to always be loaded on eagerfpu hosts.
      
      This patch fixes the bug by keeping the host's xcr0 loaded outside
      of the interrupts-disabled region where KVM switches into guest mode.
      Suggested-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatarDavid Matlack <dmatlack@google.com>
      [Move load after goto cancel_injection. - Paolo]
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1c8497d2
    • Tony Luck's avatar
      x86/mce: Avoid using object after free in genpool · adbe236b
      Tony Luck authored
      commit a3125494 upstream.
      
      When we loop over all queued machine check error records to pass them
      to the registered notifiers we use llist_for_each_entry(). But the loop
      calls gen_pool_free() for the entry in the body of the loop - and then
      the iterator looks at node->next after the free.
      
      Use llist_for_each_entry_safe() instead.
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Gong Chen <gong.chen@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Link: http://lkml.kernel.org/r/0205920@agluck-desk.sc.intel.com
      Link: http://lkml.kernel.org/r/1459929916-12852-4-git-send-email-bp@alien8.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      adbe236b
    • Ming Lei's avatar
      block: loop: fix filesystem corruption in case of aio/dio · 9fed24fe
      Ming Lei authored
      commit a7297a6a upstream.
      
      Starting from commit e36f6204(block: split bios to max possible length),
      block core starts to split bio in the middle of bvec.
      
      Unfortunately loop dio/aio doesn't consider this situation, and
      always treat 'iter.iov_offset' as zero. Then filesystem corruption
      is observed.
      
      This patch figures out the offset of the base bvevc via
      'bio->bi_iter.bi_bvec_done' and fixes the issue by passing the offset
      to iov iterator.
      
      Fixes: e36f6204 (block: split bios to max possible length)
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9fed24fe
    • Ming Lei's avatar
      block: partition: initialize percpuref before sending out KOBJ_ADD · 5b616a05
      Ming Lei authored
      commit b30a337c upstream.
      
      The initialization of partition's percpu_ref should have been done before
      sending out KOBJ_ADD uevent, which may cause userspace to read partition
      table. So the uninitialized percpu_ref may be accessed in data path.
      
      This patch fixes this issue reported by Naveen.
      Reported-by: default avatarNaveen Kaje <nkaje@codeaurora.org>
      Tested-by: default avatarNaveen Kaje <nkaje@codeaurora.org>
      Fixes: 6c71013e(block: partition: convert percpu ref)
      Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5b616a05
  2. 20 Apr, 2016 28 commits