1. 26 Sep, 2016 1 commit
    • Bart Van Assche's avatar
      scsi: Avoid that toggling use_blk_mq triggers a memory leak · 8d58881b
      Bart Van Assche authored
      This patch avoids that the following memory leak is triggered if
      use_blk_mq is disabled after a SCSI host has been allocated by the
      ib_srp driver and before the same SCSI host is freed:
      
      unreferenced object 0xffff8803a168c568 (size 256):
        backtrace:
          [<ffffffff81620c95>] kmemleak_alloc+0x45/0xa0
          [<ffffffff811bb104>] __kmalloc_node+0x1e4/0x400
          [<ffffffff81309fe4>] blk_mq_alloc_tag_set+0xb4/0x230
          [<ffffffff814731b7>] scsi_mq_setup_tags+0xc7/0xd0
          [<ffffffff81469c26>] scsi_add_host_with_dma+0x216/0x2d0
          [<ffffffffa064bef5>] srp_create_target+0xe55/0x13d0 [ib_srp]
          [<ffffffff8143ce23>] dev_attr_store+0x13/0x20
          [<ffffffff8125f030>] sysfs_kf_write+0x40/0x50
          [<ffffffff8125e397>] kernfs_fop_write+0x137/0x1c0
          [<ffffffff811d8c13>] __vfs_write+0x23/0x140
          [<ffffffff811d92e0>] vfs_write+0xb0/0x190
          [<ffffffff811da5b4>] SyS_write+0x44/0xa0
          [<ffffffff8162c8a5>] entry_SYSCALL_64_fastpath+0x18/0xa8
      
      Fixes: 9aa9cc42 ("scsi: remove the disable_blk_mq host flag")
      Signed-off-by: 's avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Cc: <stable@vger.kernel.org>
      Reviewed-by: 's avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: 's avatarMartin K. Petersen <martin.petersen@oracle.com>
      8d58881b
  2. 18 Aug, 2016 2 commits
  3. 20 Jul, 2016 1 commit
  4. 15 Jul, 2016 1 commit
  5. 13 Jul, 2016 3 commits
  6. 12 Jul, 2016 1 commit
    • Sebastian Andrzej Siewior's avatar
      fcoe: convert to kworker · 4b9bc86d
      Sebastian Andrzej Siewior authored
      The driver creates its own per-CPU threads which are updated based on
      CPU hotplug events. It is also possible to use kworkers and remove some
      of the kthread infrastrucure.
      
      The code checked ->thread to decide if there is an active per-CPU
      thread. By using the kworker infrastructure this is no longer
      possible (or required). The thread pointer is saved in `kthread' instead
      of `thread' so anything trying to use thread is caught by the
      compiler. Currently only the bnx2fc driver is using struct fcoe_percpu_s
      and the kthread member.
      
      After a CPU went offline, we may still enqueue items on the "offline"
      CPU. This isn't much of a problem. The work will be done on a random
      CPU. The allocated crc_eof_page page won't be cleaned up. It is probably
      expected that the CPU comes up at some point so it should not be a
      problem. The crc_eof_page memory is released of course once the module
      is removed.
      
      This patch was only compile-tested due to -ENODEV.
      
      Cc: Vasu Dev <vasu.dev@intel.com>
      Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
      Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: fcoe-devel@open-fcoe.org
      Cc: linux-scsi@vger.kernel.org
      Signed-off-by: 's avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Tested-by: 's avatarJohannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: 's avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: 's avatarMartin K. Petersen <martin.petersen@oracle.com>
      4b9bc86d
  7. 15 Apr, 2016 4 commits
  8. 11 Apr, 2016 2 commits
  9. 05 Apr, 2016 1 commit
  10. 04 Apr, 2016 2 commits
  11. 18 Mar, 2016 1 commit
    • 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: 's avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: 's avatarHannes Reinicke <hare@suse.de>
      Reviewed-by: 's avatarEwan Milne <emilne@redhat.com>
      Signed-off-by: 's avatarMartin K. Petersen <martin.petersen@oracle.com>
      ef3fb242
  12. 05 Mar, 2016 1 commit
  13. 23 Feb, 2016 5 commits
  14. 27 Jan, 2016 1 commit
  15. 23 Dec, 2015 1 commit
  16. 18 Dec, 2015 2 commits
  17. 02 Dec, 2015 3 commits
  18. 30 Nov, 2015 1 commit
  19. 25 Nov, 2015 1 commit
  20. 19 Nov, 2015 1 commit
  21. 09 Nov, 2015 1 commit
  22. 28 Aug, 2015 4 commits