1. 15 Jul, 2016 1 commit
  2. 13 Jul, 2016 3 commits
  3. 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: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Tested-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      4b9bc86d
  4. 15 Apr, 2016 4 commits
  5. 11 Apr, 2016 2 commits
  6. 05 Apr, 2016 1 commit
  7. 04 Apr, 2016 2 commits
  8. 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: 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
  9. 05 Mar, 2016 1 commit
  10. 23 Feb, 2016 5 commits
  11. 27 Jan, 2016 1 commit
  12. 23 Dec, 2015 1 commit
  13. 18 Dec, 2015 2 commits
  14. 02 Dec, 2015 3 commits
  15. 30 Nov, 2015 1 commit
  16. 25 Nov, 2015 1 commit
  17. 19 Nov, 2015 1 commit
  18. 09 Nov, 2015 1 commit
  19. 28 Aug, 2015 5 commits
  20. 26 Aug, 2015 1 commit
  21. 03 Aug, 2015 1 commit
  22. 30 Jul, 2015 1 commit
    • Chris Leech's avatar
      iSCSI: let session recovery_tmo sysfs writes persist across recovery · 9c8108a4
      Chris Leech authored
      The iSCSI session recovery_tmo setting is writeable in sysfs, but it's
      also set every time a connection is established when parameters are set
      from iscsid over netlink.  That results in the timeout being reset to
      the default value after every recovery.
      
      The DM multipath tools want to use the sysfs interface to lower the
      default timeout when there are multiple paths to fail over.  It has
      caused confusion that we have a writeable sysfs value that seem to keep
      resetting itself.
      
      This patch adds an in-kernel flag that gets set once a sysfs write
      occurs, and then ignores netlink parameter setting once it's been
      modified via the sysfs interface.  My thinking here is that the sysfs
      interface is much simpler for external tools to influence the session
      timeout, but if we're going to allow it to be modified directly we
      should ensure that setting is maintained.
      Signed-off-by: default avatarChris Leech <cleech@redhat.com>
      Reviewed-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
      9c8108a4