kernel/linux.git/block/bsg.c, branch v5.4.201

scsi: bsg: Remove support for SCSI_IOCTL_SEND_COMMAND

2021-09-22T10:26:23+00:00

[ Upstream commit beec64d0c9749afedf51c3c10cf52de1d9a89cc0 ] SCSI_IOCTL_SEND_COMMAND has been deprecated longer than bsg exists and has been warning for just as long. More importantly it harcodes SCSI CDBs and thus will do the wrong thing on non-SCSI bsg nodes. Link: https://lore.kernel.org/r/20210724072033.1284840-2-hch@lst.de Fixes: aa387cc89567 ("block: add bsg helper library") Reviewed-by: Bart Van Assche Acked-by: Jens Axboe Signed-off-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

bsg: free the request before return error code

2021-03-04T09:26:22+00:00

[ Upstream commit 0f7b4bc6bb1e57c48ef14f1818df947c1612b206 ] Free the request rq before returning error code. Fixes: 972248e9111e ("scsi: bsg-lib: handle bidi requests without block layer help") Signed-off-by: Pan Bian Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin

block: switch all files cleared marked as GPLv2 to SPDX tags

2019-04-30T22:11:57+00:00

All these files have some form of the usual GPLv2 boilerplate. Switch them to use SPDX tags instead. Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe

scsi: bsg-lib: handle bidi requests without block layer help

2019-02-06T02:27:40+00:00

We can just stash away the second request in struct bsg_job instead of using the block layer req->next_rq field, allowing for the eventual removal of the latter. Signed-off-by: Christoph Hellwig Acked-by: Jens Axboe Signed-off-by: Martin K. Petersen

scsi: bsg: refactor bsg_ioctl

2019-02-06T02:26:55+00:00

Move all actual functionality into helpers, just leaving the dispatch in this function. Signed-off-by: Christoph Hellwig Reviewed-by: Benjamin Block Tested-by: Benjamin Block Tested-by: Avri Altman Acked-by: Jens Axboe Signed-off-by: Martin K. Petersen

bsg: deprecate BIDI support in bsg

2018-12-21T15:47:58+00:00

Besides the OSD command set that never got traction, the only SCSI command using bidirectional buffers is XDWRITEREAD in the 10 and 32 byte variants, which is extremely esoteric and has been removed from the spec again as of SBC4r15. It probably doesn't make sense to keep the support code around just for that, so start deprecating the support. Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe

block: add queue_is_mq() helper

2018-11-16T15:34:06+00:00

Various spots check for q->mq_ops being non-NULL, but provide a helper to do this instead. Where the ->mq_ops != NULL check is redundant, remove it. Since mq == rq-based now that legacy is gone, get rid of the queue_is_rq_based() and just use queue_is_mq() everywhere. Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe

block: bsg: move atomic_t ref_count variable to refcount API

2018-08-28T01:17:02+00:00

Currently, variable ref_count within the bsg_device struct is of type atomic_t. For variables being used as reference counters, the refcount API should be used instead of atomic. The newer refcount API works to prevent counter overflows and use-after-free bugs. So, move this varable from the atomic API to refcount, potentially avoiding the issues mentioned. Signed-off-by: John Pittman Signed-off-by: Jens Axboe

Merge tag 'v4.18-rc6' into for-4.19/block2

2018-08-06T01:32:09+00:00

Pull in 4.18-rc6 to get the NVMe core AEN change to avoid a merge conflict down the line. Signed-of-by: Jens Axboe

bsg: remove read/write support

2018-07-12T14:04:08+00:00

The code poses a security risk due to user memory access in ->release and had an API that can't be used reliably. As far as we know it was never used for real, but if that turns out wrong we'll have to revert this commit and come up with a band aid. Jann Horn did look software archives for users of this interface, and the only users found were example code in sg3_utils, and optional support in an optional module of the tgt user space iscsi target, which looks like a proof of concept extension of the /dev/sg read/write support. Tony Battersby chimes in that the code is basically unsafe to use in general: The read/write interface on /dev/bsg is impossible to use safely because the list of completed commands is per-device (bd->done_list) rather than per-fd like it is with /dev/sg. So if program A and program B are both using the write/read interface on the same bsg device, then their command responses will get mixed up, and program A will read() some command results from program B and vice versa. So no, I don't use read/write on /dev/bsg. From a security standpoint, it should definitely be fixed or removed. Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe