kernel.git/drivers/target/target_core_user.c, branch linux-4.9.y

scsi: target: tcmu: Fix crash on ARM during cmd completion

2020-09-03T09:21:16Z

[ Upstream commit 5a0c256d96f020e4771f6fd5524b80f89a2d3132 ] If tcmu_handle_completions() has to process a padding shorter than sizeof(struct tcmu_cmd_entry), the current call to tcmu_flush_dcache_range() with sizeof(struct tcmu_cmd_entry) as length param is wrong and causes crashes on e.g. ARM, because tcmu_flush_dcache_range() in this case calls flush_dcache_page(vmalloc_to_page(start)); with start being an invalid address above the end of the vmalloc'ed area. The fix is to use the minimum of remaining ring space and sizeof(struct tcmu_cmd_entry) as the length param. The patch was tested on kernel 4.19.118. See https://bugzilla.kernel.org/show_bug.cgi?id=208045#c10 Link: https://lore.kernel.org/r/20200629093756.8947-1-bstroesser@ts.fujitsu.com Tested-by: JiangYu Acked-by: Mike Christie Signed-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

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

2017-04-21T07:31:18Z

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:31:18Z

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:31:18Z

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

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

2017-01-09T07:32:25Z

commit d0905ca757bc40bd1ebc261a448a521b064777d7 upstream. 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. Reported-by: Bryant G Ly Tested-by: Bryant G Ly Signed-off-by: Andy Grover Signed-off-by: Bart Van Assche Signed-off-by: Greg Kroah-Hartman

target/user: Fix comments to not refer to data ring

2016-10-20T04:22:23Z

We no longer use a ringbuffer for the data area, so this might cause confusion. Just call it the data area. Signed-off-by: Andy Grover Reviewed-by: Christoph Hellwig Reviewed-by: Mike Christie Signed-off-by: Nicholas Bellinger

target/user: Return an error if cmd data size is too large

2016-10-20T04:22:16Z

Userspace should be implementing VPD B0 (Block Limits) to inform the initiator of max data size, but just in case we do get a too-large request, do what the spec says and return INVALID_CDB_FIELD. Make sure to unlock udev->cmdr_lock before returning. Signed-off-by: Andy Grover Reviewed-by: Christoph Hellwig Reviewed-by: Mike Christie Signed-off-by: Nicholas Bellinger

target/user: Use sense_reason_t in tcmu_queue_cmd_ring

2016-10-20T04:21:45Z

Instead of using -ERROR-style returns, use sense_reason_t. This lets us remove tcmu_pass_op(), and return more correct sense values. Signed-off-by: Andy Grover Signed-off-by: Bryant G. Ly Reviewed-by: Christoph Hellwig Reviewed-by: Mike Christie Signed-off-by: Nicholas Bellinger

target/user: Report capability of handling out-of-order completions to userspace

2016-03-11T05:49:09Z

TCMU_MAILBOX_FLAG_CAP_OOOC was introduced, and userspace can check the flag for out-of-order completion capability support. Also update the document on how to use the feature. Signed-off-by: Sheng Yang Reviewed-by: Andy Grover Signed-off-by: Nicholas Bellinger

target/user: Fix size_t format-spec build warning

2016-03-11T05:49:06Z

Fix the following printk size_t warning as per 0-day build: All warnings (new ones prefixed by >>): drivers/target/target_core_user.c: In function 'is_ring_space_avail': >> drivers/target/target_core_user.c:385:12: warning: format '%lu' >> expects argument of type 'long unsigned int', but argument 3 has type >> 'size_t {aka unsigned int}' [-Wformat=] pr_debug("no data space: only %lu available, but ask for %lu\n", ^ Reported-by: kbuild test robot Signed-off-by: Nicholas Bellinger