linux-stable.git/block/bsg.c, branch linux-5.2.y

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

bsg: fix bogus EINVAL on non-data commands

2018-07-11T14:48:28+00:00

Fix a regression introduced in Linux kernel 4.17 where sending a SCSI
command that does not transfer data (such as TEST UNIT READY) via
/dev/bsg/* results in EINVAL.

Fixes: 17cb960f29c2 ("bsg: split handling of SCSI CDBs vs transport requeues")
Cc:  # 4.17+
Reviewed-by: Christoph Hellwig 
Signed-off-by: Tony Battersby 
Signed-off-by: Jens Axboe

bsg: fix race of bsg_open and bsg_unregister

2018-06-15T14:15:37+00:00

The existing implementation allows races between bsg_unregister and
bsg_open paths. bsg_unregister and request_queue cleanup and deletion
may start and complete right after bsg_get_device (in bsg_open path)
retrieves bsg_class_device and releases the mutex. Then bsg_open path
touches freed memory of bsg_class_device and request_queue.

One possible fix is to hold the mutex all the way through bsg_get_device
instead of releasing it after bsg_class_device retrieval.

Reviewed-by: Christoph Hellwig 
Signed-Off-By: Anatoliy Glagolev 
Signed-off-by: Jens Axboe