linux-stable.git/drivers/target/target_core_user.c, branch linux-4.10.y

tcmu: Skip Data-Out blocks before gathering Data-In buffer for BIDI case

2017-04-21T07:32:36+00:00

commit a5d68ba85801a78c892a0eb8efb711e293ed314b upstream.

For the bidirectional case, the Data-Out buffer blocks will always at
the head of the tcmu_cmd's bitmap, and before gathering the Data-In
buffer, first of all it should skip the Data-Out ones, or the device
supporting BIDI commands won't work.

Fixed: 26418649eead ("target/user: Introduce data_bitmap, replace
		data_length/data_head/data_tail")
Reported-by: Ilias Tsitsimpis 
Tested-by: Ilias Tsitsimpis 
Signed-off-by: Xiubo Li 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

tcmu: Fix wrongly calculating of the base_command_size

2017-04-21T07:32:36+00:00

commit abe342a5b4b5aa579f6bf40ba73447c699e6b579 upstream.

The t_data_nents and t_bidi_data_nents are the numbers of the
segments, but it couldn't be sure the block size equals to size
of the segment.

For the worst case, all the blocks are discontiguous and there
will need the same number of iovecs, that's to say: blocks == iovs.
So here just set the number of iovs to block count needed by tcmu
cmd.

Tested-by: Ilias Tsitsimpis 
Reviewed-by: Mike Christie 
Signed-off-by: Xiubo Li 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

tcmu: Fix possible overwrite of t_data_sg's last iov[]

2017-04-21T07:32:36+00:00

commit ab22d2604c86ceb01bb2725c9860b88a7dd383bb upstream.

If there has BIDI data, its first iov[] will overwrite the last
iov[] for se_cmd->t_data_sg.

To fix this, we can just increase the iov pointer, but this may
introuduce a new memory leakage bug: If the se_cmd->data_length
and se_cmd->t_bidi_data_sg->length are all not aligned up to the
DATA_BLOCK_SIZE, the actual length needed maybe larger than just
sum of them.

So, this could be avoided by rounding all the data lengthes up
to DATA_BLOCK_SIZE.

Reviewed-by: Mike Christie 
Tested-by: Ilias Tsitsimpis 
Reviewed-by: Bryant G. Ly 
Signed-off-by: Xiubo Li 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'scsi-target-for-v4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/bvanassche/linux

2016-12-21T18:16:05+00:00

Pull scsi target cleanups from Bart Van Assche:
 "The changes here are:

   - a few small bug fixes for the iSCSI and user space target drivers.

   - minimize the target build time by about 30% by rearranging #include
     directives

   - fix the second argument passed to percpu_ida_alloc()

   - reduce the number of false positive warnings reported by sparse

  These patches pass Wu Fengguang's build bot tests and also the
  linux-next tests"

* 'scsi-target-for-v4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/bvanassche/linux:
  iscsi-target: Return error if unable to add network portal
  target: Fix spelling mistake and unwrap multi-line text
  target/iscsi: Fix double free in lio_target_tiqn_addtpg()
  target/user: Fix use-after-free of tcmu_cmds if they are expired
  target: Minimize #include directives
  target/user: Add an #include directive
  cxgbit: Add an #include directive
  ibmvscsi_tgt: Add two #include directives
  sbp-target: Add an #include directive
  qla2xxx: Add an #include directive
  configfs: Minimize #include directives
  usb: gadget: Fix second argument of percpu_ida_alloc()
  sbp-target: Fix second argument of percpu_ida_alloc()
  target/user: Fix a data type in tcmu_queue_cmd()
  target: Use NULL instead of 0 to represent a pointer

target/user: Fix use-after-free of tcmu_cmds if they are expired

2016-12-15T15:34:58+00:00

Don't free the cmd in tcmu_check_expired_cmd, it's still referenced by
an entry in our cmd_id->cmd idr. If userspace ever resumes processing,
tcmu_handle_completions() will use the now-invalid cmd pointer.

Instead, don't free cmd. It will be freed by tcmu_handle_completion() if
userspace ever recovers, or tcmu_free_device if not.

Cc: stable@vger.kernel.org
Reported-by: Bryant G Ly 
Tested-by: Bryant G Ly 
Signed-off-by: Andy Grover 
Signed-off-by: Bart Van Assche

target/user: Add an #include directive

2016-12-09T18:21:55+00:00

Since this driver uses kmap_atomic(), include the highmem header file.

Signed-off-by: Bart Van Assche 
Cc: Nicholas Bellinger 
Cc: Andy Grover

target/user: Fix a data type in tcmu_queue_cmd()

2016-12-09T18:20:07+00:00

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: Bart Van Assche

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2016-10-30T16:42:58+00:00

Mostly simple overlapping changes.

For example, David Ahern's adjacency list revamp in 'net-next'
conflicted with an adjacency list traversal bug fix in 'net'.

Signed-off-by: David S. Miller

genetlink: mark families as __ro_after_init

2016-10-27T20:16:09+00:00

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: Johannes Berg 
Signed-off-by: David S. Miller

genetlink: statically initialize families

2016-10-27T20:16:09+00:00

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: Johannes Berg 
Signed-off-by: David S. Miller