1. 20 3月, 2017 1 次提交
    • J
      scsi: libsas: fix ata xfer length · 9702c67c
      John Garry 提交于
      The total ata xfer length may not be calculated properly, in that we do
      not use the proper method to get an sg element dma length.
      
      According to the code comment, sg_dma_len() should be used after
      dma_map_sg() is called.
      
      This issue was found by turning on the SMMUv3 in front of the hisi_sas
      controller in hip07. Multiple sg elements were being combined into a
      single element, but the original first element length was being use as
      the total xfer length.
      
      Cc: <stable@vger.kernel.org>
      Fixes: ff2aeb1e ("libata: convert to chained sg")
      Signed-off-by: NJohn Garry <john.garry@huawei.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      9702c67c
  2. 07 2月, 2017 1 次提交
  3. 28 1月, 2017 1 次提交
  4. 21 7月, 2016 1 次提交
    • W
      scsi:libsas: fix oops caused by assigning a freed task to ->lldd_task · 354a086d
      Wei Fang 提交于
      A freed task has been assigned to ->lldd_task when lldd_execute_task()
      failed in sas_ata_qc_issue(), and access of ->lldd_task will cause an
      oops:
      
      Call trace:
      [<ffffffc000641f64>] sas_ata_post_internal+0x6c/0x150
      [<ffffffc0006c0d64>] ata_exec_internal_sg+0x32c/0x588
      [<ffffffc0006c1048>] ata_exec_internal+0x88/0xe8
      [<ffffffc0006c13b4>] ata_dev_read_id+0x204/0x5e0
      [<ffffffc0006c17f0>] ata_dev_reread_id+0x60/0xc8
      [<ffffffc0006c3098>] ata_dev_revalidate+0x88/0x1e0
      [<ffffffc0006cf828>] ata_eh_recover+0xcf8/0x13a8
      [<ffffffc0006d075c>] ata_do_eh+0x5c/0xe0
      [<ffffffc0006d0828>] ata_std_error_handler+0x48/0x98
      [<ffffffc0006d042c>] ata_scsi_port_error_handler+0x474/0x658
      [<ffffffc000641b78>] async_sas_ata_eh+0x50/0x80
      [<ffffffc0000ca664>] async_run_entry_fn+0x64/0x180
      [<ffffffc0000c085c>] process_one_work+0x164/0x438
      [<ffffffc0000c0c74>] worker_thread+0x144/0x4b0
      [<ffffffc0000c70fc>] kthread+0xfc/0x110
      
      Fix this by reassigning NULL to ->lldd_task in error path.
      Signed-off-by: NWei Fang <fangwei1@huawei.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      354a086d
  5. 14 7月, 2016 1 次提交
  6. 10 5月, 2016 2 次提交
  7. 20 3月, 2015 1 次提交
    • 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
  8. 07 3月, 2015 1 次提交
    • J
      libsas: Fix Kernel Crash in smp_execute_task · 6302ce4d
      James Bottomley 提交于
      This crash was reported:
      
      [  366.947370] sd 3:0:1:0: [sdb] Spinning up disk....
      [  368.804046] BUG: unable to handle kernel NULL pointer dereference at           (null)
      [  368.804072] IP: [<ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b
      [  368.804098] PGD 0
      [  368.804114] Oops: 0002 [#1] SMP
      [  368.804143] CPU 1
      [  368.804151] Modules linked in: sg netconsole s3g(PO) uinput joydev hid_multitouch usbhid hid snd_hda_codec_via cpufreq_userspace cpufreq_powersave cpufreq_stats uhci_hcd cpufreq_conservative snd_hda_intel snd_hda_codec snd_hwdep snd_pcm sdhci_pci snd_page_alloc sdhci snd_timer snd psmouse evdev serio_raw pcspkr soundcore xhci_hcd shpchp s3g_drm(O) mvsas mmc_core ahci libahci drm i2c_core acpi_cpufreq mperf video processor button thermal_sys dm_dmirror exfat_fs exfat_core dm_zcache dm_mod padlock_aes aes_generic padlock_sha iscsi_target_mod target_core_mod configfs sswipe libsas libata scsi_transport_sas picdev via_cputemp hwmon_vid fuse parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 sd_mod crc_t10dif usb_storage scsi_mod ehci_hcd usbcore usb_common
      [  368.804749]
      [  368.804764] Pid: 392, comm: kworker/u:3 Tainted: P        W  O 3.4.87-logicube-ng.22 #1 To be filled by O.E.M. To be filled by O.E.M./EPIA-M920
      [  368.804802] RIP: 0010:[<ffffffff81358457>]  [<ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b
      [  368.804827] RSP: 0018:ffff880117001cc0  EFLAGS: 00010246
      [  368.804842] RAX: 0000000000000000 RBX: ffff8801185030d0 RCX: ffff88008edcb420
      [  368.804857] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff8801185030d4
      [  368.804873] RBP: ffff8801181531c0 R08: 0000000000000020 R09: 00000000fffffffe
      [  368.804885] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801185030d4
      [  368.804899] R13: 0000000000000002 R14: ffff880117001fd8 R15: ffff8801185030d8
      [  368.804916] FS:  0000000000000000(0000) GS:ffff88011fc80000(0000) knlGS:0000000000000000
      [  368.804931] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [  368.804946] CR2: 0000000000000000 CR3: 000000000160b000 CR4: 00000000000006e0
      [  368.804962] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  368.804978] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  368.804995] Process kworker/u:3 (pid: 392, threadinfo ffff880117000000, task ffff8801181531c0)
      [  368.805009] Stack:
      [  368.805017]  ffff8801185030d8 0000000000000000 ffffffff8161ddf0 ffffffff81056f7c
      [  368.805062]  000000000000b503 ffff8801185030d0 ffff880118503000 0000000000000000
      [  368.805100]  ffff8801185030d0 ffff8801188b8000 ffff88008edcb420 ffffffff813583ac
      [  368.805135] Call Trace:
      [  368.805153]  [<ffffffff81056f7c>] ? up+0xb/0x33
      [  368.805168]  [<ffffffff813583ac>] ? mutex_lock+0x16/0x25
      [  368.805194]  [<ffffffffa018c414>] ? smp_execute_task+0x4e/0x222 [libsas]
      [  368.805217]  [<ffffffffa018ce1c>] ? sas_find_bcast_dev+0x3c/0x15d [libsas]
      [  368.805240]  [<ffffffffa018ce4f>] ? sas_find_bcast_dev+0x6f/0x15d [libsas]
      [  368.805264]  [<ffffffffa018e989>] ? sas_ex_revalidate_domain+0x37/0x2ec [libsas]
      [  368.805280]  [<ffffffff81355a2a>] ? printk+0x43/0x48
      [  368.805296]  [<ffffffff81359a65>] ? _raw_spin_unlock_irqrestore+0xc/0xd
      [  368.805318]  [<ffffffffa018b767>] ? sas_revalidate_domain+0x85/0xb6 [libsas]
      [  368.805336]  [<ffffffff8104e5d9>] ? process_one_work+0x151/0x27c
      [  368.805351]  [<ffffffff8104f6cd>] ? worker_thread+0xbb/0x152
      [  368.805366]  [<ffffffff8104f612>] ? manage_workers.isra.29+0x163/0x163
      [  368.805382]  [<ffffffff81052c4e>] ? kthread+0x79/0x81
      [  368.805399]  [<ffffffff8135fea4>] ? kernel_thread_helper+0x4/0x10
      [  368.805416]  [<ffffffff81052bd5>] ? kthread_flush_work_fn+0x9/0x9
      [  368.805431]  [<ffffffff8135fea0>] ? gs_change+0x13/0x13
      [  368.805442] Code: 83 7d 30 63 7e 04 f3 90 eb ab 4c 8d 63 04 4c 8d 7b 08 4c 89 e7 e8 fa 15 00 00 48 8b 43 10 4c 89 3c 24 48 89 63 10 48 89 44 24 08 <48> 89 20 83 c8 ff 48 89 6c 24 10 87 03 ff c8 74 35 4d 89 ee 41
      [  368.805851] RIP  [<ffffffff81358457>] __mutex_lock_common.isra.7+0x9c/0x15b
      [  368.805877]  RSP <ffff880117001cc0>
      [  368.805886] CR2: 0000000000000000
      [  368.805899] ---[ end trace b720682065d8f4cc ]---
      
      It's directly caused by 89d3cf6a [SCSI] libsas: add mutex for SMP task
      execution, but shows a deeper cause: expander functions expect to be able to
      cast to and treat domain devices as expanders.  The correct fix is to only do
      expander discover when we know we've got an expander device to avoid wrongly
      casting a non-expander device.
      Reported-by: NPraveen Murali <pmurali@logicube.com>
      Tested-by: NPraveen Murali <pmurali@logicube.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      6302ce4d
  9. 04 12月, 2014 1 次提交
  10. 27 11月, 2014 1 次提交
    • C
      libsas: remove task_collector mode · 79855d17
      Christoph Hellwig 提交于
      The task_collector mode (or "latency_injector", (C) Dan Willians) is an
      optional I/O path in libsas that queues up scsi commands instead of
      directly sending it to the hardware.  It generall increases latencies
      to in the optiomal case slightly reduce mmio traffic to the hardware.
      
      Only the obsolete aic94xx driver and the mvsas driver allowed to use
      it without recompiling the kernel, and most drivers didn't support it
      at all.
      
      Remove the giant blob of code to allow better optimizations for scsi-mq
      in the future.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NHannes Reinecke <hare@suse.de>
      Acked-by: NDan Williams <dan.j.williams@intel.com>
      79855d17
  11. 24 11月, 2014 2 次提交
  12. 12 11月, 2014 3 次提交
  13. 06 11月, 2014 1 次提交
  14. 25 7月, 2014 1 次提交
  15. 18 7月, 2014 1 次提交
  16. 19 3月, 2014 1 次提交
    • D
      libata, libsas: kill pm_result and related cleanup · bc6e7c4b
      Dan Williams 提交于
      Tejun says:
        "At least for libata, worrying about suspend/resume failures don't make
         whole lot of sense.  If suspend failed, just proceed with suspend.  If
         the device can't be woken up afterwards, that's that.  There isn't
         anything we could have done differently anyway.  The same for resume, if
         spinup fails, the device is dud and the following commands will invoke
         EH actions and will eventually fail.  Again, there really isn't any
         *choice* to make.  Just making sure the errors are handled gracefully
         (ie. don't crash) and the following commands are handled correctly
         should be enough."
      
      The only libata user that actually cares about the result from a suspend
      operation is libsas.  However, it only cares about whether queuing a new
      operation collides with an in-flight one.  All libsas does with the
      error is retry, but we can just let libata wait for the previous
      operation before continuing.
      
      Other cleanups include:
      1/ Unifying all ata port pm operations on an ata_port_pm_ prefix
      2/ Marking all ata port pm helper routines as returning void, only
         ata_port_pm_ entry points need to fake a 0 return value.
      3/ Killing ata_port_{suspend|resume}_common() in favor of calling
         ata_port_request_pm() directly
      4/ Killing the wrappers that just do a to_ata_port() conversion
      5/ Clearly marking the entry points that do async operations with an
        _async suffix.
      
      Reference: http://marc.info/?l=linux-scsi&m=138995409532286&w=2
      
      Cc: Phillip Susi <psusi@ubuntu.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Suggested-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NTodd Brandt <todd.e.brandt@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      bc6e7c4b
  17. 16 3月, 2014 1 次提交
  18. 27 11月, 2013 1 次提交
  19. 24 11月, 2013 1 次提交
    • K
      block: Kill bio_segments()/bi_vcnt usage · 458b76ed
      Kent Overstreet 提交于
      When we start sharing biovecs, keeping bi_vcnt accurate for splits is
      going to be error prone - and unnecessary, if we refactor some code.
      
      So bio_segments() has to go - but most of the existing users just needed
      to know if the bio had multiple segments, which is easier - add a
      bio_multiple_segments() for them.
      
      (Two of the current uses of bio_segments() are going to go away in a
      couple patches, but the current implementation of bio_segments() is
      unsafe as soon as we start doing driver conversions for immutable
      biovecs - so implement a dumb version for bisectability, it'll go away
      in a couple patches)
      Signed-off-by: NKent Overstreet <kmo@daterainc.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Nagalakshmi Nandigama <Nagalakshmi.Nandigama@lsi.com>
      Cc: Sreekanth Reddy <Sreekanth.Reddy@lsi.com>
      Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
      458b76ed
  20. 05 6月, 2013 1 次提交
    • J
      [SCSI] libsas: implement > 16 byte CDB support · e73823f7
      James Bottomley 提交于
      Remove the arbitrary expectation in libsas that all SCSI commands are 16 bytes
      or less.  Instead do all copies via cmd->cmd_len (and use a pointer to this in
      the libsas task instead of a copy).  Note that this still doesn't enable > 16
      byte CDB support in the underlying drivers because their internal format has
      to be fixed and the wire format of > 16 byte CDBs according to the SAS spec is
      different.  the libsas drivers (isci, aic94xx, mvsas and pm8xxx are all
      updated for this change.
      
      Cc: Lukasz Dorau <lukasz.dorau@intel.com>
      Cc: Maciej Patelczyk <maciej.patelczyk@intel.com>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Jack Wang <xjtuwjp@gmail.com>
      Cc: Lindar Liu <lindar_liu@usish.com>
      Cc: Xiangliang Yu <yuxiangl@marvell.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      e73823f7
  21. 10 5月, 2013 1 次提交
    • J
      [SCSI] sas: unify the pointlessly separated enums sas_dev_type and sas_device_type · aa9f8328
      James Bottomley 提交于
      These enums have been separate since the dawn of SAS, mainly because the
      latter is a procotol only enum and the former includes additional state
      for libsas.  The dichotomy causes endless confusion about which one you
      should use where and leads to pointless warnings like this:
      
      drivers/scsi/mvsas/mv_sas.c: In function 'mvs_update_phyinfo':
      drivers/scsi/mvsas/mv_sas.c:1162:34: warning: comparison between 'enum sas_device_type' and 'enum sas_dev_type' [-Wenum-compare]
      
      Fix by eliminating one of them.  The one kept is effectively the sas.h
      one, but call it sas_device_type and make sure the enums are all
      properly namespaced with the SAS_ prefix.
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      aa9f8328
  22. 06 4月, 2013 2 次提交
  23. 24 3月, 2013 1 次提交
    • K
      block: Remove some unnecessary bi_vcnt usage · 2f477877
      Kent Overstreet 提交于
      More prep work for immutable bvecs/effecient bio splitting - usage of
      bi_vcnt has to be auditing, so getting rid of all the unnecessary usage
      makes that easier.
      
      Plus, bio_segments() is really what this code wanted, as it respects the
      current value of bi_idx.
      Signed-off-by: NKent Overstreet <koverstreet@google.com>
      CC: Jens Axboe <axboe@kernel.dk>
      CC: Eric Moore <Eric.Moore@lsi.com>
      CC: "James E.J. Bottomley" <JBottomley@parallels.com>
      CC: linux-scsi@vger.kernel.org
      2f477877
  24. 19 11月, 2012 1 次提交
  25. 24 8月, 2012 2 次提交
  26. 20 7月, 2012 9 次提交