Re: [PATCH 3/3] scsi: move the writeable from struct scsi_device to struct scsi_cd
On 07/18/2014 05:17 PM, Christoph Hellwig wrote:
We currently set the field in common code based on the device type,
but then only use it in the cdrom driver which also overrides the
value previously set in the generic code.
Just leave this entirely to the CDROM driver to make everyones life
simpler.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/scsi_scan.c | 24
drivers/scsi/sd.c | 3 ---
drivers/scsi/sr.c | 4 ++--
drivers/scsi/sr.h | 1 +
include/scsi/scsi_device.h | 1 -
5 files changed, 3 insertions(+), 30 deletions(-)
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index b91cfaf..a5a0bde 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -807,30 +807,6 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned
char *inq_result,
sdev->removable = (inq_result[1] & 0x80) >> 7;
}
- switch (sdev->type) {
- case TYPE_RBC:
- case TYPE_TAPE:
- case TYPE_DISK:
- case TYPE_PRINTER:
- case TYPE_MOD:
- case TYPE_PROCESSOR:
- case TYPE_SCANNER:
- case TYPE_MEDIUM_CHANGER:
- case TYPE_ENCLOSURE:
- case TYPE_COMM:
- case TYPE_RAID:
- case TYPE_OSD:
- sdev->writeable = 1;
- break;
- case TYPE_ROM:
- case TYPE_WORM:
- sdev->writeable = 0;
- break;
- default:
- sdev_printk(KERN_INFO, sdev, "unknown device type %d\n",
- sdev->type);
- }
-
if (sdev->type == TYPE_RBC || sdev->type == TYPE_ROM) {
/* RBC and MMC devices can return SCSI-3 compliance and yet
* still not support REPORT LUNS, so make them act as
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 3663e38..377a520 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -992,9 +992,6 @@ static int sd_setup_read_write_cmnd(struct scsi_cmnd *SCpnt)
}
}
if (rq_data_dir(rq) == WRITE) {
- if (!sdp->writeable) {
- goto out;
- }
SCpnt->cmnd[0] = WRITE_6;
if (blk_integrity_rq(rq))
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index cce4771..7eeb936 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -435,7 +435,7 @@ static int sr_init_command(struct scsi_cmnd *SCpnt)
}
if (rq_data_dir(rq) == WRITE) {
- if (!cd->device->writeable)
+ if (!cd->writeable)
goto out;
SCpnt->cmnd[0] = WRITE_10;
cd->cdi.media_written = 1;
@@ -927,7 +927,7 @@ static void get_capabilities(struct scsi_cd *cd)
*/
if ((cd->cdi.mask & (CDC_DVD_RAM | CDC_MRW_W | CDC_RAM | CDC_CD_RW)) !=
(CDC_DVD_RAM | CDC_MRW_W | CDC_RAM | CDC_CD_RW)) {
- cd->device->writeable = 1;
+ cd->writeable = 1;
}
kfree(buffer);
diff --git a/drivers/scsi/sr.h b/drivers/scsi/sr.h
index 5334e98..1d1f6f4 100644
--- a/drivers/scsi/sr.h
+++ b/drivers/scsi/sr.h
@@ -36,6 +36,7 @@ typedef struct scsi_cd {
struct scsi_device *device;
unsigned int vendor;/* vendor code, see sr_vendor.c */
unsigned long ms_offset;/* for reading multisession-CD's
*/
+ unsigned writeable : 1;
unsigned use:1; /* is this device still supportable */
unsigned xa_flag:1; /* CD has XA sectors ? */
unsigned readcd_known:1;/* drive supports READ_CD (0xbe) */
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 0f853f2..b895784 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -127,7 +127,6 @@ struct scsi_device {
* pass settings from slave_alloc to scsi
* core. */
unsigned int eh_timeout; /* Error handling timeout */
- unsigned writeable:1;
unsigned removable:1;
unsigned changed:1; /* Data invalid due to media change */
unsigned busy:1;/* Used to prevent races */
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] scsi: update scsi_device_types
On 07/18/2014 05:17 PM, Christoph Hellwig wrote:
Add two new device types, most importantly the zoned block device
one.
Split from an earlier patch by Hannes Reinecke.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/scsi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 013709f..33318f5 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -122,6 +122,8 @@ static const char *const scsi_device_types[] = {
"Bridge controller",
"Object storage ",
"Automation/Drive ",
+ "Security Manager ",
+ "Direct-Access-ZBC",
};
/**
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] scsi: add a symbolic name for the ZBC device type
On 07/18/2014 05:17 PM, Christoph Hellwig wrote: Make sure we have a symbolic name for the ZBC type available, so that e.g. patch for a SATA to translate ZAC commands can make use of it. Signed-off-by: Christoph Hellwig --- include/scsi/scsi.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/scsi/scsi.h b/include/scsi/scsi.h index 91e2e42..e6df23c 100644 --- a/include/scsi/scsi.h +++ b/include/scsi/scsi.h @@ -332,6 +332,7 @@ static inline int scsi_status_is_good(int status) #define TYPE_ENCLOSURE 0x0d/* Enclosure Services Device */ #define TYPE_RBC 0x0e #define TYPE_OSD0x11 +#define TYPE_ZBC0x14 #define TYPE_NO_LUN 0x7f /* SCSI protocols; these are taken from SPC-3 section 7.5 */ Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/25] Replace DEFINE_PCI_DEVICE_TABLE macro use
From: Benoit Taine Date: Fri, 18 Jul 2014 17:26:47 +0200 > We should prefer `const struct pci_device_id` over > `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines. > This issue was reported by checkpatch. > > A simplified version of the semantic patch that makes this change is as > follows (http://coccinelle.lip6.fr/): > > // > > @@ > identifier i; > declarer name DEFINE_PCI_DEVICE_TABLE; > initializer z; > @@ > > - DEFINE_PCI_DEVICE_TABLE(i) > + const struct pci_device_id i[] > = z; > > // > > I have 103 patches ready, and will only send a few for you to judge if > it is useful enough, and to prevent from spamming too much. I'm fine with this wrt. the networking changes, but I don't think this should be merged via my tree. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] Drivers: scsi: storvsc: Add blist flags
Add blist flags to permit the reading of the VPD pages even when
the target may claim SPC-2 compliance. MSFT targets currently
claim SPC-2 compliance while they implement post SPC-2 features.
With this patch we can correctly handle WRITE_SAME_16 issues.
Signed-off-by: K. Y. Srinivasan
---
drivers/scsi/storvsc_drv.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 29d0329..2a58dc4 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include "scsi_priv.h"
/*
* All wire protocol details (storage protocol between the guest and the host)
@@ -327,6 +328,8 @@ MODULE_PARM_DESC(storvsc_ringbuffer_size, "Ring buffer size
(bytes)");
*/
static int storvsc_timeout = 180;
+static int msft_blist_flags = BLIST_TRY_VPD_PAGES;
+
#define STORVSC_MAX_IO_REQUESTS200
static void storvsc_on_channel_callback(void *context);
@@ -1438,6 +1441,8 @@ static void storvsc_device_destroy(struct scsi_device
*sdevice)
static int storvsc_device_configure(struct scsi_device *sdevice)
{
+ int blist_flags;
+
scsi_adjust_queue_depth(sdevice, MSG_SIMPLE_TAG,
STORVSC_MAX_IO_REQUESTS);
@@ -1449,6 +1454,14 @@ static int storvsc_device_configure(struct scsi_device
*sdevice)
sdevice->no_write_same = 1;
+ blist_flags = scsi_get_device_flags_keyed(sdevice, "Msft",
+ "Virtual Disk",
+ SCSI_DEVINFO_GLOBAL);
+
+ if (blist_flags != msft_blist_flags)
+ scsi_dev_info_list_add_keyed(1, "Msft", "Virtual Disk", NULL,
+msft_blist_flags,
+SCSI_DEVINFO_GLOBAL);
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [SCSI] hpsa: Fix driver support flag initialisation on !x86
On Sun, 2014-07-20 at 17:42 -0700, Christoph Hellwig wrote: > On Mon, Jul 21, 2014 at 01:09:17AM +0100, Ben Hutchings wrote: > > On !x86 we currently don't read the existing support flags: > > Arnd already sent this and I've included it in the for-3.17 queue. Thanks. Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Re: [PATCH] [SCSI] hpsa: Fix driver support flag initialisation on !x86
On Mon, Jul 21, 2014 at 01:09:17AM +0100, Ben Hutchings wrote: > On !x86 we currently don't read the existing support flags: Arnd already sent this and I've included it in the for-3.17 queue. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [SCSI] hpsa: Fix driver support flag initialisation on !x86
On !x86 we currently don't read the existing support flags:
/home/benh/linux-3.14.13/drivers/scsi/hpsa.c:4375:17: warning: 'driver_support'
is used uninitialized in this function [-Wuninitialized]
driver_support |= ENABLE_UNIT_ATTN;
^
Signed-off-by: Ben Hutchings
Fixes: 28e134464734 ("[SCSI] hpsa: enable unit attention reporting")
Cc: # 3.14+
---
Compile-tested only.
Ben.
drivers/scsi/hpsa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 9a6e4a2..7c3ff51 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -6350,9 +6350,9 @@ static inline void hpsa_set_driver_support_bits(struct
ctlr_info *h)
{
u32 driver_support;
+ driver_support = readl(&(h->cfgtable->driver_support));
#ifdef CONFIG_X86
/* Need to enable prefetch in the SCSI core for 6400 in x86 */
- driver_support = readl(&(h->cfgtable->driver_support));
driver_support |= ENABLE_SCSI_PREFETCH;
#endif
driver_support |= ENABLE_UNIT_ATTN;
--
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.
signature.asc
Description: This is a digitally signed message part
Write cache and surface error behaviour
Hello list, I don't really understand this disk cache thing. Suppose a disk with write cache enabled of writeback type: Linux receives a write completed notification (a message from the disk) when the data has reached the cache of the disk. Correct? At that point it is not considered an in-flight I/O anymore. Correct? So what happens when the disk tries to write it to the platter and discovers that there is a media error on that sector? (suppose relocation does not happen ; maybe sectors exhausted) Does Linux receive the write error upon the next flush it issues? So the error is related to the flush? And what happens if Linux never issues such flush? Thank you J. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] block: support > 16 byte CDBs for SG_IO
On 07/20/2014 04:27 PM, Christoph Hellwig wrote: > On Sun, Jul 20, 2014 at 02:47:49PM +0300, Boaz Harrosh wrote: >> >> So two things here: >> - hdr->cmd_len is char so can be MAX of 255. I understand that 4 bytes >> alignment is a SCSI >> thing so you found no point of checking any max size? > > I don't see any point to force the aligmnet - the devices need to reject > garbage commands, and if for some reason we'd see future commands > that are > 252 and < 255 we are prepared to handle them. > I agree >> - Why the zero alloc, if you are going to paste over it the exact same >> length. Now if like in scsi >> you need 4 bytes alignment and zero padding yes, but here you do not do >> this (and probably shouldn't). >> Hence why zero-alloc? > > No good reason except that's what sg and bsg do. > Ha sorry didn't look there. Looks redundant to me that's all <> >> Inside here: blk_fill_sghdr_rq() calls blk_verify_command() which does: >> (Below cmd[] is the buffer copied from user) >> >> /* Anybody who can open the device can do a read-safe command */ >> if (test_bit(cmd[0], filter->read_ok)) >> return 0; >> >> /* Write-safe commands require a writable open */ >> if (test_bit(cmd[0], filter->write_ok) && has_write_perm) >> return 0; >> >> Now I am not sure what type "Commands" you guys intend for these large >> commands >> but if they are say SCSI-VARLEN this test will not work. Also a user might >> fool >> the system with pretending to be "read" a device modifying command. >> >> I would pass len to this test function and only permit these above if >> command is >> <= 16. Any "special" large command is root only. > > Honestly that whole filter crap should never have been merged to start with, > you'll just need proper CAP_SYS_RAWIO for variable length commands. > > I agree. What I'm saying is - Are you sure that with current code as is we will not pass on large commands without the proper CAP_SYS_RAWIO. Should we not make sure and add: /* root can do any command. */ if (capable(CAP_SYS_RAWIO)) return 0; + + if (cmnd_len > BLK_MAX_CDB) + return -EPERM; Rrrr you are right. I finally get the filter code. Anything that is not "white-listed" is rejected. OK sorry for the noise. Reviewed-by: Boaz Harrosh Thanks Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 80711] SG_FLAG_LUN_INHIBIT is no longer implemented and there's not way to prevent the kernel from using the 2nd cdb byte for the LUN
https://bugzilla.kernel.org/show_bug.cgi?id=80711 --- Comment #1 from Tiziano Bacocco --- Created attachment 143541 --> https://bugzilla.kernel.org/attachment.cgi?id=143541&action=edit This patch allows using SG_FLAG_LUN_INHIBIT I hope i've not broken anything else , this patch allows using SG_FLAG_LUN_INHIBIT -- You are receiving this mail because: You are the assignee for the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] block: support > 16 byte CDBs for SG_IO
On Sun, Jul 20, 2014 at 02:47:49PM +0300, Boaz Harrosh wrote: > > So two things here: > - hdr->cmd_len is char so can be MAX of 255. I understand that 4 bytes > alignment is a SCSI > thing so you found no point of checking any max size? I don't see any point to force the aligmnet - the devices need to reject garbage commands, and if for some reason we'd see future commands that are > 252 and < 255 we are prepared to handle them. > - Why the zero alloc, if you are going to paste over it the exact same > length. Now if like in scsi > you need 4 bytes alignment and zero padding yes, but here you do not do > this (and probably shouldn't). > Hence why zero-alloc? No good reason except that's what sg and bsg do. > - Looking at sg.h where hdr->cmd_len is defined it stills has a comment of <= > 16 you might want to > remove the comment by now. The sg changes to support > 16 byte CDs remove the comment, take a look at my core-for-3.17 tree which has them applied. > Inside here: blk_fill_sghdr_rq() calls blk_verify_command() which does: > (Below cmd[] is the buffer copied from user) > > /* Anybody who can open the device can do a read-safe command */ > if (test_bit(cmd[0], filter->read_ok)) > return 0; > > /* Write-safe commands require a writable open */ > if (test_bit(cmd[0], filter->write_ok) && has_write_perm) > return 0; > > Now I am not sure what type "Commands" you guys intend for these large > commands > but if they are say SCSI-VARLEN this test will not work. Also a user might > fool > the system with pretending to be "read" a device modifying command. > > I would pass len to this test function and only permit these above if command > is > <= 16. Any "special" large command is root only. Honestly that whole filter crap should never have been merged to start with, you'll just need proper CAP_SYS_RAWIO for variable length commands. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] block: support > 16 byte CDBs for SG_IO
On 07/20/2014 01:23 PM, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
Hi Christoph I've quickly reviewed your code and have a few questions
> ---
> block/scsi_ioctl.c | 24 +---
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
> index c4e6633..a804f3e 100644
> --- a/block/scsi_ioctl.c
> +++ b/block/scsi_ioctl.c
> @@ -288,8 +288,6 @@ static int sg_io(struct request_queue *q, struct gendisk
> *bd_disk,
>
> if (hdr->interface_id != 'S')
> return -EINVAL;
> - if (hdr->cmd_len > BLK_MAX_CDB)
> - return -EINVAL;
>
> if (hdr->dxfer_len > (queue_max_hw_sectors(q) << 9))
> return -EIO;
> @@ -306,14 +304,21 @@ static int sg_io(struct request_queue *q, struct
> gendisk *bd_disk,
> break;
> }
>
> + ret = -ENOMEM;
> rq = blk_get_request(q, writing ? WRITE : READ, GFP_KERNEL);
> if (!rq)
> - return -ENOMEM;
> + goto out;
> blk_rq_set_block_pc(rq);
>
> + if (hdr->cmd_len > BLK_MAX_CDB) {
> + rq->cmd = kzalloc(hdr->cmd_len, GFP_KERNEL);
So two things here:
- hdr->cmd_len is char so can be MAX of 255. I understand that 4 bytes
alignment is a SCSI
thing so you found no point of checking any max size?
- Why the zero alloc, if you are going to paste over it the exact same length.
Now if like in scsi
you need 4 bytes alignment and zero padding yes, but here you do not do this
(and probably shouldn't).
Hence why zero-alloc?
- Looking at sg.h where hdr->cmd_len is defined it stills has a comment of <=
16 you might want to
remove the comment by now.
> + if (!rq->cmd)
> + goto out_put_request;
> + }
> +
> ret = -EFAULT;
> if (blk_fill_sghdr_rq(q, rq, hdr, mode))
Inside here: blk_fill_sghdr_rq() calls blk_verify_command() which does:
(Below cmd[] is the buffer copied from user)
/* Anybody who can open the device can do a read-safe command */
if (test_bit(cmd[0], filter->read_ok))
return 0;
/* Write-safe commands require a writable open */
if (test_bit(cmd[0], filter->write_ok) && has_write_perm)
return 0;
Now I am not sure what type "Commands" you guys intend for these large commands
but if they are say SCSI-VARLEN this test will not work. Also a user might fool
the system with pretending to be "read" a device modifying command.
I would pass len to this test function and only permit these above if command is
<= 16. Any "special" large command is root only.
Thanks
Boaz
> - goto out;
> + goto out_free_cdb;
>
> if (hdr->iovec_count) {
> size_t iov_data_len;
> @@ -323,7 +328,7 @@ static int sg_io(struct request_queue *q, struct gendisk
> *bd_disk,
> 0, NULL, &iov);
> if (ret < 0) {
> kfree(iov);
> - goto out;
> + goto out_free_cdb;
> }
>
> iov_data_len = ret;
> @@ -346,7 +351,7 @@ static int sg_io(struct request_queue *q, struct gendisk
> *bd_disk,
> GFP_KERNEL);
>
> if (ret)
> - goto out;
> + goto out_free_cdb;
>
> bio = rq->bio;
> memset(sense, 0, sizeof(sense));
> @@ -365,8 +370,13 @@ static int sg_io(struct request_queue *q, struct gendisk
> *bd_disk,
> hdr->duration = jiffies_to_msecs(jiffies - start_time);
>
> ret = blk_complete_sghdr_rq(rq, hdr, bio);
> -out:
> +
> +out_free_cdb:
> + if (rq->cmd != rq->__cmd)
> + kfree(rq->cmd);
> +out_put_request:
> blk_put_request(rq);
> +out:
> return ret;
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
support > 16 byte CDBs for blocklayer SG_IO
Follow the bsg and sg drivers to support large CDBs by allocation the larger than 16 byte CDB array if nessecary. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] block: cleanup error handling in sg_io
Make sure we always clean up through the out label and just have
a single place to put the request.
Signed-off-by: Christoph Hellwig
---
block/scsi_ioctl.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index 14695c6..c4e6633 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -272,7 +272,6 @@ static int blk_complete_sghdr_rq(struct request *rq, struct
sg_io_hdr *hdr,
r = blk_rq_unmap_user(bio);
if (!ret)
ret = r;
- blk_put_request(rq);
return ret;
}
@@ -312,10 +311,9 @@ static int sg_io(struct request_queue *q, struct gendisk
*bd_disk,
return -ENOMEM;
blk_rq_set_block_pc(rq);
- if (blk_fill_sghdr_rq(q, rq, hdr, mode)) {
- blk_put_request(rq);
- return -EFAULT;
- }
+ ret = -EFAULT;
+ if (blk_fill_sghdr_rq(q, rq, hdr, mode))
+ goto out;
if (hdr->iovec_count) {
size_t iov_data_len;
@@ -366,7 +364,7 @@ static int sg_io(struct request_queue *q, struct gendisk
*bd_disk,
hdr->duration = jiffies_to_msecs(jiffies - start_time);
- return blk_complete_sghdr_rq(rq, hdr, bio);
+ ret = blk_complete_sghdr_rq(rq, hdr, bio);
out:
blk_put_request(rq);
return ret;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] block: support > 16 byte CDBs for SG_IO
Signed-off-by: Christoph Hellwig
---
block/scsi_ioctl.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index c4e6633..a804f3e 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -288,8 +288,6 @@ static int sg_io(struct request_queue *q, struct gendisk
*bd_disk,
if (hdr->interface_id != 'S')
return -EINVAL;
- if (hdr->cmd_len > BLK_MAX_CDB)
- return -EINVAL;
if (hdr->dxfer_len > (queue_max_hw_sectors(q) << 9))
return -EIO;
@@ -306,14 +304,21 @@ static int sg_io(struct request_queue *q, struct gendisk
*bd_disk,
break;
}
+ ret = -ENOMEM;
rq = blk_get_request(q, writing ? WRITE : READ, GFP_KERNEL);
if (!rq)
- return -ENOMEM;
+ goto out;
blk_rq_set_block_pc(rq);
+ if (hdr->cmd_len > BLK_MAX_CDB) {
+ rq->cmd = kzalloc(hdr->cmd_len, GFP_KERNEL);
+ if (!rq->cmd)
+ goto out_put_request;
+ }
+
ret = -EFAULT;
if (blk_fill_sghdr_rq(q, rq, hdr, mode))
- goto out;
+ goto out_free_cdb;
if (hdr->iovec_count) {
size_t iov_data_len;
@@ -323,7 +328,7 @@ static int sg_io(struct request_queue *q, struct gendisk
*bd_disk,
0, NULL, &iov);
if (ret < 0) {
kfree(iov);
- goto out;
+ goto out_free_cdb;
}
iov_data_len = ret;
@@ -346,7 +351,7 @@ static int sg_io(struct request_queue *q, struct gendisk
*bd_disk,
GFP_KERNEL);
if (ret)
- goto out;
+ goto out_free_cdb;
bio = rq->bio;
memset(sense, 0, sizeof(sense));
@@ -365,8 +370,13 @@ static int sg_io(struct request_queue *q, struct gendisk
*bd_disk,
hdr->duration = jiffies_to_msecs(jiffies - start_time);
ret = blk_complete_sghdr_rq(rq, hdr, bio);
-out:
+
+out_free_cdb:
+ if (rq->cmd != rq->__cmd)
+ kfree(rq->cmd);
+out_put_request:
blk_put_request(rq);
+out:
return ret;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
