[RFC PATCH 5/6] bsg: reduce unnecessary arguments for bsg_map_hdr()

Since struct bsg_command is now used in every calling case, we don't need separation of arguments anymore that are contained in the same bsg_command. Signed-off-by: Benjamin Block --- block/bsg.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-)

[RFC PATCH 4/6] bsg: refactor ioctl to use regular BSG-command infrastructure for SG_IO

Before, the SG_IO ioctl for BSG devices used to use its own on-stack data to assemble and send the specified command. The read and write calls use their own infrastructure build around the struct bsg_command and a custom slab-pool for that. Rafactor this, so that SG_IO ioctl also uses struct

[RFC PATCH 6/6] bsg: reduce unnecessary arguments for blk_complete_sgv4_hdr_rq()

Since struct bsg_command is now used in every calling case, we don't need separation of arguments anymore that are contained in the same bsg_command. Signed-off-by: Benjamin Block --- block/bsg.c | 20 +--- 1 file changed, 9 insertions(+), 11

[RFC PATCH 1/6] bsg: fix kernel panic resulting from missing allocation of a reply-buffer

In contrast to the normal SCSI-lib, the BSG block-queue doesn't make use of any extra init_rq_fn() to make additional allocations during request-creation, and the request sense-pointer is not used to transport SCSI sense data, but is used as backing for the bsg_job->reply pointer; that in turn is

[RFC PATCH 3/6] bsg: scsi-transport: add compile-tests to prevent reply-buffer overflows

The BSG implementations use the bsg_job's reply buffer as storage for their own custom reply structures (e.g.: struct fc_bsg_reply or struct iscsi_bsg_reply). The size of bsg_job's reply buffer and those of the implementations is not dependent in any way the compiler can currently check. To make

[RFC PATCH 0/6] bsg: fix regression resulting in panics when sending commands via BSG and some sanity cleanups

Hello all, Steffen noticed recently that we have a regression in the BSG code that prevents us from sending any traffic over this interface. After I researched this a bit, it turned out that this affects not only zFCP, but likely all LLDs that implements the BSG API. This was introduced in 4.11

[RFC PATCH 2/6] bsg: assign sense_len instead of fixed SCSI_SENSE_BUFFERSIZE

We do set rq->sense_len when we assigne the reply-buffer in blk_fill_sgv4_hdr_rq(). No point in possibly deviating from this value later on. bsg-lib.h specifies: unsigned int reply_len; /* * On entry : reply_len indicates the buffer size allocated for * the reply. * *