1. 25 Feb, 2017 1 commit
  2. 14 Feb, 2017 1 commit
  3. 15 Dec, 2016 1 commit
  4. 09 Dec, 2016 2 commits
    • Bart Van Assche's avatar
      target/user: Add an #include directive · f5045724
      Bart Van Assche authored
      
      
      Since this driver uses kmap_atomic(), include the highmem header file.
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Nicholas Bellinger <nab@linux-iscsi.org>
      Cc: Andy Grover <agrover@redhat.com>
      f5045724
    • Bart Van Assche's avatar
      target/user: Fix a data type in tcmu_queue_cmd() · ecaf597b
      Bart Van Assche authored
      
      
      This patch avoids that sparse reports the following error messages:
      
      drivers/target/target_core_user.c:547:13: warning: incorrect type in assignment (different base types)
      drivers/target/target_core_user.c:547:13:    expected int [signed] ret
      drivers/target/target_core_user.c:547:13:    got restricted sense_reason_t
      drivers/target/target_core_user.c:548:20: warning: restricted sense_reason_t degrades to integer
      drivers/target/target_core_user.c:557:16: warning: incorrect type in return expression (different base types)
      drivers/target/target_core_user.c:557:16:    expected restricted sense_reason_t
      drivers/target/target_core_user.c:557:16:    got int [signed] ret
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      ecaf597b
  5. 27 Oct, 2016 3 commits
    • Johannes Berg's avatar
      genetlink: mark families as __ro_after_init · 56989f6d
      Johannes Berg authored
      
      
      Now genl_register_family() is the only thing (other than the
      users themselves, perhaps, but I didn't find any doing that)
      writing to the family struct.
      
      In all families that I found, genl_register_family() is only
      called from __init functions (some indirectly, in which case
      I've add __init annotations to clarifly things), so all can
      actually be marked __ro_after_init.
      
      This protects the data structure from accidental corruption.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      56989f6d
    • Johannes Berg's avatar
      genetlink: statically initialize families · 489111e5
      Johannes Berg authored
      
      
      Instead of providing macros/inline functions to initialize
      the families, make all users initialize them statically and
      get rid of the macros.
      
      This reduces the kernel code size by about 1.6k on x86-64
      (with allyesconfig).
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      489111e5
    • Johannes Berg's avatar
      genetlink: no longer support using static family IDs · a07ea4d9
      Johannes Berg authored
      
      
      Static family IDs have never really been used, the only
      use case was the workaround I introduced for those users
      that assumed their family ID was also their multicast
      group ID.
      
      Additionally, because static family IDs would never be
      reserved by the generic netlink code, using a relatively
      low ID would only work for built-in families that can be
      registered immediately after generic netlink is started,
      which is basically only the control family (apart from
      the workaround code, which I also had to add code for so
      it would reserve those IDs)
      
      Thus, anything other than GENL_ID_GENERATE is flawed and
      luckily not used except in the cases I mentioned. Move
      those workarounds into a few lines of code, and then get
      rid of GENL_ID_GENERATE entirely, making it more robust.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a07ea4d9
  6. 20 Oct, 2016 3 commits
  7. 11 Mar, 2016 6 commits
  8. 06 Feb, 2016 1 commit
    • Arnd Bergmann's avatar
      target/user: Fix cast from pointer to phys_addr_t · 0633e123
      Arnd Bergmann authored
      
      
      The uio_mem structure has a member that is a phys_addr_t, but can
      be a number of other types too. The target core driver attempts
      to assign a pointer from vmalloc() to it, by casting it to
      phys_addr_t, but that causes a warning when phys_addr_t is longer
      than a pointer:
      
      drivers/target/target_core_user.c: In function 'tcmu_configure_device':
      drivers/target/target_core_user.c:906:22: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
      
      This adds another cast to uintptr_t to shut up the warning.
      A nicer fix might be to have additional fields in uio_mem
      for the different purposes, so we can assign a pointer directly.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      0633e123
  9. 20 Jan, 2016 1 commit
  10. 07 Jan, 2016 1 commit
    • Sheng Yang's avatar
      target/user: Allow user to set block size before enabling device · 81ee28de
      Sheng Yang authored
      The capability of setting hw_block_size was added along with 9c1cd1b6
      
      
      "target/user: Only support full command pass-through", though default
      setting override the user specified value during the enabling of device,
      which called by target_configure_device() to set block_size matching
      hw_block_size, result in user not able to set different block size other
      than default 512.
      
      This patch would use existing hw_block_size value if already set, otherwise
      it would be set to default value(512).
      
      Update: Fix the coding style issue.
      
      (Drop unnecessary re-export of dev->dev_attrib.block_size - nab)
      Signed-off-by: default avatarSheng Yang <sheng@yasker.org>
      Cc: Andy Grover <agrover@redhat.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      81ee28de
  11. 06 Jan, 2016 1 commit
  12. 29 Nov, 2015 2 commits
  13. 11 Sep, 2015 3 commits
  14. 23 Jun, 2015 1 commit
  15. 02 Jun, 2015 1 commit
    • Bart Van Assche's avatar
      target: Minimize SCSI header #include directives · ba929992
      Bart Van Assche authored
      
      
      Only include SCSI initiator header files in target code that needs
      these header files, namely the SCSI pass-through code and the tcm_loop
      driver. Change SCSI_SENSE_BUFFERSIZE into TRANSPORT_SENSE_BUFFER in
      target code because the former is intended for initiator code and the
      latter for target code. With this patch the only initiator include
      directives in target code that remain are as follows:
      
      $ git grep -nHE 'include .scsi/(scsi.h|scsi_host.h|scsi_device.h|scsi_cmnd.h)' drivers/target drivers/infiniband/ulp/{isert,srpt} drivers/usb/gadget/legacy/tcm_*.[ch] drivers/{vhost,xen} include/{target,trace/events/target.h}
      drivers/target/loopback/tcm_loop.c:29:#include <scsi/scsi.h>
      drivers/target/loopback/tcm_loop.c:31:#include <scsi/scsi_host.h>
      drivers/target/loopback/tcm_loop.c:32:#include <scsi/scsi_device.h>
      drivers/target/loopback/tcm_loop.c:33:#include <scsi/scsi_cmnd.h>
      drivers/target/target_core_pscsi.c:39:#include <scsi/scsi_device.h>
      drivers/target/target_core_pscsi.c:40:#include <scsi/scsi_host.h>
      drivers/xen/xen-scsiback.c:52:#include <scsi/scsi_host.h> /* SG_ALL */
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
      ba929992
  16. 01 Jun, 2015 3 commits
    • Nicholas Bellinger's avatar
      target: Drop lun_sep_lock for se_lun->lun_se_dev RCU usage · 4cc987ea
      Nicholas Bellinger authored
      
      
      With se_port and t10_alua_tg_pt_gp_member being absored into se_lun,
      there is no need for an extra lock to protect se_lun->lun_se_dev
      assignment.
      
      This patch also converts backend drivers to use call_rcu() release
      to allow any se_device readers to complete.  The call_rcu() instead
      of kfree_rcu() is required here because se_device is embedded into
      the backend driver specific structure.
      
      Also, convert se_lun->lun_stats to use atomic_long_t within the
      target_complete_ok_work() completion callback, and add FIXME for
      transport_lookup_tmr_lun() with se_lun->lun_ref.
      
      Finally, update sbp_update_unit_directory() special case usage with
      proper rcu_dereference_raw() and configfs symlink comment.
      Reported-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Chris Boot <bootc@bootc.net>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      4cc987ea
    • Christoph Hellwig's avatar
      target: consolidate backend attribute implementations · 5873c4d1
      Christoph Hellwig authored
      
      
      Provide a common sets of dev_attrib attributes for all devices using the
      generic SPC/SBC parsers, and a second one with the minimal required read-only
      attributes for passthrough devices.  The later is only used by pscsi for now,
      but will be wired up for the full-passthrough TCMU use case as well.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      5873c4d1
    • Christoph Hellwig's avatar
      target: simplify backend driver registration · 0a06d430
      Christoph Hellwig authored
      
      
      Rewrite the backend driver registration based on what we did to the fabric
      drivers:  introduce a read-only struct target_bakckend_ops that the driver
      registers, which is then instanciate as a struct target_backend by the
      core.  This allows the ops vector to be smaller and allows us to mark it
      const.  At the same time the registration function can set up the
      configfs attributes, avoiding the need to add additional boilerplate code
      for that to the drivers.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      0a06d430
  17. 31 May, 2015 6 commits
  18. 28 May, 2015 1 commit
  19. 03 May, 2015 1 commit
    • Andy Grover's avatar
      target/user: Disallow full passthrough (pass_level=0) · 8ee83a74
      Andy Grover authored
      
      
      TCMU requires more work to correctly handle both user handlers that want
      all SCSI commands (pass_level=0) for a se_device, and also handlers that
      just want I/O commands and let the others be emulated by the kernel
      (pass_level=1). Only support the latter for now.
      
      For full passthrough, we will need to support a second se_subsystem_api
      template, due to configfs attributes being different between the two modes.
      Thus pass_level is extraneous, and we can remove it.
      
      The ABI break for TCMU v2 is already applied for this release, so it's
      best to do this now to avoid another ABI break in the future.
      Signed-off-by: default avatarAndy Grover <agrover@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      8ee83a74
  20. 20 Apr, 2015 1 commit
    • Andy Grover's avatar
      target: Version 2 of TCMU ABI · 0ad46af8
      Andy Grover authored
      
      
      The initial version of TCMU (in 3.18) does not properly handle
      bidirectional SCSI commands -- those with both an in and out buffer. In
      looking to fix this it also became clear that TCMU's support for adding
      new types of entries (opcodes) to the command ring was broken. We need
      to fix this now, so that future issues can be handled properly by adding
      new opcodes.
      
      We make the most of this ABI break by enabling bidi cmd handling within
      TCMP_OP_CMD opcode. Add an iov_bidi_cnt field to tcmu_cmd_entry.req.
      This enables TCMU to describe bidi commands, but further kernel work is
      needed for full bidi support.
      
      Enlarge tcmu_cmd_entry_hdr by 32 bits by pulling in cmd_id and __pad1. Turn
      __pad1 into two 8 bit flags fields, for kernel-set and userspace-set flags,
      "kflags" and "uflags" respectively.
      
      Update version fields so userspace can tell the interface is changed.
      
      Update tcmu-design.txt with details of how new stuff works:
      - Specify an additional requirement for userspace to set UNKNOWN_OP
        (bit 0) in hdr.uflags for unknown/unhandled opcodes.
      - Define how Data-In and Data-Out fields are described in req.iov[]
      
      Changed in v2:
      - Change name of SKIPPED bit to UNKNOWN bit
      - PAD op does not set the bit any more
      - Change len_op helper functions to take just len_op, not the whole struct
      - Change version to 2 in missed spots, and use defines
      - Add 16 unused bytes to cmd_entry.req, in case additional SAM cmd
        parameters need to be included
      - Add iov_dif_cnt field to specify buffers used for DIF info in iov[]
      - Rearrange fields to naturally align cdb_off
      - Handle if userspace sets UNKNOWN_OP by indicating failure of the cmd
      - Wrap some overly long UPDATE_HEAD lines
      
      (Add missing req.iov_bidi_cnt + req.iov_dif_cnt zeroing - Ilias)
      Signed-off-by: default avatarAndy Grover <agrover@redhat.com>
      Reviewed-by: default avatarIlias Tsitsimpis <iliastsi@arrikto.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      0ad46af8