1. 20 4月, 2017 4 次提交
  2. 14 4月, 2017 7 次提交
  3. 13 4月, 2017 4 次提交
    • R
      ACPI / scan: Set the visited flag for all enumerated devices · f406270b
      Rafael J. Wysocki 提交于
      Commit 10c7e20b (ACPI / scan: fix enumeration (visited) flags for
      bus rescans) attempted to fix a problem with ACPI-based enumerateion
      of I2C/SPI devices, but it forgot to ensure that the visited flag
      will be set for all of the other enumerated devices, so fix that.
      
      Fixes: 10c7e20b (ACPI / scan: fix enumeration (visited) flags for bus rescans)
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=194885Reported-and-tested-by: NKevin Locke <kevin@kevinlocke.name>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: 4.8+ <stable@vger.kernel.org> # 4.8+
      f406270b
    • C
      cpufreq: Bring CPUs up even if cpufreq_online() failed · c4a3fa26
      Chen Yu 提交于
      There is a report that after commit 27622b06 ("cpufreq: Convert
      to hotplug state machine"), the normal CPU offline/online cycle
      fails on some platforms.
      
      According to the ftrace result, this problem was triggered on
      platforms using acpi-cpufreq as the default cpufreq driver,
      and due to the lack of some ACPI freq method (eg. _PCT),
      cpufreq_online() failed and returned a negative value, so the CPU
      hotplug state machine rolled back the CPU online process.  Actually,
      from the user's perspective, the failure of cpufreq_online() should
      not prevent that CPU from being brought up, although cpufreq might
      not work on that CPU.
      
      BTW, during system startup cpufreq_online() is not invoked via CPU
      online but by the cpufreq device creation process, so the APs can be
      brought up even though cpufreq_online() fails in that stage.
      
      This patch ignores the return value of cpufreq_online/offline() and
      lets the cpufreq framework deal with the failure.  cpufreq_online()
      itself will do a proper rollback in that case and if _PCT is missing,
      the ACPI cpufreq driver will print a warning if the corresponding
      debug options have been enabled.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=194581
      Fixes: 27622b06 ("cpufreq: Convert to hotplug state machine")
      Reported-and-tested-by: NTomasz Maciej Nowak <tmn505@gmail.com>
      Signed-off-by: NChen Yu <yu.c.chen@intel.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Cc: 4.9+ <stable@vger.kernel.org> # 4.9+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c4a3fa26
    • D
      device-dax: switch to srcu, fix rcu_read_lock() vs pte allocation · 956a4cd2
      Dan Williams 提交于
      The following warning triggers with a new unit test that stresses the
      device-dax interface.
      
       ===============================
       [ ERR: suspicious RCU usage.  ]
       4.11.0-rc4+ #1049 Tainted: G           O
       -------------------------------
       ./include/linux/rcupdate.h:521 Illegal context switch in RCU read-side critical section!
      
       other info that might help us debug this:
      
       rcu_scheduler_active = 2, debug_locks = 0
       2 locks held by fio/9070:
        #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff8d0739d7>] __do_page_fault+0x167/0x4f0
        #1:  (rcu_read_lock){......}, at: [<ffffffffc03fbd02>] dax_dev_huge_fault+0x32/0x620 [dax]
      
       Call Trace:
        dump_stack+0x86/0xc3
        lockdep_rcu_suspicious+0xd7/0x110
        ___might_sleep+0xac/0x250
        __might_sleep+0x4a/0x80
        __alloc_pages_nodemask+0x23a/0x360
        alloc_pages_current+0xa1/0x1f0
        pte_alloc_one+0x17/0x80
        __pte_alloc+0x1e/0x120
        __get_locked_pte+0x1bf/0x1d0
        insert_pfn.isra.70+0x3a/0x100
        ? lookup_memtype+0xa6/0xd0
        vm_insert_mixed+0x64/0x90
        dax_dev_huge_fault+0x520/0x620 [dax]
        ? dax_dev_huge_fault+0x32/0x620 [dax]
        dax_dev_fault+0x10/0x20 [dax]
        __do_fault+0x1e/0x140
        __handle_mm_fault+0x9af/0x10d0
        handle_mm_fault+0x16d/0x370
        ? handle_mm_fault+0x47/0x370
        __do_page_fault+0x28c/0x4f0
        trace_do_page_fault+0x58/0x2a0
        do_async_page_fault+0x1a/0xa0
        async_page_fault+0x28/0x30
      
      Inserting a page table entry may trigger an allocation while we are
      holding a read lock to keep the device instance alive for the duration
      of the fault. Use srcu for this keep-alive protection.
      
      Fixes: dee41079 ("/dev/dax, core: file operations and dax-mmap")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      956a4cd2
    • K
      mm: Tighten x86 /dev/mem with zeroing reads · a4866aa8
      Kees Cook 提交于
      Under CONFIG_STRICT_DEVMEM, reading System RAM through /dev/mem is
      disallowed. However, on x86, the first 1MB was always allowed for BIOS
      and similar things, regardless of it actually being System RAM. It was
      possible for heap to end up getting allocated in low 1MB RAM, and then
      read by things like x86info or dd, which would trip hardened usercopy:
      
      usercopy: kernel memory exposure attempt detected from ffff880000090000 (dma-kmalloc-256) (4096 bytes)
      
      This changes the x86 exception for the low 1MB by reading back zeros for
      System RAM areas instead of blindly allowing them. More work is needed to
      extend this to mmap, but currently mmap doesn't go through usercopy, so
      hardened usercopy won't Oops the kernel.
      Reported-by: NTommi Rantala <tommi.t.rantala@nokia.com>
      Tested-by: NTommi Rantala <tommi.t.rantala@nokia.com>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      a4866aa8
  4. 12 4月, 2017 3 次提交
    • W
      drm/etnaviv: fix missing unlock on error in etnaviv_gpu_submit() · 45abdf35
      Wei Yongjun 提交于
      Add the missing unlock before return from function etnaviv_gpu_submit()
      in the error handling case.
      
      lst: fixed label name.
      
      Fixes: f3cd1b06 ("drm/etnaviv: (re-)protect fence allocation with
      GPU mutex")
      CC: stable@vger.kernel.org #4.9+
      Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
      Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
      45abdf35
    • M
      scsi: ipr: do not set DID_PASSTHROUGH on CHECK CONDITION · 785a4704
      Mauricio Faria de Oliveira 提交于
      On a dual controller setup with multipath enabled, some MEDIUM ERRORs
      caused both paths to be failed, thus I/O got queued/blocked since the
      'queue_if_no_path' feature is enabled by default on IPR controllers.
      
      This example disabled 'queue_if_no_path' so the I/O failure is seen at
      the sg_dd program.  Notice that after the sg_dd test-case, both paths
      are in 'failed' state, and both path/priority groups are in 'enabled'
      state (not 'active') -- which would block I/O with 'queue_if_no_path'.
      
          # sg_dd if=/dev/dm-2 bs=4096 count=1 dio=1 verbose=4 blk_sgio=0
          <...>
          read(unix): count=4096, res=-1
          sg_dd: reading, skip=0 : Input/output error
          <...>
      
          # dmesg
          [...] sd 2:2:16:0: [sds] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
          [...] sd 2:2:16:0: [sds] Sense Key : Medium Error [current]
          [...] sd 2:2:16:0: [sds] Add. Sense: Unrecovered read error - recommend rewrite the data
          [...] sd 2:2:16:0: [sds] CDB: Read(10) 28 00 00 00 00 00 00 00 20 00
          [...] blk_update_request: I/O error, dev sds, sector 0
          [...] device-mapper: multipath: Failing path 65:32.
          <...>
          [...] device-mapper: multipath: Failing path 65:224.
      
          # multipath -l
          1IBM_IPR-0_59C2AE0000001F80 dm-2 IBM     ,IPR-0   59C2AE00
          size=5.2T features='0' hwhandler='1 alua' wp=rw
          |-+- policy='service-time 0' prio=0 status=enabled
          | `- 2:2:16:0 sds  65:32  failed undef running
          `-+- policy='service-time 0' prio=0 status=enabled
            `- 1:2:7:0  sdae 65:224 failed undef running
      
      This is not the desired behavior. The dm-multipath explicitly checks
      for the MEDIUM ERROR case (and a few others) so not to fail the path
      (e.g., I/O to other sectors could potentially happen without problems).
      See dm-mpath.c :: do_end_io_bio() -> noretry_error() !->! fail_path().
      
      The problem trace is:
      
      1) ipr_scsi_done()  // SENSE KEY/CHECK CONDITION detected, go to..
      2) ipr_erp_start()  // ipr_is_gscsi() and masked_ioasc OK, go to..
      3) ipr_gen_sense()  // masked_ioasc is IPR_IOASC_MED_DO_NOT_REALLOC,
                          // so set DID_PASSTHROUGH.
      
      4) scsi_decide_disposition()  // check for DID_PASSTHROUGH and return
                                    // early on, faking a DID_OK.. *instead*
                                    // of reaching scsi_check_sense().
      
                                    // Had it reached the latter, that would
                                    // set host_byte to DID_MEDIUM_ERROR.
      
      5) scsi_finish_command()
      6) scsi_io_completion()
      7) __scsi_error_from_host_byte()  // That would be converted to -ENODATA
      <...>
      8) dm_softirq_done()
      9) multipath_end_io()
      10) do_end_io()
      11) noretry_error()  // And that is checked in dm-mpath :: noretry_error()
                           // which would cause fail_path() not to be called.
      
      With this patch applied, the I/O is failed but the paths are not.  This
      multipath device continues accepting more I/O requests without blocking.
      (and notice the different host byte/driver byte handling per SCSI layer).
      
          # dmesg
          [...] sd 2:2:7:0: [sdaf] Done: SUCCESS Result: hostbyte=0x13 driverbyte=DRIVER_OK
          [...] sd 2:2:7:0: [sdaf] CDB: Read(10) 28 00 00 00 00 00 00 00 40 00
          [...] sd 2:2:7:0: [sdaf] Sense Key : Medium Error [current]
          [...] sd 2:2:7:0: [sdaf] Add. Sense: Unrecovered read error - recommend rewrite the data
          [...] blk_update_request: critical medium error, dev sdaf, sector 0
          [...] blk_update_request: critical medium error, dev dm-6, sector 0
          [...] sd 2:2:7:0: [sdaf] Done: SUCCESS Result: hostbyte=0x13 driverbyte=DRIVER_OK
          [...] sd 2:2:7:0: [sdaf] CDB: Read(10) 28 00 00 00 00 00 00 00 10 00
          [...] sd 2:2:7:0: [sdaf] Sense Key : Medium Error [current]
          [...] sd 2:2:7:0: [sdaf] Add. Sense: Unrecovered read error - recommend rewrite the data
          [...] blk_update_request: critical medium error, dev sdaf, sector 0
          [...] blk_update_request: critical medium error, dev dm-6, sector 0
          [...] Buffer I/O error on dev dm-6, logical block 0, async page read
      
          # multipath -l 1IBM_IPR-0_59C2AE0000001F80
          1IBM_IPR-0_59C2AE0000001F80 dm-6 IBM     ,IPR-0   59C2AE00
          size=5.2T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
          |-+- policy='service-time 0' prio=0 status=active
          | `- 2:2:7:0  sdaf 65:240 active undef running
          `-+- policy='service-time 0' prio=0 status=enabled
            `- 1:2:7:0  sdh  8:112  active undef running
      Signed-off-by: NMauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
      Acked-by: NBrian King <brking@linux.vnet.ibm.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      785a4704
    • G
      scsi: aacraid: fix PCI error recovery path · 911e572e
      Guilherme G. Piccoli 提交于
      During a PCI error recovery, if aac_check_health() is not aware that a
      PCI error happened and we have an offline PCI channel, it might trigger
      some errors (like NULL pointer dereference) and inhibit the error
      recovery process to complete.
      
      This patch makes the health check procedure aware of PCI channel issues,
      and in case of error recovery process, the function
      aac_adapter_check_health() returns -1 and let the recovery process to
      complete successfully. This patch was tested on upstream kernel
      v4.11-rc5 in PowerPC ppc64le architecture with adapter 9005:028d
      (VID:DID) - the error recovery procedure was able to recover fine.
      
      Fixes: 5c63f7f7 ("aacraid: Added EEH support")
      Cc: stable@vger.kernel.org # v4.6+
      Signed-off-by: NGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
      Reviewed-by: NDave Carroll <david.carroll@microsemi.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      911e572e
  5. 11 4月, 2017 15 次提交
    • J
      drm/udl: Fix unaligned memory access in udl_render_hline · 0c45b36f
      Jonathan Neuschäfer 提交于
      On SPARC, the udl driver filled my kernel log with these messages:
      
      [186668.910612] Kernel unaligned access at TPC[76609c] udl_render_hline+0x13c/0x3a0
      
      Use put_unaligned_be16 to avoid them. On x86 this results in the same
      code, but on SPARC the compiler emits two single-byte stores.
      Signed-off-by: NJonathan Neuschäfer <j.neuschaefer@gmx.net>
      Acked-by: NDavid Airlie <airlied@linux.ie>
      Signed-off-by: NSean Paul <seanpaul@chromium.org>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170407200229.20642-1-j.neuschaefer@gmx.net
      0c45b36f
    • J
      drm/i915: Don't call synchronize_rcu_expedited under struct_mutex · c053b5a5
      Joonas Lahtinen 提交于
      Only call synchronize_rcu_expedited after unlocking struct_mutex to
      avoid deadlock because the workqueues depend on struct_mutex.
      
      >From original patch by Andrea:
      
      synchronize_rcu/synchronize_sched/synchronize_rcu_expedited() will
      hang until its own workqueues are run. The i915 gem workqueues will
      wait on the struct_mutex to be released. So we cannot wait for a
      quiescent state using those rcu primitives while holding the
      struct_mutex or it creates a circular lock dependency resulting in
      kernel hangs (which is reproducible but goes undetected by lockdep).
      
      kswapd0         D    0   700      2 0x00000000
      Call Trace:
      ? __schedule+0x1a5/0x660
      ? schedule+0x36/0x80
      ? _synchronize_rcu_expedited.constprop.65+0x2ef/0x300
      ? wake_up_bit+0x20/0x20
      ? rcu_stall_kick_kthreads.part.54+0xc0/0xc0
      ? rcu_exp_wait_wake+0x530/0x530
      ? i915_gem_shrink+0x34b/0x4b0
      ? i915_gem_shrinker_scan+0x7c/0x90
      ? i915_gem_shrinker_scan+0x7c/0x90
      ? shrink_slab.part.61.constprop.72+0x1c1/0x3a0
      ? shrink_zone+0x154/0x160
      ? kswapd+0x40a/0x720
      ? kthread+0xf4/0x130
      ? try_to_free_pages+0x450/0x450
      ? kthread_create_on_node+0x40/0x40
      ? ret_from_fork+0x23/0x30
      plasmashell     D    0  4657   4614 0x00000000
      Call Trace:
      ? __schedule+0x1a5/0x660
      ? schedule+0x36/0x80
      ? schedule_preempt_disabled+0xe/0x10
      ? __mutex_lock.isra.4+0x1c9/0x790
      ? i915_gem_close_object+0x26/0xc0
      ? i915_gem_close_object+0x26/0xc0
      ? drm_gem_object_release_handle+0x48/0x90
      ? drm_gem_handle_delete+0x50/0x80
      ? drm_ioctl+0x1fa/0x420
      ? drm_gem_handle_create+0x40/0x40
      ? pipe_write+0x391/0x410
      ? __vfs_write+0xc6/0x120
      ? do_vfs_ioctl+0x8b/0x5d0
      ? SyS_ioctl+0x3b/0x70
      ? entry_SYSCALL_64_fastpath+0x13/0x94
      kworker/0:0     D    0 29186      2 0x00000000
      Workqueue: events __i915_gem_free_work
      Call Trace:
      ? __schedule+0x1a5/0x660
      ? schedule+0x36/0x80
      ? schedule_preempt_disabled+0xe/0x10
      ? __mutex_lock.isra.4+0x1c9/0x790
      ? del_timer_sync+0x44/0x50
      ? update_curr+0x57/0x110
      ? __i915_gem_free_objects+0x31/0x300
      ? __i915_gem_free_objects+0x31/0x300
      ? __i915_gem_free_work+0x2d/0x40
      ? process_one_work+0x13a/0x3b0
      ? worker_thread+0x4a/0x460
      ? kthread+0xf4/0x130
      ? process_one_work+0x3b0/0x3b0
      ? kthread_create_on_node+0x40/0x40
      ? ret_from_fork+0x23/0x30
      
      Fixes: 3d3d18f0 ("drm/i915: Avoid rcu_barrier() from reclaim paths (shrinker)")
      Reported-by: NAndrea Arcangeli <aarcange@redhat.com>
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      (cherry picked from commit 8f612d05)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      c053b5a5
    • S
      drm/i915: Suspend GuC prior to GPU Reset during GEM suspend · 63987bfe
      Sagar Arun Kamble 提交于
      i915 is currently doing a full GPU reset at the end of
      i915_gem_suspend() followed by GuC suspend in i915_drm_suspend(). This
      GPU reset clobbers the GuC, causing the suspend request to then fail,
      leaving the GuC in an undefined state. We need to tell the GuC to
      suspend before we do the direct intel_gpu_reset().
      
      v2: Commit message update. (Chris, Daniele)
      
      Fixes: 1c777c5d ("drm/i915/hsw: Fix GPU hang during resume from S3-devices state")
      Cc: Jeff McGee <jeff.mcgee@intel.com>
      Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Imre Deak <imre.deak@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1491387710-20553-1-git-send-email-sagar.a.kamble@intel.comReviewed-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      (cherry picked from commit fd089233)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      63987bfe
    • J
    • M
      pinctrl: cherryview: Add a quirk to make Acer Chromebook keyboard work again · 70365027
      Mika Westerberg 提交于
      After commit 47c950d1 ("pinctrl: cherryview: Do not add all
      southwest and north GPIOs to IRQ domain") the driver does not add all
      GPIOs to the irqdomain. The reason for that is that those GPIOs cannot
      generate IRQs at all, only GPEs (General Purpose Events). This causes
      Linux virtual IRQ numbering to change.
      
      However, it seems some CYAN Chromebooks, including Acer Chromebook
      hardcodes these Linux IRQ numbers in the ACPI tables of the machine.
      Since the numbering is different now, the IRQ meant for keyboard does
      not match the Linux virtual IRQ number anymore making the keyboard
      non-functional.
      
      Work this around by adding special quirk just for these machines where
      we add back all GPIOs to the irqdomain. Rest of the Cherryview/Braswell
      based machines will not be affected by the change.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=194945
      Fixes: 47c950d1 ("pinctrl: cherryview: Do not add all southwest and north GPIOs to IRQ domain")
      Reported-by: NAdam S Levy <theadamlevy@gmail.com>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      70365027
    • C
      Input: xpad - add support for Razer Wildcat gamepad · 53763668
      Cameron Gutman 提交于
      Cc: stable@vger.kernel.org
      Signed-off-by: NCameron Gutman <aicommander@gmail.com>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      53763668
    • D
      libnvdimm: band aid btt vs clear poison locking · 4aa5615e
      Dan Williams 提交于
      The following warning results from holding a lane spinlock,
      preempt_disable(), or the btt map spinlock and then trying to take the
      reconfig_mutex to walk the poison list and potentially add new entries.
      
       BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747
       in_atomic(): 1, irqs_disabled(): 0, pid: 17159, name: dd
       [..]
       Call Trace:
        dump_stack+0x85/0xc8
        ___might_sleep+0x184/0x250
        __might_sleep+0x4a/0x90
        __mutex_lock+0x58/0x9b0
        ? nvdimm_bus_lock+0x21/0x30 [libnvdimm]
        ? __nvdimm_bus_badblocks_clear+0x2f/0x60 [libnvdimm]
        ? acpi_nfit_forget_poison+0x79/0x80 [nfit]
        ? _raw_spin_unlock+0x27/0x40
        mutex_lock_nested+0x1b/0x20
        nvdimm_bus_lock+0x21/0x30 [libnvdimm]
        nvdimm_forget_poison+0x25/0x50 [libnvdimm]
        nvdimm_clear_poison+0x106/0x140 [libnvdimm]
        nsio_rw_bytes+0x164/0x270 [libnvdimm]
        btt_write_pg+0x1de/0x3e0 [nd_btt]
        ? blk_queue_enter+0x30/0x290
        btt_make_request+0x11a/0x310 [nd_btt]
        ? blk_queue_enter+0xb7/0x290
        ? blk_queue_enter+0x30/0x290
        generic_make_request+0x118/0x3b0
      
      As a minimal fix, disable error clearing when the BTT is enabled for the
      namespace. For the final fix a larger rework of the poison list locking
      is needed.
      
      Note that this is not a problem in the blk case since that path never
      calls nvdimm_clear_poison().
      
      Cc: <stable@vger.kernel.org>
      Fixes: 82bf1037 ("libnvdimm: check and clear poison before writing to pmem")
      Cc: Dave Jiang <dave.jiang@intel.com>
      [jeff: dynamically disable error clearing in the btt case]
      Suggested-by: NJeff Moyer <jmoyer@redhat.com>
      Reviewed-by: NJeff Moyer <jmoyer@redhat.com>
      Reported-by: NVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      4aa5615e
    • D
      libnvdimm: fix reconfig_mutex, mmap_sem, and jbd2_handle lockdep splat · 0beb2012
      Dan Williams 提交于
      Holding the reconfig_mutex over a potential userspace fault sets up a
      lockdep dependency chain between filesystem-DAX and the libnvdimm ioctl
      path. Move the user access outside of the lock.
      
           [ INFO: possible circular locking dependency detected ]
           4.11.0-rc3+ #13 Tainted: G        W  O
           -------------------------------------------------------
           fallocate/16656 is trying to acquire lock:
            (&nvdimm_bus->reconfig_mutex){+.+.+.}, at: [<ffffffffa00080b1>] nvdimm_bus_lock+0x21/0x30 [libnvdimm]
           but task is already holding lock:
            (jbd2_handle){++++..}, at: [<ffffffff813b4944>] start_this_handle+0x104/0x460
      
          which lock already depends on the new lock.
      
          the existing dependency chain (in reverse order) is:
      
          -> #2 (jbd2_handle){++++..}:
                  lock_acquire+0xbd/0x200
                  start_this_handle+0x16a/0x460
                  jbd2__journal_start+0xe9/0x2d0
                  __ext4_journal_start_sb+0x89/0x1c0
                  ext4_dirty_inode+0x32/0x70
                  __mark_inode_dirty+0x235/0x670
                  generic_update_time+0x87/0xd0
                  touch_atime+0xa9/0xd0
                  ext4_file_mmap+0x90/0xb0
                  mmap_region+0x370/0x5b0
                  do_mmap+0x415/0x4f0
                  vm_mmap_pgoff+0xd7/0x120
                  SyS_mmap_pgoff+0x1c5/0x290
                  SyS_mmap+0x22/0x30
                  entry_SYSCALL_64_fastpath+0x1f/0xc2
      
          -> #1 (&mm->mmap_sem){++++++}:
                  lock_acquire+0xbd/0x200
                  __might_fault+0x70/0xa0
                  __nd_ioctl+0x683/0x720 [libnvdimm]
                  nvdimm_ioctl+0x8b/0xe0 [libnvdimm]
                  do_vfs_ioctl+0xa8/0x740
                  SyS_ioctl+0x79/0x90
                  do_syscall_64+0x6c/0x200
                  return_from_SYSCALL_64+0x0/0x7a
      
          -> #0 (&nvdimm_bus->reconfig_mutex){+.+.+.}:
                  __lock_acquire+0x16b6/0x1730
                  lock_acquire+0xbd/0x200
                  __mutex_lock+0x88/0x9b0
                  mutex_lock_nested+0x1b/0x20
                  nvdimm_bus_lock+0x21/0x30 [libnvdimm]
                  nvdimm_forget_poison+0x25/0x50 [libnvdimm]
                  nvdimm_clear_poison+0x106/0x140 [libnvdimm]
                  pmem_do_bvec+0x1c2/0x2b0 [nd_pmem]
                  pmem_make_request+0xf9/0x270 [nd_pmem]
                  generic_make_request+0x118/0x3b0
                  submit_bio+0x75/0x150
      
      Cc: <stable@vger.kernel.org>
      Fixes: 62232e45 ("libnvdimm: control (ioctl) messages for nvdimm_bus and nvdimm devices")
      Cc: Dave Jiang <dave.jiang@intel.com>
      Reported-by: NVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      0beb2012
    • O
      sata_via: Enable hotplug only on VT6421 · 3cf86452
      Ondrej Zary 提交于
      Commit 57e5568f ("sata_via: Implement hotplug for VT6421") adds
      hotplug IRQ handler for VT6421 but enables hotplug on all chips. This
      is a bug because it causes "irq xx: nobody cared" error on VT6420 when
      hot-(un)plugging a drive:
      
      [  381.839948] irq 20: nobody cared (try booting with the "irqpoll" option)
      [  381.840014] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-rc5+ #148
      [  381.840066] Hardware name:          P4VM800/P4VM800, BIOS P1.60 05/29/2006
      [  381.840117] Call Trace:
      [  381.840167]  <IRQ>
      [  381.840225]  ? dump_stack+0x44/0x58
      [  381.840278]  ? __report_bad_irq+0x14/0x97
      [  381.840327]  ? handle_edge_irq+0xa5/0xa5
      [  381.840376]  ? note_interrupt+0x155/0x1cf
      [  381.840426]  ? handle_edge_irq+0xa5/0xa5
      [  381.840474]  ? handle_irq_event_percpu+0x32/0x38
      [  381.840524]  ? handle_irq_event+0x1f/0x38
      [  381.840573]  ? handle_fasteoi_irq+0x69/0xb8
      [  381.840625]  ? handle_irq+0x4f/0x5d
      [  381.840672]  </IRQ>
      [  381.840726]  ? do_IRQ+0x2e/0x8b
      [  381.840782]  ? common_interrupt+0x2c/0x34
      [  381.840836]  ? mwait_idle+0x60/0x82
      [  381.840892]  ? arch_cpu_idle+0x6/0x7
      [  381.840949]  ? do_idle+0x96/0x18e
      [  381.841002]  ? cpu_startup_entry+0x16/0x1a
      [  381.841057]  ? start_kernel+0x319/0x31c
      [  381.841111]  ? startup_32_smp+0x166/0x168
      [  381.841165] handlers:
      [  381.841219] [<c12a7263>] ata_bmdma_interrupt
      [  381.841274] Disabling IRQ #20
      
      Seems that VT6420 can do hotplug too (there's no documentation) but the
      comments say that SCR register access (required for detecting hotplug
      events) can cause problems on these chips.
      
      For now, just keep hotplug disabled on anything other than VT6421.
      Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      3cf86452
    • M
      virtio-pci: Remove affinity hint before freeing the interrupt · 2f8dc3a0
      Marc Zyngier 提交于
      virtio-pci registers a per-vq affinity hint when using MSIX,
      but fails to remove it when freeing the interrupt, resulting
      in this type of splat:
      
      [   31.111202] WARNING: CPU: 0 PID: 2823 at kernel/irq/manage.c:1503 __free_irq+0x2c4/0x2c8
      [   31.114689] Modules linked in:
      [   31.116101] CPU: 0 PID: 2823 Comm: kexec Not tainted 4.10.0+ #6941
      [   31.118911] Hardware name: Generic DT based system
      [   31.121319] [<c022fb78>] (unwind_backtrace) from [<c0229d8c>] (show_stack+0x18/0x1c)
      [   31.125017] [<c0229d8c>] (show_stack) from [<c05192f4>] (dump_stack+0x84/0x98)
      [   31.128427] [<c05192f4>] (dump_stack) from [<c023d940>] (__warn+0xf4/0x10c)
      [   31.131910] [<c023d940>] (__warn) from [<c023da20>] (warn_slowpath_null+0x28/0x30)
      [   31.135543] [<c023da20>] (warn_slowpath_null) from [<c0290238>] (__free_irq+0x2c4/0x2c8)
      [   31.139355] [<c0290238>] (__free_irq) from [<c02902d0>] (free_irq+0x44/0x78)
      [   31.142909] [<c02902d0>] (free_irq) from [<c059d3a8>] (vp_del_vqs+0x68/0x1c0)
      [   31.146299] [<c059d3a8>] (vp_del_vqs) from [<c056ca4c>] (pci_device_shutdown+0x3c/0x78)
      
      The obvious fix is to drop the affinity hint before freeing the
      interrupt.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      2f8dc3a0
    • M
      Revert "virtio_pci: remove struct virtio_pci_vq_info" · 0a9b3f47
      Michael S. Tsirkin 提交于
      This reverts commit 5c34d002.
      
      Conflicts:
      	drivers/virtio/virtio_pci_common.c
      
      The cleanup seems to be one of the changes that broke
      hybernation for some users. We are still not sure why
      but revert helps.
      
      This reverts the cleanup changes but keeps the affinity support.
      Tested-by: NMike Galbraith <efault@gmx.de>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      0a9b3f47
    • M
      Revert "virtio_pci: use shared interrupts for virtqueues" · 0b0f9dc5
      Michael S. Tsirkin 提交于
      This reverts commit 07ec5148.
      
      Conflicts:
      	drivers/virtio/virtio_pci_common.c
      
      Unfortunately the idea does not work with threadirqs
      as more than 32 queues can then map to a single interrupts.
      
      Further, the cleanup seems to be one of the changes that broke
      hybernation for some users. We are still not sure why
      but revert helps.
      
      This reverts the cleanup changes but keeps the affinity support.
      Tested-by: NMike Galbraith <efault@gmx.de>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      0b0f9dc5
    • M
      Revert "virtio_pci: don't duplicate the msix_enable flag in struct pci_dev" · 2008c154
      Michael S. Tsirkin 提交于
      This reverts commit 53a020c6.
      
      The cleanup seems to be one of the changes that broke
      hybernation for some users. We are still not sure why
      but revert helps.
      Tested-by: NMike Galbraith <efault@gmx.de>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      2008c154
    • M
      Revert "virtio_pci: simplify MSI-X setup" · bf951b10
      Michael S. Tsirkin 提交于
      This reverts commit 52a61516.
      
      Conflicts:
      	drivers/virtio/virtio_pci_common.c
      
      The cleanup seems to be one of the changes that broke
      hybernation for some users. We are still not sure why
      but revert helps.
      
      This reverts the cleanup changes but keeps the affinity support.
      Tested-by: NMike Galbraith <efault@gmx.de>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      bf951b10
    • M
      Revert "virtio_pci: fix out of bound access for msix_names" · 8f10d014
      Michael S. Tsirkin 提交于
      This reverts commit de85ec8b.
      
      Follow-up patches will revert 07ec5148 ("virtio_pci: use shared
      interrupts for virtqueues") that triggered the problem so no need for
      this one anymore.
      Tested-by: NMike Galbraith <efault@gmx.de>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      8f10d014
  6. 10 4月, 2017 4 次提交
  7. 08 4月, 2017 3 次提交