1. 24 3月, 2016 1 次提交
    • C
      mpt3sas: Don't overreach ioc->reply_post[] during initialization · 5ec8a175
      Calvin Owens 提交于
      In _base_make_ioc_operational(), we walk ioc->reply_queue_list and pull
      a pointer out of successive elements of ioc->reply_post[] for each entry
      in that list if RDPQ is enabled.
      
      Since the code pulls the pointer for the next iteration at the bottom of
      the loop, it triggers the a KASAN dump on the final iteration:
      
          BUG: KASAN: slab-out-of-bounds in _base_make_ioc_operational+0x47b7/0x47e0 [mpt3sas] at addr ffff880754816ab0
          Read of size 8 by task modprobe/305
          <snip>
          Call Trace:
           [<ffffffff81dfc591>] dump_stack+0x4d/0x6c
           [<ffffffff814c9689>] print_trailer+0xf9/0x150
           [<ffffffff814ceda4>] object_err+0x34/0x40
           [<ffffffff814d1231>] kasan_report_error+0x221/0x530
           [<ffffffff814d1673>] __asan_report_load8_noabort+0x43/0x50
           [<ffffffffa0043637>] _base_make_ioc_operational+0x47b7/0x47e0 [mpt3sas]
           [<ffffffffa0049a51>] mpt3sas_base_attach+0x1991/0x2120 [mpt3sas]
           [<ffffffffa0053c93>] _scsih_probe+0xeb3/0x16b0 [mpt3sas]
           [<ffffffff81ebd047>] local_pci_probe+0xc7/0x170
           [<ffffffff81ebf2cf>] pci_device_probe+0x20f/0x290
           [<ffffffff820d50cd>] really_probe+0x17d/0x600
           [<ffffffff820d56a3>] __driver_attach+0x153/0x190
           [<ffffffff820cffac>] bus_for_each_dev+0x11c/0x1a0
           [<ffffffff820d421d>] driver_attach+0x3d/0x50
           [<ffffffff820d378a>] bus_add_driver+0x44a/0x5f0
           [<ffffffff820d666c>] driver_register+0x18c/0x3b0
           [<ffffffff81ebcb76>] __pci_register_driver+0x156/0x200
           [<ffffffffa00c8135>] _mpt3sas_init+0x135/0x1000 [mpt3sas]
           [<ffffffff81000423>] do_one_initcall+0x113/0x2b0
           [<ffffffff813caa5a>] do_init_module+0x1d0/0x4d8
           [<ffffffff81273909>] load_module+0x6729/0x8dc0
           [<ffffffff81276123>] SYSC_init_module+0x183/0x1a0
           [<ffffffff8127625e>] SyS_init_module+0xe/0x10
           [<ffffffff828fe7d7>] entry_SYSCALL_64_fastpath+0x12/0x6a
      
      Fix this by pulling the value at the beginning of the loop.
      Signed-off-by: NCalvin Owens <calvinowens@fb.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: NJens Axboe <axboe@fb.com>
      Acked-by: NChaitra Basappa <chaitra.basappa@broadcom.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      5ec8a175
  2. 22 3月, 2016 1 次提交
    • A
      aacraid: add missing curly braces · 548f0e65
      Arnd Bergmann 提交于
      gcc-6 warns about obviously wrong indentation for newly added code in
      aac_slave_configure():
      
      drivers/scsi/aacraid/linit.c: In function 'aac_slave_configure':
      drivers/scsi/aacraid/linit.c:458:3: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
         sdev->tagged_supported = 1;
         ^~~~
      drivers/scsi/aacraid/linit.c:455:4: note: ...this 'else' clause, but it is not
      
      gcc is correct, and evidently this was meant to be within the curly
      braces that should have been there to start with. This patch adds them,
      which avoids the warning and makes it clear what was intended here.
      
      Nothing changes in behavior because in the 'if' block, the
      sdev->tagged_supported flag is known to be set already.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 6bf3b630 ("aacraid: SCSI blk tag support")
      Reviewed-by: NRaghava Aditya Renukunta <raghavaaditya.renukunta@pmcs.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      548f0e65
  3. 19 3月, 2016 7 次提交
    • H
      scsi_common: do not clobber fixed sense information · ba083116
      Hannes Reinecke 提交于
      For fixed sense the information field is 32 bits, to we need to truncate
      the information field to avoid clobbering the sense code.
      
      Fixes: a1524f22 ("libata-eh: Set 'information' field for autosense")
      Cc: <stable@vger.kernel.org> #v4.1+
      Signed-off-by: NHannes Reinecke <hare@suse.com>
      Reviewed-by: NLee Duncan <lduncan@suse.com>
      Reviewed-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Reviewed-by: NEwan D. Milne <emilne@redhat.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      ba083116
    • A
      scsi: ufs: select CONFIG_NLS · c80fa12e
      Arnd Bergmann 提交于
      A recent change to ufshcd introduced a call to utf16s_to_utf8s, a
      function that is provided by the NLS module, so we get a link error when
      that is not present:
      
      drivers/scsi/built-in.o: In function `ufshcd_read_string_desc':
      :(.text+0x124d0): undefined reference to `utf16s_to_utf8s'
      
      This adds a Kconfig 'select' statement to avoid the build error.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: b573d484 ("scsi: ufs: add support to read device and string descriptors")
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      c80fa12e
    • A
      scsi: fc: use get/put_unaligned64 for wwn access · ef3fb242
      Arnd Bergmann 提交于
      A bug in the gcc-6.0 prerelease version caused at least one
      driver (lpfc) to have excessive stack usage when dealing with
      wwn data, on the ARM architecture.
      
      lpfc_scsi.c: In function 'lpfc_find_next_oas_lun':
      lpfc_scsi.c:117:1: warning: the frame size of 1152 bytes is larger than 1024 bytes [-Wframe-larger-than=]
      
      I have reported this as a gcc regression in
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
      
      However, using a better implementation of wwn_to_u64() not only
      helps with the particular gcc problem but also leads to better
      object code for any version or architecture.
      
      The kernel already provides get_unaligned_be64() and
      put_unaligned_be64() helper functions that provide an
      optimized implementation with the desired semantics.
      
      The lpfc_find_next_oas_lun() function in the example that
      grew from 1146 bytes to 5144 bytes when moving from gcc-5.3
      to gcc-6.0 is now 804 bytes, as the optimized
      get_unaligned_be64() load can be done in three instructions.
      The stack usage is now down to 28 bytes from 128 bytes with
      gcc-5.3 before.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NHannes Reinicke <hare@suse.de>
      Reviewed-by: NEwan Milne <emilne@redhat.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      ef3fb242
    • M
      fnic: move printk()s outside of the critical code section. · 14cee5b4
      Maurizio Lombardi 提交于
      This patch moves a printk() outside of the code section where interrupt
      are disabled. In some cases a flood of error messages may cause a kernel
      panic.  It also removes one of the printk()s because the same error
      message was printed twice.
      
      [709686.317197] Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 12
      [709686.317200] CPU: 12 PID: 1963 Comm: systemd-journal Tainted: GF          O--------------   3.10.0-229.el7.x86_64 #1
      [709686.317201] Hardware name: Cisco Systems Inc UCSB-B200-M3/UCSB-B200-M3, BIOS B200M3.2.2.3.6.030620151309 03/06/2015
      [709686.317206]  ffffffff8182b2e8 00000000392722ba ffff88046fcc5c48 ffffffff81603f36
      [709686.317209]  ffff88046fcc5cc8 ffffffff815fd7da 0000000000000010 ffff88046fcc5cd8
      [709686.317211]  ffff88046fcc5c78 00000000392722ba ffff88046fcc5c88 000000000000000c
      [709686.317212] Call Trace:
      [709686.317221]  <NMI>  [<ffffffff81603f36>] dump_stack+0x19/0x1b
      [709686.317223]  [<ffffffff815fd7da>] panic+0xd8/0x1e7
      [709686.317227]  [<ffffffff8110a760>] ? watchdog_enable_all_cpus.part.2+0x40/0x40
      [709686.317229]  [<ffffffff8110a822>] watchdog_overflow_callback+0xc2/0xd0
      [709686.317233]  [<ffffffff8114c901>] __perf_event_overflow+0xa1/0x250
      [709686.317235]  [<ffffffff8114d404>] perf_event_overflow+0x14/0x20
      [709686.317239]  [<ffffffff810301fd>] intel_pmu_handle_irq+0x1fd/0x410
      [709686.317242]  [<ffffffff811908d1>] ? unmap_kernel_range_noflush+0x11/0x20
      [709686.317246]  [<ffffffff81373574>] ? ghes_copy_tofrom_phys+0x124/0x210
      [709686.317249]  [<ffffffff8160cfcb>] perf_event_nmi_handler+0x2b/0x50
      [709686.317251]  [<ffffffff8160c719>] nmi_handle.isra.0+0x69/0xb0
      [709686.317252]  [<ffffffff8160c830>] do_nmi+0xd0/0x340
      [709686.317256]  [<ffffffff8160bb71>] end_repeat_nmi+0x1e/0x2e
      [709686.317260]  [<ffffffff812e24fd>] ? memcpy+0xd/0x110
      [709686.317263]  [<ffffffff812e24fd>] ? memcpy+0xd/0x110
      [709686.317265]  [<ffffffff812e24fd>] ? memcpy+0xd/0x110
      [709686.317269]  <<EOE>>  [<ffffffff8132c297>] ? vgacon_scroll+0x2d7/0x330
      [709686.317273]  [<ffffffff813a086c>] scrup+0xfc/0x110
      [709686.317275]  [<ffffffff813a0920>] lf+0xa0/0xb0
      [709686.317278]  [<ffffffff813a1b32>] vt_console_print+0x2d2/0x420
      [709686.317283]  [<ffffffff8106f4a1>] call_console_drivers.constprop.15+0x91/0xf0
      [709686.317287]  [<ffffffff8107069f>] console_unlock+0x3bf/0x400
      [709686.317291]  [<ffffffff81070996>] vprintk_emit+0x2b6/0x530
      [709686.317294]  [<ffffffff815fd961>] printk_emit+0x44/0x5b
      [709686.317297]  [<ffffffff81070d98>] devkmsg_writev+0x158/0x1d0
      [709686.317303]  [<ffffffff811c5ef9>] do_sync_readv_writev+0x79/0xd0
      [709686.317307]  [<ffffffff811c73ee>] do_readv_writev+0xce/0x260
      [709686.317310]  [<ffffffff811c8d18>] ? __sb_start_write+0x58/0x110
      [709686.317314]  [<ffffffff811c7615>] vfs_writev+0x35/0x60
      [709686.317318]  [<ffffffff811c776c>] SyS_writev+0x5c/0xd0
      [709686.317322]  [<ffffffff81613da9>] system_call_fastpath+0x16/0x1b
      Signed-off-by: NMaurizio Lombardi <mlombard@redhat.com>
      Reviewed-by: NLaurence Oberman <loberman@redhat.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      14cee5b4
    • A
      qla2xxx: avoid maybe_uninitialized warning · bc7095a9
      Arnd Bergmann 提交于
      The qlt_check_reserve_free_req() function produces an incorrect warning
      when CONFIG_PROFILE_ANNOTATED_BRANCHES is set:
      
      drivers/scsi/qla2xxx/qla_target.c: In function 'qlt_check_reserve_free_req':
      drivers/scsi/qla2xxx/qla_target.c:1887:3: error: 'cnt_in' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         ql_dbg(ql_dbg_io, vha, 0x305a,
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
             "qla_target(%d): There is no room in the request ring: vha->req->ring_index=%d, vha->req->cnt=%d, req_cnt=%d Req-out=%d Req-in=%d Req-Length=%d\n",
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
             vha->vp_idx, vha->req->ring_index,
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
             vha->req->cnt, req_cnt, cnt, cnt_in, vha->req->length);
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/scsi/qla2xxx/qla_target.c:1887:3: error: 'cnt' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      The problem is that gcc fails to track the state of the condition across
      an annotated branch.
      
      This slightly rearranges the code to move the second if() block
      into the first one, to avoid the warning while retaining the
      behavior of the code.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-By: NHimanshu Madhani <himanshu.madhani@qlogic.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      bc7095a9
    • A
      megaraid_sas: add missing curly braces in ioctl handler · 3deb9438
      Arnd Bergmann 提交于
      gcc-6 found a dubious indentation in the megasas_mgmt_fw_ioctl
      function:
      
      drivers/scsi/megaraid/megaraid_sas_base.c: In function 'megasas_mgmt_fw_ioctl':
      drivers/scsi/megaraid/megaraid_sas_base.c:6658:4: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
          kbuff_arr[i] = NULL;
          ^~~~~~~~~
      drivers/scsi/megaraid/megaraid_sas_base.c:6653:3: note: ...this 'if' clause, but it is not
         if (kbuff_arr[i])
         ^~
      
      The code is actually correct, as there is no downside in clearing a NULL
      pointer again.
      
      This clarifies the code and avoids the warning by adding extra curly
      braces.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 90dc9d98 ("megaraid_sas : MFI MPT linked list corruption fix")
      Reviewed-by: NHannes Reinecke <hare@suse.com>
      Acked-by: NSumit Saxena <sumit.saxena@broadcom.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      3deb9438
    • A
      lpfc: fix misleading indentation · aeb6641f
      Arnd Bergmann 提交于
      gcc-6 complains about the indentation of the lpfc_destroy_vport_work_array()
      call in lpfc_online(), which clearly doesn't look right:
      
      drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_online':
      drivers/scsi/lpfc/lpfc_init.c:2880:3: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
         lpfc_destroy_vport_work_array(phba, vports);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/scsi/lpfc/lpfc_init.c:2863:2: note: ...this 'if' clause, but it is not
        if (vports != NULL)
        ^~
      
      Looking at the patch that introduced this code, it's clear that the
      behavior is correct and the indentation is wrong.
      
      This fixes the indentation and adds curly braces around the previous
      if() block for clarity, as that is most likely what caused the code
      to be misindented in the first place.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 549e55cd ("[SCSI] lpfc 8.2.2 : Fix locking around HBA's port_list")
      Reviewed-by: NSebastian Herbszt <herbszt@gmx.de>
      Reviewed-by: NHannes Reinecke <hare@suse.com>
      Reviewed-by: NEwan D. Milne <emilne@redhat.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      aeb6641f
  4. 15 3月, 2016 23 次提交
  5. 11 3月, 2016 2 次提交
  6. 10 3月, 2016 1 次提交
  7. 09 3月, 2016 5 次提交
    • M
      cxlflash: Increase cmd_per_lun for better throughput · 83430833
      Manoj N. Kumar 提交于
      With the current value of cmd_per_lun at 16, the throughput
      over a single adapter is limited to around 150kIOPS.
      
      Increase the value of cmd_per_lun to 256 to improve
      throughput. With this change a single adapter is able to
      attain close to the maximum throughput (380kIOPS).
      Also change the number of RRQ entries that can be queued.
      Signed-off-by: NManoj N. Kumar <manoj@linux.vnet.ibm.com>
      Acked-by: NMatthew R. Ochs <mrochs@linux.vnet.ibm.com>
      Reviewed-by: NUma Krishnan <ukrishn@linux.vnet.ibm.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      83430833
    • M
      cxlflash: Fix to avoid unnecessary scan with internal LUNs · 603ecce9
      Manoj N. Kumar 提交于
      When switching to the internal LUN defined on the
      IBM CXL flash adapter, there is an unnecessary
      scan occurring on the second port. This scan leads
      to the following extra lines in the log:
      
      Dec 17 10:09:00 tul83p1 kernel: [ 3708.561134] cxlflash 0008:00:00.0: cxlflash_queuecommand: (scp=c0000000fc1f0f00) 11/1/0/0 cdb=(A0000000-00000000-10000000-00000000)
      Dec 17 10:09:00 tul83p1 kernel: [ 3708.561147] process_cmd_err: cmd failed afu_rc=32 scsi_rc=0 fc_rc=0 afu_extra=0xE, scsi_extra=0x0, fc_extra=0x0
      
      By definition, both of the internal LUNs are on the first port/channel.
      
      When the lun_mode is switched to internal LUN the
      same value for host->max_channel is retained. This
      causes an unnecessary scan over the second port/channel.
      
      This fix alters the host->max_channel to 0 (1 port), if internal
      LUNs are configured and switches it back to 1 (2 ports) while
      going back to external LUNs.
      Signed-off-by: NManoj N. Kumar <manoj@linux.vnet.ibm.com>
      Acked-by: NMatthew R. Ochs <mrochs@linux.vnet.ibm.com>
      Reviewed-by: NUma Krishnan <ukrishn@linux.vnet.ibm.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      603ecce9
    • U
      cxlflash: Reorder user context initialization · 5d1952ac
      Uma Krishnan 提交于
      In order to support cxlflash in the PowerVM environment, underlying
      hypervisor APIs have imposed a kernel API ordering change.
      
      For the superpipe access to LUN, user applications need a context.
      The cxlflash module creates this context by making a sequence of
      cxl calls. In the current code, a context is initialized via
      cxl_dev_context_init() followed by cxl_process_element(), a function
      that obtains the process element id. Finally, cxl_start_work()
      is called to attach the process element.
      
      In the PowerVM environment, a process element id cannot be obtained
      from the hypervisor until the process element is attached. The
      cxlflash module is unable to create contexts without a valid
      process element id.
      
      To fix this problem, cxl_start_work() is called before obtaining
      the process element id.
      Signed-off-by: NUma Krishnan <ukrishn@linux.vnet.ibm.com>
      Acked-by: NMatthew R. Ochs <mrochs@linux.vnet.ibm.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      5d1952ac
    • M
      cxlflash: Simplify attach path error cleanup · 8a96b52a
      Matthew R. Ochs 提交于
      The cxlflash_disk_attach() routine currently uses a cascading error
      gate strategy for its error cleanup path. While this strategy is
      commonly used to handle cleanup scenarios, it is too restrictive when
      function callouts need to be restructured. Problems range from
      inserting error path bugs in previously 'good' code to the cleanup
      path imposing design changes to how the normal path is structured.
      A less restrictive approach is needed to support ordering changes
      that come about when operating in different environments.
      
      To overcome this restriction, the error cleanup path is modified to
      have a single entrypoint and use conditional logic to cleanup where
      necessary. Entities that require multiple cleanup steps must be
      carefully vetted to ensure their APIs support state. In cases where
      they do not (none as of this commit) additional local variables can
      be used to maintain state on their behalf.
      Signed-off-by: NMatthew R. Ochs <mrochs@linux.vnet.ibm.com>
      Reviewed-by: NUma Krishnan <ukrishn@linux.vnet.ibm.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      8a96b52a
    • M
      cxlflash: Split out context initialization · 5e6632d1
      Matthew R. Ochs 提交于
      Presently, context information structures are allocated and
      initialized in the same routine, create_context(). This imposes
      an ordering restriction such that all pieces of information needed
      to initialize a context must be known before the context is even
      allocated.
      
      This design point is not flexible when the order of context
      creation needs to be modified. Specifically, this can lead to
      problems when members of the context information structure are
      a part of an ordering dependency (i.e. - the 'work' structure
      embedded within the context).
      
      To remedy, the allocation is left as-is, inside of the existing
      create_context() routine and the initialization is transitioned
      to a new void routine, init_context(). At the same time, in
      anticipation of these routines not being called in sequence, a
      state boolean is added to the context information structure to
      track when the context has been initilized. The context teardown
      routine, destroy_context(), is modified to support being called
      with a non-initialized context.
      Signed-off-by: NMatthew R. Ochs <mrochs@linux.vnet.ibm.com>
      Reviewed-by: NUma Krishnan <ukrishn@linux.vnet.ibm.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      5e6632d1