1. 22 Mar, 2016 1 commit
  2. 18 Mar, 2016 7 commits
    • Hannes Reinecke's avatar
      scsi_common: do not clobber fixed sense information · ba083116
      Hannes Reinecke authored
      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: default avatarHannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarLee Duncan <lduncan@suse.com>
      Reviewed-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Reviewed-by: default avatarEwan D. Milne <emilne@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      ba083116
    • Arnd Bergmann's avatar
      scsi: ufs: select CONFIG_NLS · c80fa12e
      Arnd Bergmann authored
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: b573d484 ("scsi: ufs: add support to read device and string descriptors")
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      c80fa12e
    • Arnd Bergmann's avatar
      scsi: fc: use get/put_unaligned64 for wwn access · ef3fb242
      Arnd Bergmann authored
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarHannes Reinicke <hare@suse.de>
      Reviewed-by: default avatarEwan Milne <emilne@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      ef3fb242
    • Maurizio Lombardi's avatar
      fnic: move printk()s outside of the critical code section. · 14cee5b4
      Maurizio Lombardi authored
      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: default avatarMaurizio Lombardi <mlombard@redhat.com>
      Reviewed-by: default avatarLaurence Oberman <loberman@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      14cee5b4
    • Arnd Bergmann's avatar
      qla2xxx: avoid maybe_uninitialized warning · bc7095a9
      Arnd Bergmann authored
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-By: default avatarHimanshu Madhani <himanshu.madhani@qlogic.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      bc7095a9
    • Arnd Bergmann's avatar
      megaraid_sas: add missing curly braces in ioctl handler · 3deb9438
      Arnd Bergmann authored
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 90dc9d98 ("megaraid_sas : MFI MPT linked list corruption fix")
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Acked-by: default avatarSumit Saxena <sumit.saxena@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      3deb9438
    • Arnd Bergmann's avatar
      lpfc: fix misleading indentation · aeb6641f
      Arnd Bergmann authored
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 549e55cd ("[SCSI] lpfc 8.2.2 : Fix locking around HBA's port_list")
      Reviewed-by: default avatarSebastian Herbszt <herbszt@gmx.de>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarEwan D. Milne <emilne@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      aeb6641f
  3. 15 Mar, 2016 21 commits
  4. 14 Mar, 2016 5 commits
  5. 11 Mar, 2016 2 commits
  6. 10 Mar, 2016 2 commits
    • Lars-Peter Clausen's avatar
      mpt3sas: Remove unnecessary synchronize_irq() before free_irq() · 7f8b8f3f
      Lars-Peter Clausen authored
      Calling synchronize_irq() right before free_irq() is quite useless. On
      one hand the IRQ can easily fire again before free_irq() is entered, on
      the other hand free_irq() itself calls synchronize_irq() internally (in
      a race condition free way), before any state associated with the IRQ is
      freed.
      
      Patch was generated using the following semantic patch:
      // <smpl>
      @@
      expression irq;
      @@
      -synchronize_irq(irq);
       free_irq(irq, ...);
      // </smpl>
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Acked-by: default avatarSreekanth Reddy <sreekanth.reddy@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      7f8b8f3f
    • Douglas Gilbert's avatar
      sg: fix dxferp in from_to case · 5ecee0a3
      Douglas Gilbert authored
      One of the strange things that the original sg driver did was let the
      user provide both a data-out buffer (it followed the sg_header+cdb)
      _and_ specify a reply length greater than zero. What happened was that
      the user data-out buffer was copied into some kernel buffers and then
      the mid level was told a read type operation would take place with the
      data from the device overwriting the same kernel buffers. The user would
      then read those kernel buffers back into the user space.
      
      From what I can tell, the above action was broken by commit fad7f01e
      ("sg: set dxferp to NULL for READ with the older SG interface") in 2008
      and syzkaller found that out recently.
      
      Make sure that a user space pointer is passed through when data follows
      the sg_header structure and command.  Fix the abnormal case when a
      non-zero reply_len is also given.
      
      Fixes: fad7f01e
      Cc: <stable@vger.kernel.org> #v2.6.28+
      Signed-off-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
      Reviewed-by: default avatarEwan Milne <emilne@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      5ecee0a3
  7. 09 Mar, 2016 2 commits