1. 20 7月, 2012 1 次提交
  2. 08 7月, 2012 2 次提交
    • D
      [SCSI] libsas: fix taskfile corruption in sas_ata_qc_fill_rtf · 6ef1b512
      Dan Williams 提交于
      fill_result_tf() grabs the taskfile flags from the originating qc which
      sas_ata_qc_fill_rtf() promptly overwrites.  The presence of an
      ata_taskfile in the sata_device makes it tempting to just copy the full
      contents in sas_ata_qc_fill_rtf().  However, libata really only wants
      the fis contents and expects the other portions of the taskfile to not
      be touched by ->qc_fill_rtf.  To that end store a fis buffer in the
      sata_device and use ata_tf_from_fis() like every other ->qc_fill_rtf()
      implementation.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: NPraveen Murali <pmurali@logicube.com>
      Tested-by: NPraveen Murali <pmurali@logicube.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      6ef1b512
    • M
      [SCSI] Fix NULL dereferences in scsi_cmd_to_driver · 222a806a
      Mark Rustad 提交于
      Avoid crashing if the private_data pointer happens to be NULL. This has
      been seen sometimes when a host reset happens, notably when there are
      many LUNs:
      
      host3: Assigned Port ID 0c1601
      scsi host3: libfc: Host reset succeeded on port (0c1601)
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000350
      IP: [<ffffffff81352bb8>] scsi_send_eh_cmnd+0x58/0x3a0
      <snip>
      Process scsi_eh_3 (pid: 4144, threadinfo ffff88030920c000, task ffff880326b160c0)
      Stack:
       000000010372e6ba 0000000000000282 000027100920dca0 ffffffffa0038ee0
       0000000000000000 0000000000030003 ffff88030920dc80 ffff88030920dc80
       00000002000e0000 0000000a00004000 ffff8803242f7760 ffff88031326ed80
      Call Trace:
       [<ffffffff8105b590>] ? lock_timer_base+0x70/0x70
       [<ffffffff81352fbe>] scsi_eh_tur+0x3e/0xc0
       [<ffffffff81353a36>] scsi_eh_test_devices+0x76/0x170
       [<ffffffff81354125>] scsi_eh_host_reset+0x85/0x160
       [<ffffffff81354291>] scsi_eh_ready_devs+0x91/0x110
       [<ffffffff813543fd>] scsi_unjam_host+0xed/0x1f0
       [<ffffffff813546a8>] scsi_error_handler+0x1a8/0x200
       [<ffffffff81354500>] ? scsi_unjam_host+0x1f0/0x1f0
       [<ffffffff8106ec3e>] kthread+0x9e/0xb0
       [<ffffffff81509264>] kernel_thread_helper+0x4/0x10
       [<ffffffff8106eba0>] ? kthread_freezable_should_stop+0x70/0x70
       [<ffffffff81509260>] ? gs_change+0x13/0x13
      Code: 25 28 00 00 00 48 89 45 c8 31 c0 48 8b 87 80 00 00 00 48 8d b5 60 ff ff ff 89 d1 48 89 fb 41 89 d6 4c 89 fa 48 8b 80 b8 00 00 00
       <48> 8b 80 50 03 00 00 48 8b 00 48 89 85 38 ff ff ff 48 8b 07 4c
      RIP  [<ffffffff81352bb8>] scsi_send_eh_cmnd+0x58/0x3a0
       RSP <ffff88030920dc50>
      CR2: 0000000000000350
      Signed-off-by: NMark Rustad <mark.d.rustad@intel.com>
      Tested-by: NMarcus Dennis <marcusx.e.dennis@intel.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      222a806a
  3. 23 6月, 2012 1 次提交
    • A
      SCSI & usb-storage: add try_rc_10_first flag · 6a0bdffa
      Alan Stern 提交于
      Several bug reports have been received recently for USB mass-storage
      devices that don't handle READ CAPACITY(16) commands properly.  They
      report bogus sizes, in some cases becoming unusable as a result.
      
      The bugs were triggered by commit
      09b6b51b (SCSI & usb-storage: add
      flags for VPD pages and REPORT LUNS), which caused usb-storage to stop
      overriding the SCSI level reported by devices.  By default, the sd
      driver will try READ CAPACITY(16) first for any device whose level is
      above SCSI_SPC_2.
      
      It seems likely that any device large enough to require the use of
      READ CAPACITY(16) (i.e., 2 TB or more) would be able to handle READ
      CAPACITY(10) commands properly.  Indeed, I don't know of any devices
      that don't handle READ CAPACITY(10) properly.
      
      Therefore this patch (as1559) adds a new flag telling the sd driver
      to try READ CAPACITY(10) before READ CAPACITY(16), and sets this flag
      for every USB mass-storage device.  If a device really is larger than
      2 TB, sd will fall back to READ CAPACITY(16) just as it used to.
      
      This fixes Bugzilla #43391.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NHans de Goede <hdegoede@redhat.com>
      CC: "James E.J. Bottomley" <JBottomley@parallels.com>
      CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a0bdffa
  4. 23 5月, 2012 3 次提交
    • R
      [SCSI] fcoe, bnx2fc, libfcoe: SW FCoE and bnx2fc use FCoE Syfs · 8d55e507
      Robert Love 提交于
      This patch has the SW FCoE driver and the bnx2fc
      driver make use of the new fcoe_sysfs API added
      earlier in this patch series.
      
      After this patch a fcoe_ctlr_device is allocated with
      private data in this order.
      
      +------------------+   +------------------+
      | fcoe_ctlr_device |   | fcoe_ctlr_device |
      +------------------+   +------------------+
      | fcoe_ctlr        |   | fcoe_ctlr        |
      +------------------+   +------------------+
      | fcoe_interface   |   | bnx2fc_interface |
      +------------------+   +------------------+
      
      libfcoe also takes part in this new model since it
      discovers and manages fcoe_fcf instances. The memory
      allocation is different for FCFs. I didn't want to
      impact libfcoe's fcoe_fcf processing, so this patch
      creates fcoe_fcf_device instances for each discovered
      fcoe_fcf. The two are paired using a (void * priv)
      member of the fcoe_ctlr_device. This allows libfcoe
      to continue maintaining its list of fcoe_fcf instances
      and simply attaches and detaches them from existing
      or new fcoe_fcf_device instances.
      Signed-off-by: NRobert Love <robert.w.love@intel.com>
      Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      8d55e507
    • R
      [SCSI] libfcoe: Add fcoe_sysfs · 9a74e884
      Robert Love 提交于
      This patch adds a 'fcoe bus' infrastructure to the kernel
      that is driven by changes to libfcoe which allow LLDs to
      present FIP (FCoE Initialization Protocol) discovered
      entities and their attributes to user space via sysfs.
      
      This patch adds the following APIs-
      
      fcoe_ctlr_device_add
      fcoe_ctlr_device_delete
      fcoe_fcf_device_add
      fcoe_fcf_device_delete
      
      They allow the LLD to expose the FCoE ENode Controller
      and any discovered FCFs (Fibre Channel Forwarders, e.g.
      FCoE switches) to the user. Each of these new devices
      has their own bus_type so that they are grouped together
      for easy lookup from a user space application. Each
      new class has an attribute_group to expose attributes
      for any created instances. The attributes are-
      
      fcoe_ctlr_device
      * fcf_dev_loss_tmo
      * lesb_link_fail
      * lesb_vlink_fail
      * lesb_miss_fka
      * lesb_symb_err
      * lesb_err_block
      * lesb_fcs_error
      
      fcoe_fcf_device
      * fabric_name
      * switch_name
      * priority
      * selected
      * fc_map
      * vfid
      * mac
      * fka_peroid
      * fabric_state
      * dev_loss_tmo
      
      A device loss infrastructre similar to the FC Transport's
      is also added by this patch. It is nice to have so that a
      link flapping adapter doesn't continually advance the count
      used to identify the discovered FCF. FCFs will exist in a
      "Disconnected" state until either the timer expires or the
      FCF is rediscovered and becomes "Connected."
      
      This patch generates a few checkpatch.pl WARNINGS that
      I'm not sure what to do about. They're macros modeled
      around the FC Transport attribute building macros, which
      have the same 'feature' where the caller can ommit a cast
      in the argument list and no cast occurs in the code. I'm
      not sure how to keep the code condensed while keeping the
      macros. Any advice would be appreciated.
      Signed-off-by: NRobert Love <robert.w.love@intel.com>
      Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      9a74e884
    • R
      [SCSI] fcoe: Allocate fcoe_ctlr with fcoe_interface, not as a member · 619fe4be
      Robert Love 提交于
      Currently the fcoe_ctlr associated with an interface is allocated
      as a member of struct fcoe_interface. This causes problems when
      attempting to use the new fcoe_sysfs APIs which allow us to allocate
      the fcoe_interface as private data to the fcoe_ctlr_device instance.
      The problem is that libfcoe wants to be able use pointer math to find a
      fcoe_ctlr's fcoe_ctlr_device as well as finding a fcoe_ctlr_device's
      assocated fcoe_ctlr. To do this we need to allocate the
      fcoe_ctlr_device, with private data for the LLD. The private data
      contains the fcoe_ctlr and its private data is the fcoe_interface.
      This patch only allocates the fcoe_interface with the fcoe_ctlr, the
      fcoe_ctlr_device will be added in a later patch, which will complete
      the below diagram-
      
      +------------------+
      | fcoe_ctlr_device |
      +------------------+
      | fcoe_ctlr        |
      +------------------+
      | fcoe_interface   |
      +------------------+
      
      This prep work will allow us to go from a fcoe_ctlr_device instance
      to its fcoe_ctlr as well as from a fcoe_ctlr to its fcoe_ctlr_device
      once the fcoe_sysfs API is in use (later patches in this series).
      Signed-off-by: NRobert Love <robert.w.love@intel.com>
      Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      619fe4be
  5. 18 5月, 2012 1 次提交
  6. 25 4月, 2012 1 次提交
  7. 23 4月, 2012 2 次提交
    • D
      [SCSI] libsas, libata: fix start of life for a sas ata_port · b2024459
      Dan Williams 提交于
      This changes the ordering of initialization and probing events from:
        1/ allocate rphy in PORTE_BYTES_DMAED, DISCE_REVALIDATE_DOMAIN
        2/ allocate ata_port and schedule port probe in DISCE_PROBE
      ...to:
        1/ allocate ata_port in PORTE_BYTES_DMAED, DISCE_REVALIDATE_DOMAIN
        2/ allocate rphy in PORTE_BYTES_DMAED, DISCE_REVALIDATE_DOMAIN
        3/ schedule port probe in DISCE_PROBE
      
      This ordering prevents PHYE_SIGNAL_LOSS_EVENTS from sneaking in to
      destrory ata devices before they have been fully initialized:
      
        BUG: unable to handle kernel paging request at 0000000000003b10
        IP: [<ffffffffa0053d7e>] sas_ata_end_eh+0x12/0x5e [libsas]
        ...
        [<ffffffffa004d1af>] sas_unregister_common_dev+0x78/0xc9 [libsas]
        [<ffffffffa004d4d4>] sas_unregister_dev+0x4f/0xad [libsas]
        [<ffffffffa004d5b1>] sas_unregister_domain_devices+0x7f/0xbf [libsas]
        [<ffffffffa004c487>] sas_deform_port+0x61/0x1b8 [libsas]
        [<ffffffffa004bed0>] sas_phye_loss_of_signal+0x29/0x2b [libsas]
      
      ...and kills the awkward "sata domain_device briefly existing in the
      domain without an ata_port" state.
      Reported-by: NMichal Kosciowski <michal.kosciowski@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Acked-by: NJeff Garzik <jgarzik@redhat.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      b2024459
    • D
      [SCSI] libsas: introduce sas_work to fix sas_drain_work vs sas_queue_work · 22b9153f
      Dan Williams 提交于
      When requeuing work to a draining workqueue the last work instance may
      not be idle, so sas_queue_work() must not touch work->entry.  Introduce
      sas_work with a drain_node list_head to have a private list for
      collecting work deferred due to drain collision.
      
      Fixes reports like:
        BUG: unable to handle kernel NULL pointer dereference at           (null)
        IP: [<ffffffff810410d4>] process_one_work+0x2e/0x338
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      22b9153f
  8. 16 4月, 2012 1 次提交
  9. 28 3月, 2012 1 次提交
  10. 27 3月, 2012 2 次提交
  11. 24 3月, 2012 1 次提交
  12. 16 3月, 2012 1 次提交
    • P
      device.h: audit and cleanup users in main include dir · 313162d0
      Paul Gortmaker 提交于
      The <linux/device.h> header includes a lot of stuff, and
      it in turn gets a lot of use just for the basic "struct device"
      which appears so often.
      
      Clean up the users as follows:
      
      1) For those headers only needing "struct device" as a pointer
      in fcn args, replace the include with exactly that.
      
      2) For headers not really using anything from device.h, simply
      delete the include altogether.
      
      3) For headers relying on getting device.h implicitly before
      being included themselves, now explicitly include device.h
      
      4) For files in which doing #1 or #2 uncovers an implicit
      dependency on some other header, fix by explicitly adding
      the required header(s).
      
      Any C files that were implicitly relying on device.h to be
      present have already been dealt with in advance.
      
      Total removals from #1 and #2: 51.  Total additions coming
      from #3: 9.  Total other implicit dependencies from #4: 7.
      
      As of 3.3-rc1, there were 110, so a net removal of 42 gives
      about a 38% reduction in device.h presence in include/*
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      313162d0
  13. 05 3月, 2012 1 次提交
    • P
      BUG: headers with BUG/BUG_ON etc. need linux/bug.h · 187f1882
      Paul Gortmaker 提交于
      If a header file is making use of BUG, BUG_ON, BUILD_BUG_ON, or any
      other BUG variant in a static inline (i.e. not in a #define) then
      that header really should be including <linux/bug.h> and not just
      expecting it to be implicitly present.
      
      We can make this change risk-free, since if the files using these
      headers didn't have exposure to linux/bug.h already, they would have
      been causing compile failures/warnings.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      187f1882
  14. 01 3月, 2012 10 次提交
  15. 26 2月, 2012 2 次提交
  16. 20 2月, 2012 10 次提交