1. 31 3月, 2015 3 次提交
  2. 27 3月, 2015 3 次提交
  3. 26 3月, 2015 6 次提交
  4. 25 3月, 2015 1 次提交
    • D
      drm/i915: Don't try to reference the fb in get_initial_plane_config() · 59a58cb3
      Damien Lespiau 提交于
      Tvrtko noticed a new warning on boot:
      
        WARNING: CPU: 1 PID: 353 at include/linux/kref.h:47 drm_framebuffer_reference+0x6c/0x80 [drm]()
        Call Trace:
        [<ffffffff8161f10c>] dump_stack+0x4f/0x7b
        [<ffffffff81052caa>] warn_slowpath_common+0xaa/0xd0
        [<ffffffff81052d8a>] warn_slowpath_null+0x1a/0x20
        [<ffffffffa00d035c>] drm_framebuffer_reference+0x6c/0x80 [drm]
        [<ffffffffa01c0df7>] update_state_fb.isra.54+0x47/0x50 [i915]
        [<ffffffffa01ccd5c>] skylake_get_initial_plane_config+0x93c/0x950 [i915]
        [<ffffffffa01e8721>] intel_modeset_init+0x1551/0x17c0 [i915]
        [<ffffffffa02476e0>] i915_driver_load+0xed0/0x11e0 [i915]
        [<ffffffff81627aa1>] ? _raw_spin_unlock_irqrestore+0x51/0x70
        [<ffffffffa00ca8b7>] drm_dev_register+0x77/0x110 [drm]
        [<ffffffffa00cda3b>] drm_get_pci_dev+0x11b/0x1f0 [drm]
        [<ffffffff81098e3d>] ? trace_hardirqs_on+0xd/0x10
        [<ffffffff81627aa1>] ? _raw_spin_unlock_irqrestore+0x51/0x70
        [<ffffffffa0145276>] i915_pci_probe+0x56/0x60 [i915]
        [<ffffffff813ad59c>] pci_device_probe+0x7c/0x100
        [<ffffffff81466aad>] driver_probe_device+0x16d/0x380
      
      We cannot take a reference at this point, not before
      intel_framebuffer_init() and the underlying drm_framebuffer_init().
      
      Introduced in:
      
        commit 706dc7b549175e47f23e913b7f1e52874a7d0f56
        Author: Matt Roper <matthew.d.roper@intel.com>
        Date:   Tue Feb 3 13:10:04 2015 -0800
      
            drm/i915: Ensure plane->state->fb stays in sync with plane->fb
      
      v2: Don't move update_state_fb(). It was moved around because I
          originally put update_state_fb() in intel_alloc_plane_obj() before
          finding a better place. (Matt)
      Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
      Reported-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      From drm-next:
      (cherry picked from commit f55548b5)
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      59a58cb3
  5. 24 3月, 2015 2 次提交
    • D
      drm: Fixup racy refcounting in plane_force_disable · 8218c3f4
      Daniel Vetter 提交于
      Originally it was impossible to be dropping the last refcount in this
      function since there was always one around still from the idr. But in
      
      commit 83f45fc3
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Wed Aug 6 09:10:18 2014 +0200
      
          drm: Don't grab an fb reference for the idr
      
      we've switched to weak references, broke that assumption but forgot to
      fix it up.
      
      Since we still force-disable planes it's only possible to hit this
      when racing multiple rmfb with fbdev restoring or similar evil things.
      As long as userspace is nice it's impossible to hit the BUG_ON.
      
      But the BUG_ON would most likely be hit from fbdev code, which usually
      invovles the console_lock besides all modeset locks. So very likely
      we'd never get the bug reports if this was hit in the wild, hence
      better be safe than sorry and backport.
      
      Spotted by Matt Roper while reviewing other patches.
      
      [airlied: pull this back into 4.0 - the oops happens there]
      
      Cc: stable@vger.kernel.org
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      8218c3f4
    • M
      dm: fix add_disk() NULL pointer due to race with free_dev() · 63a4f065
      Mike Snitzer 提交于
      Commit c4db59d3 ("fs: don't reassign dirty inodes to
      default_backing_dev_info") exposed DM to a latent race in free_dev() vs
      add_disk() in relation to management of the device's minor number.
      
      Fix this by refactoring free_dev() to match cleanup order of the
      alloc_dev() error path.  Move cleanup of the gendisk, queue, and bdev
      to _before_ the cleanup of the idr managed minor number.
      
      Also, purely due to cleanup that fell out during the free_dev() audit:
      - adjust dm_blk_close() to access the gendisk's private_data under
        the _minor_lock spinlock.
      - move __dm_destroy()'s dm_get_live_table() call out from under the
        _minor_lock spinlock.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1202449Reported-by: NZdenek Kabelac <zkabelac@redhat.com>
      Reported-by: NJeff Moyer <jmoyer@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      63a4f065
  6. 23 3月, 2015 1 次提交
  7. 22 3月, 2015 1 次提交
    • O
      cx82310_eth: wait for firmware to become ready · f40bff42
      Ondrej Zary 提交于
      When the device is powered up, some (older) firmware versions fail to work
      properly if we send commands before the boot is complete (everything is OK
      when the device is hot-plugged). The firmware indicates its ready status by
      putting the link up.
      Newer firmwares delay the first command so they don't suffer from this problem.
      They also report the link being always up.
      
      Wait for firmware to become ready (link up) before sending any commands and/or
      data.
      
      This also allows lowering CMD_TIMEOUT value to a reasonable time.
      
      Tested with 4.1.0.9 (old) and 4.1.0.30 (new) firmware versions.
      Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f40bff42
  8. 21 3月, 2015 5 次提交
  9. 20 3月, 2015 13 次提交
    • R
      Revert "x86/PCI: Refine the way to release PCI IRQ resources" · 9e8ce4b9
      Rafael J. Wysocki 提交于
      Commit b4b55cda (Refine the way to release PCI IRQ resources)
      introduced a regression in the PCI IRQ resource management by causing
      the IRQ resource of a device, established when pci_enabled_device()
      is called on a fully disabled device, to be released when the driver
      is unbound from the device, regardless of the enable_cnt.
      
      This leads to the situation that an ill-behaved driver can now make a
      device unusable to subsequent drivers by an imbalance in their use of
      pci_enable/disable_device().  That is a serious problem for secondary
      drivers like vfio-pci, which are innocent of the transgressions of
      the previous driver.
      
      Since the solution of this problem is not immediate and requires
      further discussion, revert commit b4b55cda and the issue it was
      supposed to address (a bug related to xen-pciback) will be taken
      care of in a different way going forward.
      Reported-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9e8ce4b9
    • C
      target: do not reject FUA CDBs when write cache is enabled but emulate_write_cache is 0 · 9bc6548f
      Christophe Vu-Brugier 提交于
      A check that rejects a CDB with FUA bit set if no write cache is
      emulated was added by the following commit:
      
        fde9f50f target: Add sanity checks for DPO/FUA bit usage
      
      The condition is as follows:
      
        if (!dev->dev_attrib.emulate_fua_write ||
            !dev->dev_attrib.emulate_write_cache)
      
      However, this check is wrong if the backend device supports WCE but
      "emulate_write_cache" is disabled.
      
      This patch uses se_dev_check_wce() (previously named
      spc_check_dev_wce) to invoke transport->get_write_cache() if the
      device has a write cache or check the "emulate_write_cache" attribute
      otherwise.
      Reported-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NChristophe Vu-Brugier <cvubrugier@fastmail.fm>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      9bc6548f
    • N
      target: Fix virtual LUN=0 target_configure_device failure OOPs · 5f7da044
      Nicholas Bellinger 提交于
      This patch fixes a NULL pointer dereference triggered by a late
      target_configure_device() -> alloc_workqueue() failure that results
      in target_free_device() being called with DF_CONFIGURED already set,
      which subsequently OOPses in destroy_workqueue() code.
      
      Currently this only happens at modprobe target_core_mod time when
      core_dev_setup_virtual_lun0() -> target_configure_device() fails,
      and the explicit target_free_device() gets called.
      
      To address this bug originally introduced by commit 0fd97ccf, go
      ahead and move DF_CONFIGURED to end of target_configure_device()
      code to handle this special failure case.
      Reported-by: NClaudio Fleiner <cmf@daterainc.com>
      Cc: Claudio Fleiner <cmf@daterainc.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: <stable@vger.kernel.org> # v3.7+
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      5f7da044
    • N
      target/pscsi: Fix NULL pointer dereference in get_device_type · 215a8fe4
      Nicholas Bellinger 提交于
      This patch fixes a NULL pointer dereference OOPs with pSCSI backends
      within target_core_stat.c code.  The bug is caused by a configfs attr
      read if no pscsi_dev_virt->pdv_sd has been configured.
      Reported-by: NOlaf Hering <olaf@aepfle.de>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      215a8fe4
    • D
      tcm_fc: missing curly braces in ft_invl_hw_context() · d556546e
      Dan Carpenter 提交于
      This patch adds a missing set of conditional check braces in
      ft_invl_hw_context() originally introduced by commit dcd998cc
      when handling DDP failures in ft_recv_write_data() code.
      
       commit dcd998cc
       Author: Kiran Patil <kiran.patil@intel.com>
       Date:   Wed Aug 3 09:20:01 2011 +0000
      
          tcm_fc: Handle DDP/SW fc_frame_payload_get failures in ft_recv_write_data
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Cc: Kiran Patil <kiran.patil@intel.com>
      Cc: <stable@vger.kernel.org> # 3.1+
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      d556546e
    • B
      target: Fix reference leak in target_get_sess_cmd() error path · 7544e597
      Bart Van Assche 提交于
      This patch fixes a se_cmd->cmd_kref leak buf when se_sess->sess_tearing_down
      is true within target_get_sess_cmd() submission path code.
      
      This se_cmd reference leak can occur during active session shutdown when
      ack_kref=1 is passed by target_submit_cmd_[map_sgls,tmr]() callers.
      Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Cc: <stable@vger.kernel.org> # 3.6+
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      7544e597
    • B
      loop/usb/vhost-scsi/xen-scsiback: Fix use of __transport_register_session · 2f450cc1
      Bart Van Assche 提交于
      This patch changes loopback, usb-gadget, vhost-scsi and xen-scsiback
      fabric code to invoke transport_register_session() instead of the
      unprotected flavour, to ensure se_tpg->session_lock is taken when
      adding new session list nodes to se_tpg->tpg_sess_list.
      
      Note that since these four fabric drivers already hold their own
      internal TPG mutexes when accessing se_tpg->tpg_sess_list, and
      consist of a single se_session created through configfs attribute
      access, no list corruption can currently occur.
      
      So for correctness sake, go ahead and use the se_tpg->session_lock
      protected version for these four fabric drivers.
      Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      2f450cc1
    • B
      tcm_qla2xxx: Fix incorrect use of __transport_register_session · 75c3d0bf
      Bart Van Assche 提交于
      This patch fixes the incorrect use of __transport_register_session()
      in tcm_qla2xxx_check_initiator_node_acl() code, that does not perform
      explicit se_tpg->session_lock when accessing se_tpg->tpg_sess_list
      to add new se_sess nodes.
      
      Given that tcm_qla2xxx_check_initiator_node_acl() is not called with
      qla_hw->hardware_lock held for all accesses of ->tpg_sess_list, the
      code should be using transport_register_session() instead.
      Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Giridhar Malavali <giridhar.malavali@qlogic.com>
      Cc: Quinn Tran <quinn.tran@qlogic.com>
      Cc: <stable@vger.kernel.org> # 3.5+
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      75c3d0bf
    • N
      iscsi-target: Avoid early conn_logout_comp for iser connections · f068fbc8
      Nicholas Bellinger 提交于
      This patch fixes a iser specific logout bug where early complete()
      of conn->conn_logout_comp in iscsit_close_connection() was causing
      isert_wait4logout() to complete too soon, triggering a use after
      free NULL pointer dereference of iscsi_conn memory.
      
      The complete() was originally added for traditional iscsi-target
      when a ISCSI_LOGOUT_OP failed in iscsi_target_rx_opcode(), but given
      iser-target does not wait in logout failure, this special case needs
      to be avoided.
      Reported-by: NSagi Grimberg <sagig@mellanox.com>
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Cc: Slava Shwartsman <valyushash@gmail.com>
      Cc: <stable@vger.kernel.org> # v3.10+
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      f068fbc8
    • N
      Revert "iscsi-target: Avoid IN_LOGOUT failure case for iser-target" · 2a03ee8c
      Nicholas Bellinger 提交于
      This reverts commit 72859d91.
      
      The original patch was wrong, iscsit_close_connection() still needs
      to release iscsi_conn during both normal + exception IN_LOGOUT status
      with ib_isert enabled.
      
      The original OOPs is due to completing conn_logout_comp early within
      iscsit_close_connection(), causing isert_wait4logout() to complete
      instead of waiting for iscsit_logout_post_handler_*() to be called.
      Reported-by: NSagi Grimberg <sagig@mellanox.com>
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Cc: Slava Shwartsman <valyushash@gmail.com>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      2a03ee8c
    • N
      target: Disallow changing of WRITE cache/FUA attrs after export · 4b36b68c
      Nicholas Bellinger 提交于
      Now that incoming FUA=1 bit check is enforced for backends with FUA or
      WCE disabled, go ahead and disallow the changing of related backend
      attributes when active fabric exports exist.
      
      This is required to avoid potential failures with existing initiator
      LUN registrations that have been previously created with FUA=1.
      Reported-by: NChristoph Hellwig <hch@lst.de>
      Cc: Doug Gilbert <dgilbert@interlog.com>
      Cc: James Bottomley <JBottomley@Parallels.com>
      Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      4b36b68c
    • P
      regmap: introduce regmap_name to fix syscon regmap trace events · c6b570d9
      Philipp Zabel 提交于
      This patch fixes a NULL pointer dereference when enabling regmap event
      tracing in the presence of a syscon regmap, introduced by commit bdb0066d
      ("mfd: syscon: Decouple syscon interface from platform devices").
      That patch introduced syscon regmaps that have their dev field set to NULL.
      The regmap trace events expect it to point to a valid struct device and feed
      it to dev_name():
      
        $ echo 1 > /sys/kernel/debug/tracing/events/regmap/enable
      
        Unable to handle kernel NULL pointer dereference at virtual address 0000002c
        pgd = 80004000
        [0000002c] *pgd=00000000
        Internal error: Oops: 17 [#1] SMP ARM
        Modules linked in: coda videobuf2_vmalloc
        CPU: 0 PID: 304 Comm: kworker/0:2 Not tainted 4.0.0-rc2+ #9197
        Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
        Workqueue: events_freezable thermal_zone_device_check
        task: 9f25a200 ti: 9f1ee000 task.ti: 9f1ee000
        PC is at ftrace_raw_event_regmap_block+0x3c/0xe4
        LR is at _regmap_raw_read+0x1bc/0x1cc
        pc : [<803636e8>]    lr : [<80365f2c>]    psr: 600f0093
        sp : 9f1efd78  ip : 9f1efdb8  fp : 9f1efdb4
        r10: 00000004  r9 : 00000001  r8 : 00000001
        r7 : 00000180  r6 : 00000000  r5 : 9f00e3c0  r4 : 00000003
        r3 : 00000001  r2 : 00000180  r1 : 00000000  r0 : 9f00e3c0
        Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
        Control: 10c5387d  Table: 2d91004a  DAC: 00000015
        Process kworker/0:2 (pid: 304, stack limit = 0x9f1ee210)
        Stack: (0x9f1efd78 to 0x9f1f0000)
        fd60:                                                       9f1efda4 9f1efd88
        fd80: 800708c0 805f9510 80927140 800f0013 9f1fc800 9eb2f490 00000000 00000180
        fda0: 808e3840 00000001 9f1efdfc 9f1efdb8 80365f2c 803636b8 805f8958 800708e0
        fdc0: a00f0013 803636ac 9f16de00 00000180 80927140 9f1fc800 9f1fc800 9f1efe6c
        fde0: 9f1efe6c 9f732400 00000000 00000000 9f1efe1c 9f1efe00 80365f70 80365d7c
        fe00: 80365f3c 9f1fc800 9f1fc800 00000180 9f1efe44 9f1efe20 803656a4 80365f48
        fe20: 9f1fc800 00000180 9f1efe6c 9f1efe6c 9f732400 00000000 9f1efe64 9f1efe48
        fe40: 803657bc 80365634 00000001 9e95f910 9f1fc800 9f1efeb4 9f1efe8c 9f1efe68
        fe60: 80452ac0 80365778 9f1efe8c 9f1efe78 9e93d400 9e93d5e8 9f1efeb4 9f72ef40
        fe80: 9f1efeac 9f1efe90 8044e11c 80452998 8045298c 9e93d608 9e93d400 808e1978
        fea0: 9f1efecc 9f1efeb0 8044fd14 8044e0d0 ffffffff 9f25a200 9e93d608 9e481380
        fec0: 9f1efedc 9f1efed0 8044fde8 8044fcec 9f1eff1c 9f1efee0 80038d50 8044fdd8
        fee0: 9f1ee020 9f72ef40 9e481398 00000000 00000008 9f72ef54 9f1ee020 9f72ef40
        ff00: 9e481398 9e481380 00000008 9f72ef40 9f1eff5c 9f1eff20 80039754 80038bfc
        ff20: 00000000 9e481380 80894100 808e1662 00000000 9e4f2ec0 00000000 9e481380
        ff40: 800396f8 00000000 00000000 00000000 9f1effac 9f1eff60 8003e020 80039704
        ff60: ffffffff 00000000 ffffffff 9e481380 00000000 00000000 9f1eff78 9f1eff78
        ff80: 00000000 00000000 9f1eff88 9f1eff88 9e4f2ec0 8003df30 00000000 00000000
        ffa0: 00000000 9f1effb0 8000eb60 8003df3c 00000000 00000000 00000000 00000000
        ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff
        Backtrace:
        [<803636ac>] (ftrace_raw_event_regmap_block) from [<80365f2c>] (_regmap_raw_read+0x1bc/0x1cc)
         r9:00000001 r8:808e3840 r7:00000180 r6:00000000 r5:9eb2f490 r4:9f1fc800
        [<80365d70>] (_regmap_raw_read) from [<80365f70>] (_regmap_bus_read+0x34/0x6c)
         r10:00000000 r9:00000000 r8:9f732400 r7:9f1efe6c r6:9f1efe6c r5:9f1fc800
         r4:9f1fc800
        [<80365f3c>] (_regmap_bus_read) from [<803656a4>] (_regmap_read+0x7c/0x144)
         r6:00000180 r5:9f1fc800 r4:9f1fc800 r3:80365f3c
        [<80365628>] (_regmap_read) from [<803657bc>] (regmap_read+0x50/0x70)
         r9:00000000 r8:9f732400 r7:9f1efe6c r6:9f1efe6c r5:00000180 r4:9f1fc800
        [<8036576c>] (regmap_read) from [<80452ac0>] (imx_get_temp+0x134/0x1a4)
         r6:9f1efeb4 r5:9f1fc800 r4:9e95f910 r3:00000001
        [<8045298c>] (imx_get_temp) from [<8044e11c>] (thermal_zone_get_temp+0x58/0x74)
         r7:9f72ef40 r6:9f1efeb4 r5:9e93d5e8 r4:9e93d400
        [<8044e0c4>] (thermal_zone_get_temp) from [<8044fd14>] (thermal_zone_device_update+0x34/0xec)
         r6:808e1978 r5:9e93d400 r4:9e93d608 r3:8045298c
        [<8044fce0>] (thermal_zone_device_update) from [<8044fde8>] (thermal_zone_device_check+0x1c/0x20)
         r5:9e481380 r4:9e93d608
        [<8044fdcc>] (thermal_zone_device_check) from [<80038d50>] (process_one_work+0x160/0x3d4)
        [<80038bf0>] (process_one_work) from [<80039754>] (worker_thread+0x5c/0x4f4)
         r10:9f72ef40 r9:00000008 r8:9e481380 r7:9e481398 r6:9f72ef40 r5:9f1ee020
         r4:9f72ef54
        [<800396f8>] (worker_thread) from [<8003e020>] (kthread+0xf0/0x108)
         r10:00000000 r9:00000000 r8:00000000 r7:800396f8 r6:9e481380 r5:00000000
         r4:9e4f2ec0
        [<8003df30>] (kthread) from [<8000eb60>] (ret_from_fork+0x14/0x34)
         r7:00000000 r6:00000000 r5:8003df30 r4:9e4f2ec0
        Code: e3140040 1a00001a e3140020 1a000016 (e596002c)
        ---[ end trace 193c15c2494ec960 ]---
      
      Fixes: bdb0066d (mfd: syscon: Decouple syscon interface from platform devices)
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      c6b570d9
    • S
      ata: Add a new flag to destinguish sas controller · 5067c046
      Shaohua Li 提交于
      SAS controller has its own tag allocation, which doesn't directly match to ATA
      tag, so SAS and SATA have different code path for ata tags. Originally we use
      port->scsi_host (98bd4be1) to destinguish SAS controller, but libsas set
      ->scsi_host too, so we can't use it for the destinguish, we add a new flag for
      this purpose.
      
      Without this patch, the following oops can happen because scsi-mq uses
      a host-wide tag map shared among all devices with some integer tag
      values >= ATA_MAX_QUEUE.  These unexpectedly high tag values cause
      __ata_qc_from_tag() to return NULL, which is then dereferenced in
      ata_qc_new_init().
      
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
        IP: [<ffffffff804fd46e>] ata_qc_new_init+0x3e/0x120
        PGD 32adf0067 PUD 32adf1067 PMD 0
        Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
        Modules linked in: iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi igb
        i2c_algo_bit ptp pps_core pm80xx libsas scsi_transport_sas sg coretemp
        eeprom w83795 i2c_i801
        CPU: 4 PID: 1450 Comm: cydiskbench Not tainted 4.0.0-rc3 #1
        Hardware name: Supermicro X8DTH-i/6/iF/6F/X8DTH, BIOS 2.1b       05/04/12
        task: ffff8800ba86d500 ti: ffff88032a064000 task.ti: ffff88032a064000
        RIP: 0010:[<ffffffff804fd46e>]  [<ffffffff804fd46e>] ata_qc_new_init+0x3e/0x120
        RSP: 0018:ffff88032a067858  EFLAGS: 00010046
        RAX: 0000000000000000 RBX: ffff8800ba0d2230 RCX: 000000000000002a
        RDX: ffffffff80505ae0 RSI: 0000000000000020 RDI: ffff8800ba0d2230
        RBP: ffff88032a067868 R08: 0000000000000201 R09: 0000000000000001
        R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800ba0d0000
        R13: ffff8800ba0d2230 R14: ffffffff80505ae0 R15: ffff8800ba0d0000
        FS:  0000000041223950(0063) GS:ffff88033e480000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
        CR2: 0000000000000058 CR3: 000000032a0a3000 CR4: 00000000000006e0
        Stack:
         ffff880329eee758 ffff880329eee758 ffff88032a0678a8 ffffffff80502dad
         ffff8800ba167978 ffff880329eee758 ffff88032bf9c520 ffff8800ba167978
         ffff88032bf9c520 ffff88032bf9a290 ffff88032a0678b8 ffffffff80506909
        Call Trace:
         [<ffffffff80502dad>] ata_scsi_translate+0x3d/0x1b0
         [<ffffffff80506909>] ata_sas_queuecmd+0x149/0x2a0
         [<ffffffffa0046650>] sas_queuecommand+0xa0/0x1f0 [libsas]
         [<ffffffff804ea544>] scsi_dispatch_cmd+0xd4/0x1a0
         [<ffffffff804eb50f>] scsi_queue_rq+0x66f/0x7f0
         [<ffffffff803e5098>] __blk_mq_run_hw_queue+0x208/0x3f0
         [<ffffffff803e54b8>] blk_mq_run_hw_queue+0x88/0xc0
         [<ffffffff803e5c74>] blk_mq_insert_request+0xc4/0x130
         [<ffffffff803e0b63>] blk_execute_rq_nowait+0x73/0x160
         [<ffffffffa0023fca>] sg_common_write+0x3da/0x720 [sg]
         [<ffffffffa0025100>] sg_new_write+0x250/0x360 [sg]
         [<ffffffffa0025feb>] sg_write+0x13b/0x450 [sg]
         [<ffffffff8032ec91>] vfs_write+0xd1/0x1b0
         [<ffffffff8032ee54>] SyS_write+0x54/0xc0
         [<ffffffff80689932>] system_call_fastpath+0x12/0x17
      
      tj: updated description.
      
      Fixes: 12cb5ce1 ("libata: use blk taging")
      Reported-and-tested-by: NTony Battersby <tonyb@cybernetics.com>
      Signed-off-by: NShaohua Li <shli@fb.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      5067c046
  10. 19 3月, 2015 5 次提交