Re: [PATCH 14/15] block/bsg: move queue creation into bsg_setup_queue
On Wed, Jan 11, 2017 at 05:01:22PM -0500, Mike Snitzer wrote: > But I've seen you reference the need to stop multipath from allocating > its own requests. Are you referring to old request_fn request-based > multipath's clone_old_rq:alloc_old_clone_request? Yes, that one is the issue. It allocates a struct request "blind", that is without known what queue it goes to. With this queue (or blk-mq for that matter) we need to know the queue, because the request structures might have additional data behind it and require additional initialization for drivers that require per-request data. We make use of the per-request data for SCSI passthrough in this patch. > Or how blk-mq request-based multipath gets a request from the blk-mq tag > space (via blk_mq_alloc_request)? That's fine because it works on the queue of the device that I/O is submitted to. -- 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] sd: Ignore zoned field for host-managed devices
On 01/12/2017 07:25 AM, Damien Le Moal wrote:
There is no good match of the zoned filed of the block device
characteristics page for host-managed devices. For these devices, the
zoning model is derived directly from the device type. So ignore the
zoned field for these drives.
Signed-off-by: Damien Le Moal
---
drivers/scsi/sd.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index d7aaacf..6e6d4a4 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -2784,13 +2784,21 @@ static void sd_read_block_characteristics(struct
scsi_disk *sdkp)
queue_flag_clear_unlocked(QUEUE_FLAG_ADD_RANDOM, q);
}
- sdkp->zoned = (buffer[8] >> 4) & 3;
- if (sdkp->zoned == 1)
- q->limits.zoned = BLK_ZONED_HA;
- else if (sdkp->device->type == TYPE_ZBC)
+ if (sdkp->device->type == TYPE_ZBC) {
+ /* Host-managed */
q->limits.zoned = BLK_ZONED_HM;
- else
- q->limits.zoned = BLK_ZONED_NONE;
+ } else {
+ sdkp->zoned = (buffer[8] >> 4) & 3;
+ if (sdkp->zoned == 1)
+ /* Host-aware */
+ q->limits.zoned = BLK_ZONED_HA;
+ else
+ /*
+* Treat drive-managed devices as
+* regular block devices.
+*/
+ q->limits.zoned = BLK_ZONED_NONE;
+ }
if (blk_queue_is_zoned(q) && sdkp->first_scan)
sd_printk(KERN_NOTICE, sdkp, "Host-%s zoned block device\n",
q->limits.zoned == BLK_ZONED_HM ? "managed" : "aware");
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (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/2] sd: Fix wrong DPOFUA disable in sd_read_cache_type
On 01/12/2017 07:25 AM, Damien Le Moal wrote:
Zoned block devices force the use of READ/WRITE(16) commands by setting
sdkp->use_16_for_rw and clearing sdkp->use_10_for_rw. This result in
DPOFUA always being disabled for these drives as the assumed use of
the deprecated READ/WRITE(6) commands only looks at sdkp->use_10_for_rw.
Strenghten the test by also checking that sdkp->use_16_for_rw is false.
Signed-off-by: Damien Le Moal
---
drivers/scsi/sd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index b193304..d7aaacf 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -2600,7 +2600,8 @@ sd_read_cache_type(struct scsi_disk *sdkp, unsigned char
*buffer)
if (sdp->broken_fua) {
sd_first_printk(KERN_NOTICE, sdkp, "Disabling FUA\n");
sdkp->DPOFUA = 0;
- } else if (sdkp->DPOFUA && !sdkp->device->use_10_for_rw) {
+ } else if (sdkp->DPOFUA && !sdkp->device->use_10_for_rw &&
+ !sdkp->device->use_16_for_rw) {
sd_first_printk(KERN_NOTICE, sdkp,
"Uses READ/WRITE(6), disabling FUA\n");
sdkp->DPOFUA = 0;
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (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
[PATCH 2/2] sd: Ignore zoned field for host-managed devices
There is no good match of the zoned filed of the block device
characteristics page for host-managed devices. For these devices, the
zoning model is derived directly from the device type. So ignore the
zoned field for these drives.
Signed-off-by: Damien Le Moal
---
drivers/scsi/sd.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index d7aaacf..6e6d4a4 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -2784,13 +2784,21 @@ static void sd_read_block_characteristics(struct
scsi_disk *sdkp)
queue_flag_clear_unlocked(QUEUE_FLAG_ADD_RANDOM, q);
}
- sdkp->zoned = (buffer[8] >> 4) & 3;
- if (sdkp->zoned == 1)
- q->limits.zoned = BLK_ZONED_HA;
- else if (sdkp->device->type == TYPE_ZBC)
+ if (sdkp->device->type == TYPE_ZBC) {
+ /* Host-managed */
q->limits.zoned = BLK_ZONED_HM;
- else
- q->limits.zoned = BLK_ZONED_NONE;
+ } else {
+ sdkp->zoned = (buffer[8] >> 4) & 3;
+ if (sdkp->zoned == 1)
+ /* Host-aware */
+ q->limits.zoned = BLK_ZONED_HA;
+ else
+ /*
+* Treat drive-managed devices as
+* regular block devices.
+*/
+ q->limits.zoned = BLK_ZONED_NONE;
+ }
if (blk_queue_is_zoned(q) && sdkp->first_scan)
sd_printk(KERN_NOTICE, sdkp, "Host-%s zoned block device\n",
q->limits.zoned == BLK_ZONED_HM ? "managed" : "aware");
--
2.9.3
--
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] sd: Fix wrong DPOFUA disable in sd_read_cache_type
Zoned block devices force the use of READ/WRITE(16) commands by setting
sdkp->use_16_for_rw and clearing sdkp->use_10_for_rw. This result in
DPOFUA always being disabled for these drives as the assumed use of
the deprecated READ/WRITE(6) commands only looks at sdkp->use_10_for_rw.
Strenghten the test by also checking that sdkp->use_16_for_rw is false.
Signed-off-by: Damien Le Moal
---
drivers/scsi/sd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index b193304..d7aaacf 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -2600,7 +2600,8 @@ sd_read_cache_type(struct scsi_disk *sdkp, unsigned char
*buffer)
if (sdp->broken_fua) {
sd_first_printk(KERN_NOTICE, sdkp, "Disabling FUA\n");
sdkp->DPOFUA = 0;
- } else if (sdkp->DPOFUA && !sdkp->device->use_10_for_rw) {
+ } else if (sdkp->DPOFUA && !sdkp->device->use_10_for_rw &&
+ !sdkp->device->use_16_for_rw) {
sd_first_printk(KERN_NOTICE, sdkp,
"Uses READ/WRITE(6), disabling FUA\n");
sdkp->DPOFUA = 0;
--
2.9.3
--
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 0/2] sd fixes for zoned block devices
2 small fixes in this series: (1) Fix sd_read_cache_type so that DPOFUA is not disabled for zoned block devices supporting it. (2) Ignore the zoned field of the block device characteristics page for host-managed zoned block devices as there is no good match defined explicitely for HM by the standard. Damien Le Moal (2): sd: Fix wrong DPOFUA disable in sd_read_cache_type sd: Ignore zoned field for host-managed devices drivers/scsi/sd.c | 23 --- 1 file changed, 16 insertions(+), 7 deletions(-) -- 2.9.3 -- 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: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
> > This is a separate topic. The initial proposal is for polling for > interrupt mitigation, you are talking about polling in the context of > polling for completion of an IO. > > We can definitely talk about this form of polling as well, but it should > be a separate topic and probably proposed independently. > > -- > Jens Axboe > > Jens Oh thanks for the clarification. I will propose this as a separate topic. Thanks Stephen -- 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
[LSF/MM TOPIC][LSF/MM ATTEND] IO completion polling for block drivers
Hi I'd like to discuss the ongoing work in the kernel to enable high priority IO via polling for completion in the blk-mq subsystem. Given that iopoll only really makes sense for low-latency, low queue depth environments (i.e. down below 10-20us) I'd like to discuss which drivers we think will need/want to be upgraded (aside from NVMe ;-)). I'd also be interested in discussing how best to enable and disable polling. In the past some of us have pushed for a "big hammer" to turn polling on for a given device or HW queue [1]. I'd like to discuss this again as well as looking at other methods above and beyond the preadv2 system call and the HIPRI flag. Finally I'd like to discuss some of the recent work to improve the heuristics around when to poll and when not to poll. I'd like to see if we can come up with more optimal balance between CPU load and average completion times [2]. Stephen Bates [1] http://marc.info/?l=linux-block&m=146307410101827&w=2 [2] http://marc.info/?l=linux-block&m=147803441801858&w=2 -- 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: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
>> >> I'd like to attend LSF/MM and would like to discuss polling for block >> drivers. >> >> Currently there is blk-iopoll but it is neither as widely used as NAPI >> in the networking field and accoring to Sagi's findings in [1] >> performance with polling is not on par with IRQ usage. >> >> On LSF/MM I'd like to whether it is desirable to have NAPI like polling >> in more block drivers and how to overcome the currently seen performance >> issues. > > It would be an interesting topic to discuss, as it is a shame that > blk-iopoll isn't used more widely. > > -- > Jens Axboe > I'd also be interested in this topic. Given that iopoll only really makes sense for low-latency, low queue depth environments (i.e. down below 10-20us) I'd like to discuss which drivers we think will need/want to be upgraded (aside from NVMe ;-)). I'd also be interested in discussing how best to enable and disable polling. In the past some of us have pushed for a "big hammer" to turn polling on for a given device or HW queue [1]. I'd like to discuss this again as well as looking at other methods above and beyond the preadv2 system call and the HIPRI flag. Stephen [1] http://marc.info/?l=linux-block&m=146307410101827&w=2 > ___ > Linux-nvme mailing list > linux-n...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-nvme > > -- 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: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
On 01/11/2017 09:36 PM, Stephen Bates wrote: >>> >>> I'd like to attend LSF/MM and would like to discuss polling for block >>> drivers. >>> >>> Currently there is blk-iopoll but it is neither as widely used as NAPI >>> in the networking field and accoring to Sagi's findings in [1] >>> performance with polling is not on par with IRQ usage. >>> >>> On LSF/MM I'd like to whether it is desirable to have NAPI like polling >>> in more block drivers and how to overcome the currently seen performance >>> issues. >> >> It would be an interesting topic to discuss, as it is a shame that >> blk-iopoll isn't used more widely. >> >> -- >> Jens Axboe >> > > I'd also be interested in this topic. Given that iopoll only really makes > sense for low-latency, low queue depth environments (i.e. down below > 10-20us) I'd like to discuss which drivers we think will need/want to be > upgraded (aside from NVMe ;-)). > > I'd also be interested in discussing how best to enable and disable > polling. In the past some of us have pushed for a "big hammer" to turn > polling on for a given device or HW queue [1]. I'd like to discuss this > again as well as looking at other methods above and beyond the preadv2 > system call and the HIPRI flag. This is a separate topic. The initial proposal is for polling for interrupt mitigation, you are talking about polling in the context of polling for completion of an IO. We can definitely talk about this form of polling as well, but it should be a separate topic and probably proposed independently. -- Jens Axboe -- 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 15/15] block: split scsi_request out of struct request
On Tue, Jan 10 2017, Christoph Hellwig wrote:
> And require all drivers that want to support BLOCK_PC to allocate it
> as the first thing of their private data. To support this the legacy
> IDE and BSG code is switched to set cmd_size on their queues to let
> the block layer allocate the additional space.
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index be23859..499728d 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -225,17 +225,7 @@ struct request {
> int tag;
> int errors;
>
> - /*
> - * when request is used as a packet command carrier
> - */
> - unsigned char __cmd[BLK_MAX_CDB];
> - unsigned char *cmd;
> - unsigned short cmd_len;
> -
> unsigned int extra_len; /* length of alignment and padding */
> - unsigned int sense_len;
> - unsigned int resid_len; /* residual count */
> - void *sense;
Oh yes, my mouth is watering. I've wanted to kill off ->cmd and friends
with fire for years.
On the block front, I think the solution is fine with mimicking the mq
solution of carrying an rq payload, and the implementation for the
legacy path looks fine.
--
Jens Axboe
--
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 v2 0/4] cxlflash: Enhancements, cleanup and fixes
> "Uma" == Uma Krishnan writes: Uma> This patch series includes an enhancement to support a new command Uma> queuing model and also cleans up prints throughout the driver. The Uma> last patch in the series fixes a racing issue. Applied to 4.11/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering -- 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] lpfc: avoid double free of resource identifiers
> "Johannes" == Johannes Thumshirn writes: Johannes> Set variables initialized in Johannes> lpfc_sli4_alloc_resource_identifiers() to NULL if an error Johannes> occurred. Otherwise, lpfc_sli4_driver_resource_unset() Johannes> attempts to free the memory again. Applied to 4.10/scsi-fixes. -- Martin K. Petersen Oracle Linux Engineering -- 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] qla4xxx: remove two unused MSI-X related #defines
> "Christoph" == Christoph Hellwig writes: Christoph> Spotted while preparing qla2xxx changes as the symbols exist Christoph> in both drivers (sigh..). Applied to 4.11/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering -- 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: two fixes for the qla2xxx MSI-X changes in 4.10-rc
> "Christoph" == Christoph Hellwig writes: Christoph> Hi Himanshu, two small updates to to a) fix the way affinity Christoph> is assigned for qla2xxx, and b) remove the dead interrupt Christoph> affinity notifiers. Applied to 4.10/scsi-fixes. -- Martin K. Petersen Oracle Linux Engineering -- 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 v1] scsi: ufs: fix arguments order some trace calls
> "Subhash" == Subhash Jadavani writes:
Subhash> Colin Ian King reported that with
Subhash> commit 7ff5ab473633 ("scsi: ufs: add tracing support") static
Subhash> analysis is reporting that we may have swapped arguments on
Subhash> calls to:
[...]
Applied to 4.11/scsi-queue.
--
Martin K. Petersen Oracle Linux Engineering
--
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] vmw_pvscsi: switch to pci_alloc_irq_vectors
> "Christoph" == Christoph Hellwig writes: Christoph> And simply the interrupt handler by splitting the INTx case Christoph> that needs to deal with shared interrupts into a separate Christoph> helper. Applied to 4.11/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering -- 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] virtio_scsi: Reject commands when virtqueue is broken
On Wed, 01/11 17:02, Eric Farman wrote:
> In the case of a graceful set of detaches, where the virtio-scsi-ccw
> disk is removed from the guest prior to the controller, the guest
> behaves quite normally. Specifically, the detach gets us into
> sd_sync_cache to issue a Synchronize Cache(10) command, which
> immediately fails (and is retried a couple of times) because the
> device has been removed. Later, the removal of the controller
> sees two CRWs presented, but there's no further indication of the
> removal from the guest viewpoint.
>
> [ 17.217458] sd 0:0:0:0: [sda] Synchronizing SCSI cache
> [ 17.219257] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result:
> hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
> [ 21.449400] crw_info : CRW reports slct=0, oflw=0, chn=1, rsc=3, anc=0,
> erc=4, rsid=2
> [ 21.449406] crw_info : CRW reports slct=0, oflw=0, chn=0, rsc=3, anc=0,
> erc=4, rsid=0
>
> However, on s390, the SCSI disks can be removed "by surprise" when
> an entire controller (host) is removed and all associated disks
> are removed via the loop in scsi_forget_host. The same call to
> sd_sync_cache is made, but because the controller has already
> been removed, the Synchronize Cache(10) command is neither issued
> (and then failed) nor rejected.
>
> That the I/O isn't returned means the guest cannot have other devices
> added nor removed, and other tasks (such as shutdown or reboot) issued
> by the guest will not complete either. The virtio ring has already
> been marked as broken (via virtio_break_device in virtio_ccw_remove),
> but we still attempt to queue the command only to have it remain there.
> The calling sequence provides a bit of distinction for us:
>
> virtscsi_queuecommand()
>-> virtscsi_kick_cmd()
> -> virtscsi_add_cmd()
> -> virtqueue_add_sgs()
> -> virtqueue_add()
> if success
>return 0
> elseif vq->broken or vring_mapping_error()
>return -EIO
> else
>return -ENOSPC
>
> A return of ENOSPC is generally a temporary condition, so returning
> "host busy" from virtscsi_queuecommand makes sense here, to have it
> redriven in a moment or two. But the EIO return code is more of a
> permanent error and so it would be wise to return the I/O itself and
> allow the calling thread to finish gracefully. The result is these
> four kernel messages in the guest (the fourth one does not occur
> prior to this patch):
>
> [ 22.921562] crw_info : CRW reports slct=0, oflw=0, chn=1, rsc=3, anc=0,
> erc=4, rsid=2
> [ 22.921580] crw_info : CRW reports slct=0, oflw=0, chn=0, rsc=3, anc=0,
> erc=4, rsid=0
> [ 22.921978] sd 0:0:0:0: [sda] Synchronizing SCSI cache
> [ 22.921993] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result:
> hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
>
> I opted to fill in the same response data that is returned from the
> more graceful device detach, where the disk device is removed prior
> to the controller device.
>
> Signed-off-by: Eric Farman
> ---
> drivers/scsi/virtio_scsi.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
> index ec91bd0..78d50ca 100644
> --- a/drivers/scsi/virtio_scsi.c
> +++ b/drivers/scsi/virtio_scsi.c
> @@ -535,6 +535,7 @@ static int virtscsi_queuecommand(struct virtio_scsi
> *vscsi,
> struct Scsi_Host *shost = virtio_scsi_host(vscsi->vdev);
> struct virtio_scsi_cmd *cmd = scsi_cmd_priv(sc);
> int req_size;
> + int ret;
>
> BUG_ON(scsi_sg_count(sc) > shost->sg_tablesize);
>
> @@ -562,8 +563,13 @@ static int virtscsi_queuecommand(struct virtio_scsi
> *vscsi,
> req_size = sizeof(cmd->req.cmd);
> }
>
> - if (virtscsi_kick_cmd(req_vq, cmd, req_size, sizeof(cmd->resp.cmd)) !=
> 0)
> + ret = virtscsi_kick_cmd(req_vq, cmd, req_size, sizeof(cmd->resp.cmd));
> + if (ret == -EIO) {
> + cmd->resp.cmd.response = VIRTIO_SCSI_S_BAD_TARGET;
> + virtscsi_complete_cmd(vscsi, cmd);
Is this safe? Calling virtscsi_complete_cmd requires vq_lock but we don't seem
to have it here.
Fam
> + } else if (ret != 0) {
> return SCSI_MLQUEUE_HOST_BUSY;
> + }
> return 0;
> }
--
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 62971] Kernel 3.11.1 and higher does not boot on VMware VM
https://bugzilla.kernel.org/show_bug.cgi?id=62971 Bojan Smojver changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX -- You are receiving this mail because: You are watching the assignee of 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
[PATCH v2 4/4] cxlflash: Cancel scheduled workers before stopping AFU
When processing an AFU asynchronous interrupt, if the action results in an
operation that requires off level processing (a link reset for example),
the worker thread is scheduled. In the meantime a reset event (i.e.: EEH)
could unmap the AFU to recover. This results in an Oops when the worker
thread tries to access the AFU mapping.
[c00f17e03b90] d7cd5978 cxlflash_worker_thread+0x268/0x550
[c00f17e03c40] c011883c process_one_work+0x1dc/0x680
[c00f17e03ce0] c0118e80 worker_thread+0x1a0/0x520
[c00f17e03d80] c0126174 kthread+0xf4/0x100
[c00f17e03e30] c000a47c ret_from_kernel_thread+0x5c/0xe0
In an effort to avoid this, a mapcount was introduced in
commit b45cdbaf9f7f ("cxlflash: Resolve oops in wait_port_offline")
but due to the race condition described above, this solution is incomplete.
In order to fully resolve this problem and to simplify things, this commit
removes the mapcount solution. Instead, the scheduled worker thread is
cancelled after interrupts have been disabled and prior to the mapping
being freed.
Fixes: b45cdbaf9f7f ("cxlflash: Resolve oops in wait_port_offline")
Signed-off-by: Uma Krishnan
Acked-by: Matthew R. Ochs
---
drivers/scsi/cxlflash/common.h | 2 --
drivers/scsi/cxlflash/main.c | 34 ++
2 files changed, 6 insertions(+), 30 deletions(-)
diff --git a/drivers/scsi/cxlflash/common.h b/drivers/scsi/cxlflash/common.h
index dee8657..d11dcc5 100644
--- a/drivers/scsi/cxlflash/common.h
+++ b/drivers/scsi/cxlflash/common.h
@@ -174,8 +174,6 @@ struct afu {
struct sisl_host_map __iomem *host_map; /* MC host map */
struct sisl_ctrl_map __iomem *ctrl_map; /* MC control map */
- struct kref mapcount;
-
ctx_hndl_t ctx_hndl;/* master's context handle */
atomic_t hsq_credits;
diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
index ab38bca..7069639 100644
--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -419,16 +419,6 @@ static int send_tmf(struct afu *afu, struct scsi_cmnd
*scp, u64 tmfcmd)
return rc;
}
-static void afu_unmap(struct kref *ref)
-{
- struct afu *afu = container_of(ref, struct afu, mapcount);
-
- if (likely(afu->afu_map)) {
- cxl_psa_unmap((void __iomem *)afu->afu_map);
- afu->afu_map = NULL;
- }
-}
-
/**
* cxlflash_driver_info() - information handler for this host driver
* @host: SCSI host associated with device.
@@ -459,7 +449,6 @@ static int cxlflash_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *scp)
ulong lock_flags;
int nseg = 0;
int rc = 0;
- int kref_got = 0;
dev_dbg_ratelimited(dev, "%s: (scp=%p) %d/%d/%d/%llu "
"cdb=(%08x-%08x-%08x-%08x)\n",
@@ -497,9 +486,6 @@ static int cxlflash_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *scp)
break;
}
- kref_get(&cfg->afu->mapcount);
- kref_got = 1;
-
if (likely(sg)) {
nseg = scsi_dma_map(scp);
if (unlikely(nseg < 0)) {
@@ -530,8 +516,6 @@ static int cxlflash_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *scp)
if (unlikely(rc))
scsi_dma_unmap(scp);
out:
- if (kref_got)
- kref_put(&afu->mapcount, afu_unmap);
return rc;
}
@@ -569,13 +553,15 @@ static void free_mem(struct cxlflash_cfg *cfg)
*
* Safe to call with AFU in a partially allocated/initialized state.
*
- * Waits for any active internal AFU commands to timeout and then unmaps
- * the MMIO space.
+ * Cancels scheduled worker threads, waits for any active internal AFU
+ * commands to timeout and then unmaps the MMIO space.
*/
static void stop_afu(struct cxlflash_cfg *cfg)
{
struct afu *afu = cfg->afu;
+ cancel_work_sync(&cfg->work_q);
+
if (likely(afu)) {
while (atomic_read(&afu->cmds_active))
ssleep(1);
@@ -583,7 +569,6 @@ static void stop_afu(struct cxlflash_cfg *cfg)
cxl_psa_unmap((void __iomem *)afu->afu_map);
afu->afu_map = NULL;
}
- kref_put(&afu->mapcount, afu_unmap);
}
}
@@ -767,7 +752,6 @@ static void cxlflash_remove(struct pci_dev *pdev)
scsi_remove_host(cfg->host);
/* fall through */
case INIT_STATE_AFU:
- cancel_work_sync(&cfg->work_q);
term_afu(cfg);
case INIT_STATE_PCI:
pci_disable_device(pdev);
@@ -1277,7 +1261,6 @@ static irqreturn_t cxlflash_async_err_irq(int irq, void
*data)
__func__, port);
cfg->lr_state = LINK_RESET_REQUIRED;
cfg->lr_port = port;
- kref_get(&cfg->afu->mapcount);
schedule_w
[PATCH v2 1/4] cxlflash: Refactor context reset to share reset logic
From: "Matthew R. Ochs"
As staging for supporting hardware with different context reset
registers but a similar reset procedure, refactor the existing context
reset routine to move the reset logic to a common routine. This will
allow hardware with a different reset register to leverage existing
code.
Signed-off-by: Matthew R. Ochs
Signed-off-by: Uma Krishnan
---
drivers/scsi/cxlflash/main.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
index b17ebf6..a990efb 100644
--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -188,10 +188,11 @@ static void cmd_complete(struct afu_cmd *cmd)
}
/**
- * context_reset_ioarrin() - reset command owner context via IOARRIN register
+ * context_reset() - reset command owner context via specified register
* @cmd: AFU command that timed out.
+ * @reset_reg: MMIO register to perform reset.
*/
-static void context_reset_ioarrin(struct afu_cmd *cmd)
+static void context_reset(struct afu_cmd *cmd, __be64 __iomem *reset_reg)
{
int nretry = 0;
u64 rrin = 0x1;
@@ -201,9 +202,9 @@ static void context_reset_ioarrin(struct afu_cmd *cmd)
pr_debug("%s: cmd=%p\n", __func__, cmd);
- writeq_be(rrin, &afu->host_map->ioarrin);
+ writeq_be(rrin, reset_reg);
do {
- rrin = readq_be(&afu->host_map->ioarrin);
+ rrin = readq_be(reset_reg);
if (rrin != 0x1)
break;
/* Double delay each time */
@@ -215,6 +216,17 @@ static void context_reset_ioarrin(struct afu_cmd *cmd)
}
/**
+ * context_reset_ioarrin() - reset command owner context via IOARRIN register
+ * @cmd: AFU command that timed out.
+ */
+static void context_reset_ioarrin(struct afu_cmd *cmd)
+{
+ struct afu *afu = cmd->parent;
+
+ context_reset(cmd, &afu->host_map->ioarrin);
+}
+
+/**
* send_cmd_ioarrin() - sends an AFU command via IOARRIN register
* @afu: AFU associated with the host.
* @cmd: AFU command to send.
--
2.1.0
--
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 v2 3/4] cxlflash: Cleanup prints
From: "Matthew R. Ochs"
The usage of prints within the cxlflash driver is inconsistent. This
hinders debug and makes the driver source and log output appear sloppy.
The following cleanups help unify the prints within cxlflash:
- move all prints to dev-* where possible
- transition all hex prints to lowercase
- standardize variable prints in debug output
- derive pointers in a consistent manner
- change int to bool where appropriate
- remove superfluous data from prints and print statements that do not
make sense
Signed-off-by: Matthew R. Ochs
Signed-off-by: Uma Krishnan
Reviewed-by: Andrew Donnellan
---
drivers/scsi/cxlflash/lunmgt.c| 31 ++--
drivers/scsi/cxlflash/main.c | 319 ++
drivers/scsi/cxlflash/superpipe.c | 165 ++--
drivers/scsi/cxlflash/vlun.c | 169 ++--
4 files changed, 346 insertions(+), 338 deletions(-)
diff --git a/drivers/scsi/cxlflash/lunmgt.c b/drivers/scsi/cxlflash/lunmgt.c
index 6c318db9..0efed17 100644
--- a/drivers/scsi/cxlflash/lunmgt.c
+++ b/drivers/scsi/cxlflash/lunmgt.c
@@ -32,11 +32,13 @@
*/
static struct llun_info *create_local(struct scsi_device *sdev, u8 *wwid)
{
+ struct cxlflash_cfg *cfg = shost_priv(sdev->host);
+ struct device *dev = &cfg->dev->dev;
struct llun_info *lli = NULL;
lli = kzalloc(sizeof(*lli), GFP_KERNEL);
if (unlikely(!lli)) {
- pr_err("%s: could not allocate lli\n", __func__);
+ dev_err(dev, "%s: could not allocate lli\n", __func__);
goto out;
}
@@ -58,11 +60,13 @@ static struct llun_info *create_local(struct scsi_device
*sdev, u8 *wwid)
*/
static struct glun_info *create_global(struct scsi_device *sdev, u8 *wwid)
{
+ struct cxlflash_cfg *cfg = shost_priv(sdev->host);
+ struct device *dev = &cfg->dev->dev;
struct glun_info *gli = NULL;
gli = kzalloc(sizeof(*gli), GFP_KERNEL);
if (unlikely(!gli)) {
- pr_err("%s: could not allocate gli\n", __func__);
+ dev_err(dev, "%s: could not allocate gli\n", __func__);
goto out;
}
@@ -129,10 +133,10 @@ static struct glun_info *lookup_global(u8 *wwid)
*/
static struct llun_info *find_and_create_lun(struct scsi_device *sdev, u8
*wwid)
{
+ struct cxlflash_cfg *cfg = shost_priv(sdev->host);
+ struct device *dev = &cfg->dev->dev;
struct llun_info *lli = NULL;
struct glun_info *gli = NULL;
- struct Scsi_Host *shost = sdev->host;
- struct cxlflash_cfg *cfg = shost_priv(shost);
if (unlikely(!wwid))
goto out;
@@ -165,7 +169,7 @@ static struct llun_info *find_and_create_lun(struct
scsi_device *sdev, u8 *wwid)
list_add(&gli->list, &global.gluns);
out:
- pr_debug("%s: returning %p\n", __func__, lli);
+ dev_dbg(dev, "%s: returning lli=%p, gli=%p\n", __func__, lli, gli);
return lli;
}
@@ -225,17 +229,18 @@ void cxlflash_term_global_luns(void)
int cxlflash_manage_lun(struct scsi_device *sdev,
struct dk_cxlflash_manage_lun *manage)
{
- int rc = 0;
+ struct cxlflash_cfg *cfg = shost_priv(sdev->host);
+ struct device *dev = &cfg->dev->dev;
struct llun_info *lli = NULL;
+ int rc = 0;
u64 flags = manage->hdr.flags;
u32 chan = sdev->channel;
mutex_lock(&global.mutex);
lli = find_and_create_lun(sdev, manage->wwid);
- pr_debug("%s: ENTER: WWID = %016llX%016llX, flags = %016llX li = %p\n",
-__func__, get_unaligned_be64(&manage->wwid[0]),
-get_unaligned_be64(&manage->wwid[8]),
-manage->hdr.flags, lli);
+ dev_dbg(dev, "%s: WWID=%016llx%016llx, flags=%016llx lli=%p\n",
+ __func__, get_unaligned_be64(&manage->wwid[0]),
+ get_unaligned_be64(&manage->wwid[8]), manage->hdr.flags, lli);
if (unlikely(!lli)) {
rc = -ENOMEM;
goto out;
@@ -265,11 +270,11 @@ int cxlflash_manage_lun(struct scsi_device *sdev,
}
}
- pr_debug("%s: port_sel = %08X chan = %u lun_id = %016llX\n", __func__,
-lli->port_sel, chan, lli->lun_id[chan]);
+ dev_dbg(dev, "%s: port_sel=%08x chan=%u lun_id=%016llx\n",
+ __func__, lli->port_sel, chan, lli->lun_id[chan]);
out:
mutex_unlock(&global.mutex);
- pr_debug("%s: returning rc=%d\n", __func__, rc);
+ dev_dbg(dev, "%s: returning rc=%d\n", __func__, rc);
return rc;
}
diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
index d2bac4b..ab38bca 100644
--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -43,6 +43,9 @@ MODULE_LICENSE("GPL");
*/
static void process_cmd_err(struct afu_cmd *cmd, struct scsi_cmnd *scp)
{
+ struct afu *afu = cmd->parent;
+ struct cxlflash_cfg *cfg = af
[PATCH v2 2/4] cxlflash: Support SQ Command Mode
From: "Matthew R. Ochs"
The SISLite specification outlines a new queuing model to improve
over the MMIO-based IOARRIN model that exists today. This new model
uses a submission queue that exists in host memory and is shared with
the device. Each entry in the queue is an IOARCB that describes a
transfer request. When requests are submitted, IOARCBs ('current'
position tracked in host software) are populated and the submission
queue tail pointer is then updated via MMIO to make the device aware
of the requests.
Signed-off-by: Matthew R. Ochs
Signed-off-by: Uma Krishnan
---
drivers/scsi/cxlflash/common.h | 30 +++-
drivers/scsi/cxlflash/main.c | 98 --
drivers/scsi/cxlflash/sislite.h| 19 +++-
drivers/scsi/cxlflash/superpipe.c | 18 +--
include/uapi/scsi/cxlflash_ioctl.h | 1 +
5 files changed, 153 insertions(+), 13 deletions(-)
diff --git a/drivers/scsi/cxlflash/common.h b/drivers/scsi/cxlflash/common.h
index 0e9de5d..dee8657 100644
--- a/drivers/scsi/cxlflash/common.h
+++ b/drivers/scsi/cxlflash/common.h
@@ -54,6 +54,9 @@ extern const struct file_operations cxlflash_cxl_fops;
/* RRQ for master issued cmds */
#define NUM_RRQ_ENTRY CXLFLASH_MAX_CMDS
+/* SQ for master issued cmds */
+#define NUM_SQ_ENTRY CXLFLASH_MAX_CMDS
+
static inline void check_sizes(void)
{
@@ -155,8 +158,8 @@ static inline struct afu_cmd *sc_to_afucz(struct scsi_cmnd
*sc)
struct afu {
/* Stuff requiring alignment go first. */
-
- u64 rrq_entry[NUM_RRQ_ENTRY]; /* 2K RRQ */
+ struct sisl_ioarcb sq[NUM_SQ_ENTRY];/* 16K SQ */
+ u64 rrq_entry[NUM_RRQ_ENTRY]; /* 2K RRQ */
/* Beware of alignment till here. Preferably introduce new
* fields after this point
@@ -174,6 +177,12 @@ struct afu {
struct kref mapcount;
ctx_hndl_t ctx_hndl;/* master's context handle */
+
+ atomic_t hsq_credits;
+ spinlock_t hsq_slock;
+ struct sisl_ioarcb *hsq_start;
+ struct sisl_ioarcb *hsq_end;
+ struct sisl_ioarcb *hsq_curr;
u64 *hrrq_start;
u64 *hrrq_end;
u64 *hrrq_curr;
@@ -191,6 +200,23 @@ struct afu {
};
+static inline bool afu_is_cmd_mode(struct afu *afu, u64 cmd_mode)
+{
+ u64 afu_cap = afu->interface_version >> SISL_INTVER_CAP_SHIFT;
+
+ return afu_cap & cmd_mode;
+}
+
+static inline bool afu_is_sq_cmd_mode(struct afu *afu)
+{
+ return afu_is_cmd_mode(afu, SISL_INTVER_CAP_SQ_CMD_MODE);
+}
+
+static inline bool afu_is_ioarrin_cmd_mode(struct afu *afu)
+{
+ return afu_is_cmd_mode(afu, SISL_INTVER_CAP_IOARRIN_CMD_MODE);
+}
+
static inline u64 lun_to_lunid(u64 lun)
{
__be64 lun_id;
diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
index a990efb..d2bac4b 100644
--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -227,6 +227,17 @@ static void context_reset_ioarrin(struct afu_cmd *cmd)
}
/**
+ * context_reset_sq() - reset command owner context w/ SQ Context Reset
register
+ * @cmd: AFU command that timed out.
+ */
+static void context_reset_sq(struct afu_cmd *cmd)
+{
+ struct afu *afu = cmd->parent;
+
+ context_reset(cmd, &afu->host_map->sq_ctx_reset);
+}
+
+/**
* send_cmd_ioarrin() - sends an AFU command via IOARRIN register
* @afu: AFU associated with the host.
* @cmd: AFU command to send.
@@ -269,6 +280,49 @@ static int send_cmd_ioarrin(struct afu *afu, struct
afu_cmd *cmd)
}
/**
+ * send_cmd_sq() - sends an AFU command via SQ ring
+ * @afu: AFU associated with the host.
+ * @cmd: AFU command to send.
+ *
+ * Return:
+ * 0 on success, SCSI_MLQUEUE_HOST_BUSY on failure
+ */
+static int send_cmd_sq(struct afu *afu, struct afu_cmd *cmd)
+{
+ struct cxlflash_cfg *cfg = afu->parent;
+ struct device *dev = &cfg->dev->dev;
+ int rc = 0;
+ int newval;
+ ulong lock_flags;
+
+ newval = atomic_dec_if_positive(&afu->hsq_credits);
+ if (newval <= 0) {
+ rc = SCSI_MLQUEUE_HOST_BUSY;
+ goto out;
+ }
+
+ cmd->rcb.ioasa = &cmd->sa;
+
+ spin_lock_irqsave(&afu->hsq_slock, lock_flags);
+
+ *afu->hsq_curr = cmd->rcb;
+ if (afu->hsq_curr < afu->hsq_end)
+ afu->hsq_curr++;
+ else
+ afu->hsq_curr = afu->hsq_start;
+ writeq_be((u64)afu->hsq_curr, &afu->host_map->sq_tail);
+
+ spin_unlock_irqrestore(&afu->hsq_slock, lock_flags);
+out:
+ dev_dbg(dev, "%s: cmd=%p len=%d ea=%p ioasa=%p rc=%d curr=%p "
+ "head=%016llX tail=%016llX\n", __func__, cmd, cmd->rcb.data_len,
+ (void *)cmd->rcb.data_ea, cmd->rcb.ioasa, rc, afu->hsq_curr,
+ readq_be(&afu->host_map->sq_head),
+ readq_be(&afu->host_map->sq_tail));
+ return rc;
+}
+
+/**
* wait_resp() - polls for a response or timeout
[PATCH v2 0/4] cxlflash: Enhancements, cleanup and fixes
This patch series includes an enhancement to support a new command queuing model and also cleans up prints throughout the driver. The last patch in the series fixes a racing issue. The series is based upon v4.10-rc2, intended for 4.11 and is bisectable. v2 Changes: - Fixed SOBs for all the submitted patches Matthew R. Ochs (3): cxlflash: Refactor context reset to share reset logic cxlflash: Support SQ Command Mode cxlflash: Cleanup prints Uma Krishnan (1): cxlflash: Cancel scheduled workers before stopping AFU drivers/scsi/cxlflash/common.h | 32 ++- drivers/scsi/cxlflash/lunmgt.c | 31 +-- drivers/scsi/cxlflash/main.c | 465 + drivers/scsi/cxlflash/sislite.h| 19 +- drivers/scsi/cxlflash/superpipe.c | 183 --- drivers/scsi/cxlflash/vlun.c | 169 +++--- include/uapi/scsi/cxlflash_ioctl.h | 1 + 7 files changed, 518 insertions(+), 382 deletions(-) -- 2.1.0 -- 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 05/15] dm: remove incomple BLOCK_PC support
On Tue, Jan 10 2017 at 10:06am -0500,
Christoph Hellwig wrote:
> DM tries to copy a few fields around for BLOCK_PC requests, but given
> that no dm-target ever wires up scsi_cmd_ioctl BLOCK_PC can't actually
> be sent to dm.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/md/dm-rq.c | 16
> 1 file changed, 16 deletions(-)
>
> diff --git a/drivers/md/dm-rq.c b/drivers/md/dm-rq.c
> index 93f6e9f..3f12916 100644
> --- a/drivers/md/dm-rq.c
> +++ b/drivers/md/dm-rq.c
> @@ -270,19 +270,6 @@ static void dm_end_request(struct request *clone, int
> error)
> struct mapped_device *md = tio->md;
> struct request *rq = tio->orig;
>
> - if (rq->cmd_type == REQ_TYPE_BLOCK_PC) {
> - rq->errors = clone->errors;
> - rq->resid_len = clone->resid_len;
> -
> - if (rq->sense)
> - /*
> - * We are using the sense buffer of the original
> - * request.
> - * So setting the length of the sense data is enough.
> - */
> - rq->sense_len = clone->sense_len;
> - }
> -
> free_rq_clone(clone);
> rq_end_stats(md, rq);
> if (!rq->q->mq_ops)
> @@ -511,9 +498,6 @@ static int setup_clone(struct request *clone, struct
> request *rq,
> if (r)
> return r;
>
> - clone->cmd = rq->cmd;
> - clone->cmd_len = rq->cmd_len;
> - clone->sense = rq->sense;
> clone->end_io = end_clone_request;
> clone->end_io_data = tio;
>
I'm not following your reasoning.
dm_blk_ioctl calls __blkdev_driver_ioctl and will call scsi_cmd_ioctl
(sd_ioctl -> scsi_cmd_blk_ioctl -> scsi_cmd_ioctl) if DM's underlying
block device is a scsi device.
--
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] drivers: block: Remove unnecessary cast
Quoting Greg KH : On Wed, Jan 11, 2017 at 12:41:05PM -0600, Gustavo A. R. Silva wrote: This issue was detected using Coccinelle and the following semantic patch: @@ expression * e; expression arg1, arg2; type T; @@ - e = (T *) + e = kmalloc(arg1, arg2); Signed-off-by: Gustavo A. R. Silva --- drivers/block/cciss_scsi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Why send this to me? Oops... Sorry... I was also working with the Staging tree, so it seems your e-mail address got in the middle at some point. -- Gustavo A. R. Silva -- 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] vmw_pvscsi: switch to pci_alloc_irq_vectors
acked by Jim Gill (jg...@vmware.com)
looks good to me.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/vmw_pvscsi.c | 104 +-
drivers/scsi/vmw_pvscsi.h | 5 ---
2 files changed, 38 insertions(+), 71 deletions(-)
diff --git a/drivers/scsi/vmw_pvscsi.c b/drivers/scsi/vmw_pvscsi.c
index 4a0d3cd..642dd4e 100644
--- a/drivers/scsi/vmw_pvscsi.c
+++ b/drivers/scsi/vmw_pvscsi.c
@@ -68,10 +68,7 @@ struct pvscsi_ctx {
struct pvscsi_adapter {
char *mmioBase;
- unsigned int irq;
u8 rev;
- bool use_msi;
- bool use_msix;
bool use_msg;
bool use_req_threshold;
@@ -1160,30 +1157,26 @@ static bool pvscsi_setup_req_threshold(struct
pvscsi_adapter *adapter,
static irqreturn_t pvscsi_isr(int irq, void *devp)
{
struct pvscsi_adapter *adapter = devp;
- int handled;
-
- if (adapter->use_msi || adapter->use_msix)
- handled = true;
- else {
- u32 val = pvscsi_read_intr_status(adapter);
- handled = (val & PVSCSI_INTR_ALL_SUPPORTED) != 0;
- if (handled)
- pvscsi_write_intr_status(devp, val);
- }
-
- if (handled) {
- unsigned long flags;
+ unsigned long flags;
- spin_lock_irqsave(&adapter->hw_lock, flags);
+ spin_lock_irqsave(&adapter->hw_lock, flags);
+ pvscsi_process_completion_ring(adapter);
+ if (adapter->use_msg && pvscsi_msg_pending(adapter))
+ queue_work(adapter->workqueue, &adapter->work);
+ spin_unlock_irqrestore(&adapter->hw_lock, flags);
- pvscsi_process_completion_ring(adapter);
- if (adapter->use_msg && pvscsi_msg_pending(adapter))
- queue_work(adapter->workqueue, &adapter->work);
+ return IRQ_HANDLED;
+}
- spin_unlock_irqrestore(&adapter->hw_lock, flags);
- }
+static irqreturn_t pvscsi_shared_isr(int irq, void *devp)
+{
+ struct pvscsi_adapter *adapter = devp;
+ u32 val = pvscsi_read_intr_status(adapter);
- return IRQ_RETVAL(handled);
+ if (!(val & PVSCSI_INTR_ALL_SUPPORTED))
+ return IRQ_NONE;
+ pvscsi_write_intr_status(devp, val);
+ return pvscsi_isr(irq, devp);
}
static void pvscsi_free_sgls(const struct pvscsi_adapter *adapter)
@@ -1195,34 +1188,10 @@ static void pvscsi_free_sgls(const struct
pvscsi_adapter *adapter)
free_pages((unsigned long)ctx->sgl, get_order(SGL_SIZE));
}
-static int pvscsi_setup_msix(const struct pvscsi_adapter *adapter,
- unsigned int *irq)
-{
- struct msix_entry entry = { 0, PVSCSI_VECTOR_COMPLETION };
- int ret;
-
- ret = pci_enable_msix_exact(adapter->dev, &entry, 1);
- if (ret)
- return ret;
-
- *irq = entry.vector;
-
- return 0;
-}
-
static void pvscsi_shutdown_intr(struct pvscsi_adapter *adapter)
{
- if (adapter->irq) {
- free_irq(adapter->irq, adapter);
- adapter->irq = 0;
- }
- if (adapter->use_msi) {
- pci_disable_msi(adapter->dev);
- adapter->use_msi = 0;
- } else if (adapter->use_msix) {
- pci_disable_msix(adapter->dev);
- adapter->use_msix = 0;
- }
+ free_irq(pci_irq_vector(adapter->dev, 0), adapter);
+ pci_free_irq_vectors(adapter->dev);
}
static void pvscsi_release_resources(struct pvscsi_adapter *adapter)
@@ -1358,11 +1327,11 @@ static u32 pvscsi_get_max_targets(struct pvscsi_adapter
*adapter)
static int pvscsi_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
+ unsigned int irq_flag = PCI_IRQ_MSIX | PCI_IRQ_MSI | PCI_IRQ_LEGACY;
struct pvscsi_adapter *adapter;
struct pvscsi_adapter adapter_temp;
struct Scsi_Host *host = NULL;
unsigned int i;
- unsigned long flags = 0;
int error;
u32 max_id;
@@ -1511,30 +1480,33 @@ static int pvscsi_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
goto out_reset_adapter;
}
- if (!pvscsi_disable_msix &&
- pvscsi_setup_msix(adapter, &adapter->irq) == 0) {
- printk(KERN_INFO "vmw_pvscsi: using MSI-X\n");
- adapter->use_msix = 1;
- } else if (!pvscsi_disable_msi && pci_enable_msi(pdev) == 0) {
- printk(KERN_INFO "vmw_pvscsi: using MSI\n");
- adapter->use_msi = 1;
- adapter->irq = pdev->irq;
- } else {
- printk(KERN_INFO "vmw_pvscsi: using INTx\n");
- adapter->irq = pdev->irq;
- flags = IRQF_SHARED;
- }
+ if (pvscsi_disable_msix)
+
Re: [PATCH 02/11] qla2xxx: Cleanup TMF code translation from qla_target.
On 1/11/17, 1:08 PM, "Bart Van Assche" wrote: >On 12/23/2016 08:23 PM, Himanshu Madhani wrote: >> From: Quinn Tran >> >> Move code code which converts Task Mgmt Command flags for >> ATIO to TCM #defines, from qla2xxx driver to tcm_qla2xxx >> driver. >> >> Reviewed-by: Christoph Hellwig >> Signed-off-by: Quinn Tran >> Signed-off-by: Himanshu Madhani >> --- >> drivers/scsi/qla2xxx/qla_target.c | 75 >> -- >> drivers/scsi/qla2xxx/qla_target.h | 6 ++- >> drivers/scsi/qla2xxx/tcm_qla2xxx.c | 39 +++- >> 3 files changed, 49 insertions(+), 71 deletions(-) >> >> diff --git a/drivers/scsi/qla2xxx/qla_target.c >> b/drivers/scsi/qla2xxx/qla_target.c >> index 47acc26..6e58848 100644 >> --- a/drivers/scsi/qla2xxx/qla_target.c >> +++ b/drivers/scsi/qla2xxx/qla_target.c >> @@ -1592,8 +1592,9 @@ static int __qlt_24xx_handle_abts(struct scsi_qla_host >> *vha, >> mcmd->sess = sess; >> memcpy(&mcmd->orig_iocb.abts, abts, sizeof(mcmd->orig_iocb.abts)); >> mcmd->reset_count = vha->hw->chip_reset; >> +mcmd->tmr_func = QLA_TGT_ABTS; >> >> -rc = ha->tgt.tgt_ops->handle_tmr(mcmd, lun, TMR_ABORT_TASK, >> +rc = ha->tgt.tgt_ops->handle_tmr(mcmd, 0, mcmd->tmr_func, >> abts->exchange_addr_to_abort); > >Does this change remove the last user of the 'lun' variable from this >function? If so, please remove that variable entirely. We will need to preserve lun variable, since handle_tmr is also called from qlt_issue_task_mgmt and qlt_handle_task_mgmt. > >Thanks, > >Bart.
Re: RFC: split scsi passthrough fields out of struct request
On Tue, Jan 10 2017 at 10:06am -0500, Christoph Hellwig wrote: > Hi all, > > this series splits the support for SCSI passthrough commands from the > main struct request used all over the block layer into a separate > scsi_request structure that drivers that want to support SCSI passthough > need to embedded as the first thing into their request-private data, > similar to how we handle NVMe passthrough commands. > > To support this I've added support for that the private data after > request structure to the legacy request path instead, so that it can > be treated the same way as the blk-mq path. Compare to the current > scsi_cmnd allocator that actually is a major simplification. > > There is one major show-stopper for the series as-is: Request-based > device mapper currently allocate the request structures in the stacking > driver without a knowledge of the queue it's going to be submitte on > for the legacy request path. It managed to avoid that issue for the > blk-mq path, but that currently can't be used on legacy request devices > for reasons I don't fully understand. We'll need to figure out how > sort this out, but maybe that's a good opportunity to drop one or two > of the three different dm-mpath I/O paths? :) Ah, should've read the 0th patch earlier.. I removed blk-mq on request_fn paths support because it was one of the permutations that I felt least useful/stable (see commit c5248f79f3 "dm: remove support for stacking dm-mq on .request_fn device(s)") As for all of the different IO paths. I've always liked the idea of blk-mq ruling the world. With Jens' blk-mq IO scheduling advances maybe we're closer! -- 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: [LSF/MM TOPIC][LSF/MM ATTEND] multipath redesign
On Wed, Jan 11 2017 at 4:44am -0500, Hannes Reinecke wrote: > Hi all, > > I'd like to attend LSF/MM this year, and would like to discuss a > redesign of the multipath handling. > > With recent kernels we've got quite some functionality required for > multipathing already implemented, making some design decisions of the > original multipath-tools implementation quite pointless. > > I'm working on a proof-of-concept implementation which just uses a > simple configfs interface and doesn't require a daemon altogether. > > At LSF/MM I'd like to discuss how to move forward here, and whether we'd > like to stay with the current device-mapper integration or move away > from that towards a stand-alone implementation. I'd really like open exchange of the problems you're having with the current multipath-tools and DM multipath _before LSF_. Last LSF only scratched the surface on people having disdain for the complexity that is the multipath-tools userspace. But considering how much of the multipath-tools you've written I find it fairly comical that you're the person advocating switching away from it. But if less userspace involvement is needed then fix userspace. Fail to see how configfs is any different than the established DM ioctl interface. As I just said in another email DM multipath could benefit from factoring out the SCSI-specific bits so that they are nicely optimized away if using new transports (e.g. NVMEoF). Could be lessons can be learned from your approach but I'd prefer we provably exhaust the utility of the current DM multipath kernel implementation. DM multipath is one of the most actively maintained and updated DM targets (aside from thinp and cache). As you know DM multipath has grown blk-mq support which yielded serious performance improvement. You also noted (in an earlier email) that I reintroduced bio-based DM multipath. On a data path level we have all possible block core interfaces plumbed. And yes, they all involve cloning due to the underlying Device Mapper core. Open to any ideas on optimization. If DM is imposing some inherent performance limitation then please report it accordingly. -- 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 14/15] block/bsg: move queue creation into bsg_setup_queue
On Wed, Jan 11 2017 at 4:37am -0500, Hannes Reinecke wrote: > On 01/11/2017 10:01 AM, Christoph Hellwig wrote: > > On Wed, Jan 11, 2017 at 09:59:17AM +0100, Hannes Reinecke wrote: > >> I'd advocate to discuss this at LSF. > >> Now that Mike moved the bio-based mpath stuff back in things got even > >> more complex. > > > > Yeah. If we'd _only_ have bio based support it would simplify things > > a lot, but as a third parallel path it's not exactly making things easier. > > > >> I'll be posting a patchset for reimplementing multipath as a stand-alone > >> driver shortly; that'll give us a good starting point on how we want > >> multipath to evolve. > >> > >> Who knows; we might even manage to move multipath out of device-mapper > >> altogether. > >> That would make Mike very happy, and I wouldn't mind, either :-) > > > > Heh. I'm curious how you want to do that while keeping existing setups > > working, though. > > which will become challenging, indeed. > > ATM it's just a testbed on how things could work; we've got most of the > required infrastucture in the kernel nowadays, so that we can just drop > most of the complexity from the present multipath-tools mess. > > In the end it might even boil down to update the existing device-mapper > multipath implementation. We'll see. Honestly, at this point I'm pretty confident you guys will never actually produce a new NIH multipath. You'll just threaten to for _years_. Joking aside, I think DM multipath would benefit from a more focused separation from all the SCSI cruft that wormed its way in. Factoring that stuff out so that multipath can be more easily adapted/optimized for use with leaner transports like NVMe-over-fabrics. But NVMe-over-fabrics setups are still pretty rare (only a handful of vendors are stepping up with requirements to support it) so details on what change is needed to DM multipath is largely unknown to me. But may become clearer in the coming month. Mike -- 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] virtio_scsi: Reject commands when virtqueue is broken
In the case of a graceful set of detaches, where the virtio-scsi-ccw
disk is removed from the guest prior to the controller, the guest
behaves quite normally. Specifically, the detach gets us into
sd_sync_cache to issue a Synchronize Cache(10) command, which
immediately fails (and is retried a couple of times) because the
device has been removed. Later, the removal of the controller
sees two CRWs presented, but there's no further indication of the
removal from the guest viewpoint.
[ 17.217458] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 17.219257] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result:
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 21.449400] crw_info : CRW reports slct=0, oflw=0, chn=1, rsc=3, anc=0,
erc=4, rsid=2
[ 21.449406] crw_info : CRW reports slct=0, oflw=0, chn=0, rsc=3, anc=0,
erc=4, rsid=0
However, on s390, the SCSI disks can be removed "by surprise" when
an entire controller (host) is removed and all associated disks
are removed via the loop in scsi_forget_host. The same call to
sd_sync_cache is made, but because the controller has already
been removed, the Synchronize Cache(10) command is neither issued
(and then failed) nor rejected.
That the I/O isn't returned means the guest cannot have other devices
added nor removed, and other tasks (such as shutdown or reboot) issued
by the guest will not complete either. The virtio ring has already
been marked as broken (via virtio_break_device in virtio_ccw_remove),
but we still attempt to queue the command only to have it remain there.
The calling sequence provides a bit of distinction for us:
virtscsi_queuecommand()
-> virtscsi_kick_cmd()
-> virtscsi_add_cmd()
-> virtqueue_add_sgs()
-> virtqueue_add()
if success
return 0
elseif vq->broken or vring_mapping_error()
return -EIO
else
return -ENOSPC
A return of ENOSPC is generally a temporary condition, so returning
"host busy" from virtscsi_queuecommand makes sense here, to have it
redriven in a moment or two. But the EIO return code is more of a
permanent error and so it would be wise to return the I/O itself and
allow the calling thread to finish gracefully. The result is these
four kernel messages in the guest (the fourth one does not occur
prior to this patch):
[ 22.921562] crw_info : CRW reports slct=0, oflw=0, chn=1, rsc=3, anc=0,
erc=4, rsid=2
[ 22.921580] crw_info : CRW reports slct=0, oflw=0, chn=0, rsc=3, anc=0,
erc=4, rsid=0
[ 22.921978] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 22.921993] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result:
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
I opted to fill in the same response data that is returned from the
more graceful device detach, where the disk device is removed prior
to the controller device.
Signed-off-by: Eric Farman
---
drivers/scsi/virtio_scsi.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index ec91bd0..78d50ca 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -535,6 +535,7 @@ static int virtscsi_queuecommand(struct virtio_scsi *vscsi,
struct Scsi_Host *shost = virtio_scsi_host(vscsi->vdev);
struct virtio_scsi_cmd *cmd = scsi_cmd_priv(sc);
int req_size;
+ int ret;
BUG_ON(scsi_sg_count(sc) > shost->sg_tablesize);
@@ -562,8 +563,13 @@ static int virtscsi_queuecommand(struct virtio_scsi *vscsi,
req_size = sizeof(cmd->req.cmd);
}
- if (virtscsi_kick_cmd(req_vq, cmd, req_size, sizeof(cmd->resp.cmd)) !=
0)
+ ret = virtscsi_kick_cmd(req_vq, cmd, req_size, sizeof(cmd->resp.cmd));
+ if (ret == -EIO) {
+ cmd->resp.cmd.response = VIRTIO_SCSI_S_BAD_TARGET;
+ virtscsi_complete_cmd(vscsi, cmd);
+ } else if (ret != 0) {
return SCSI_MLQUEUE_HOST_BUSY;
+ }
return 0;
}
--
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] virtio_scsi: Reject commands when virtqueue is broken
While doing some disruptive testing with QEMU/KVM, I have encountered some
guest problems during hot unplug of virtio-scsi devices depending on the
order of operations in which they are performed. The following notes
describe my setup (s390x), and how I'm able to reproduce the error and
test the attached fix.
In both the "working" and "failing" case, the detaches appear to work
just fine. Any sign of problems only begin to appear later based on
other actions I may perform, such as powering off the guest system.
Host:
# lsscsi -g | grep sg6
[6:0:6:1074151456]diskIBM 2107900 .217 /dev/sdg /dev/sg6
QEMU:
- Include the following parameters
-device virtio-scsi-ccw,id=scsi0
-drive file=/dev/sg6,if=none,id=drive0,format=raw
-device
scsi-generic,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive0,id=hostdev6
- QMP commands (working)
- device_del hostdev6
- device_del scsi0
- QMP commands (failing)
- device_del scsi0
Libvirt:
- Note: A preventative fix went into Libvirt 2.5.0
(libvirt commit 655429a0d4a5 ("qemu: Prevent detaching SCSI controller used
by hostdev"))
- Include the following XML
# cat scsicontroller.xml
# cat scsihostdev.xml
- virsh commands (working)
- virsh detach-device guest scsihostdev.xml
- virsh detach-device guest scsicontroller.xml
- virsh commands (failing)
- virsh detach-device guest scsicontroller.xml
Eric Farman (1):
virtio_scsi: Reject commands when virtqueue is broken
drivers/scsi/virtio_scsi.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
--
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
Re: [PATCH 14/15] block/bsg: move queue creation into bsg_setup_queue
On Wed, Jan 11 2017 at 3:45am -0500, Christoph Hellwig wrote: > On Wed, Jan 11, 2017 at 09:42:44AM +0100, Johannes Thumshirn wrote: > > On Tue, Jan 10, 2017 at 04:06:19PM +0100, Christoph Hellwig wrote: > > > Simply the boilerplate code needed for bsg nodes a bit. > > > > > > Signed-off-by: Christoph Hellwig > > > --- > > > > that reminds me of posting my SAS bsg-lib patch... > > Yes. Having SAS use bsg-lib, and bsg-lib switched away from abusing > struct request_queue would make this series a lot cleaner. > > So maybe we should get that into the scsi tree for 4.10 together > with the prep patches in this series as a priority and defer the actual > struct request changes once again. That should also give us some more > time to sort out the dm-mpath story.. I'm not aware of the story you're referring to. I'm missing the actual challenge you're facing. But I've seen you reference the need to stop multipath from allocating its own requests. Are you referring to old request_fn request-based multipath's clone_old_rq:alloc_old_clone_request? Or how blk-mq request-based multipath gets a request from the blk-mq tag space (via blk_mq_alloc_request)? Or both? How is that holding you back? -- 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 02/11] qla2xxx: Cleanup TMF code translation from qla_target.
On 12/23/2016 08:23 PM, Himanshu Madhani wrote: > From: Quinn Tran > > Move code code which converts Task Mgmt Command flags for > ATIO to TCM #defines, from qla2xxx driver to tcm_qla2xxx > driver. > > Reviewed-by: Christoph Hellwig > Signed-off-by: Quinn Tran > Signed-off-by: Himanshu Madhani > --- > drivers/scsi/qla2xxx/qla_target.c | 75 > -- > drivers/scsi/qla2xxx/qla_target.h | 6 ++- > drivers/scsi/qla2xxx/tcm_qla2xxx.c | 39 +++- > 3 files changed, 49 insertions(+), 71 deletions(-) > > diff --git a/drivers/scsi/qla2xxx/qla_target.c > b/drivers/scsi/qla2xxx/qla_target.c > index 47acc26..6e58848 100644 > --- a/drivers/scsi/qla2xxx/qla_target.c > +++ b/drivers/scsi/qla2xxx/qla_target.c > @@ -1592,8 +1592,9 @@ static int __qlt_24xx_handle_abts(struct scsi_qla_host > *vha, > mcmd->sess = sess; > memcpy(&mcmd->orig_iocb.abts, abts, sizeof(mcmd->orig_iocb.abts)); > mcmd->reset_count = vha->hw->chip_reset; > + mcmd->tmr_func = QLA_TGT_ABTS; > > - rc = ha->tgt.tgt_ops->handle_tmr(mcmd, lun, TMR_ABORT_TASK, > + rc = ha->tgt.tgt_ops->handle_tmr(mcmd, 0, mcmd->tmr_func, > abts->exchange_addr_to_abort); Does this change remove the last user of the 'lun' variable from this function? If so, please remove that variable entirely. Thanks, Bart. -- 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 11/11] qla2xxx: Improve RSCN handling in driver
On Fri, 2016-12-23 at 20:23 -0800, Himanshu Madhani wrote:
> +void qlt_unknown_atio_work_fn(struct delayed_work *work)
> +{
> + struct scsi_qla_host *vha = container_of(work, struct scsi_qla_host,
> + unknown_atio_work);
> + qlt_try_to_dequeue_unknown_atios(vha, 0);
> + return;
> +}
> +
> [ ... ]
> + INIT_DELAYED_WORK(&base_vha->unknown_atio_work,
> + (void (*)(struct work_struct *))qlt_unknown_atio_work_fn);
Hello Himanshu and Quinn,
Please follow the approach for delayed work that is followed elsewhere in
the kernel, namely:
* Use struct work_struct * for the argument type of delayed work functions.
* Do not use a function pointer cast in the INIT_DELAYED_WORK() macro.
This change will require to modify the container_of() expression. Here are
two examples from other kernel drivers:
hctx = container_of(work, struct blk_mq_hw_ctx, delay_work.work);
struct srp_rport *rport = container_of(to_delayed_work(work),
struct srp_rport, reconnect_work);
Thanks,
Bart.--
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 03/11] qla2xxx: Make trace flags more readable.
On 1/11/17, 12:47 PM, "Bart Van Assche" wrote: >On Fri, 2016-12-23 at 20:23 -0800, Himanshu Madhani wrote: >> From: Quinn Tran >> >> This patch does not change any functionality. > >Please also mention in the patch description what the purpose of cmd_flags >is. If I remember correctly the only purpose of most flags is to make >analyzing crash dumps easier? Yes. You are correct. I will add blurb about need for having trc_flags in the patch commit message > >Bart.
Re: [PATCH 02/11] qla2xxx: Cleanup TMF code translation from qla_target.
On 1/11/17, 12:05 PM, "Bart Van Assche" wrote:
>On 12/23/2016 08:23 PM, Himanshu Madhani wrote:
>> static int tcm_qla2xxx_handle_tmr(struct qla_tgt_mgmt_cmd *mcmd, uint32_t
>> lun,
>> -uint8_t tmr_func, uint32_t tag)
>> +uint16_t tmr_func, uint32_t tag)
>> {
>> struct qla_tgt_sess *sess = mcmd->sess;
>> struct se_cmd *se_cmd = &mcmd->se_cmd;
>> +int transl_tmr_func;
>> +
>> +switch (tmr_func) {
>> +case QLA_TGT_ABTS:
>> +pr_debug("%ld: ABTS received\n", sess->vha->host_no);
>> +transl_tmr_func = TMR_ABORT_TASK;
>> +break;
>> +case QLA_TGT_2G_ABORT_TASK:
>> +pr_debug("%ld: 2G Abort Task received\n", sess->vha->host_no);
>> +transl_tmr_func = TMR_ABORT_TASK;
>> +break;
>> +case QLA_TGT_CLEAR_ACA:
>> +pr_debug("%ld: CLEAR_ACA received\n", sess->vha->host_no);
>> +transl_tmr_func = TMR_CLEAR_ACA;
>> +break;
>> +case QLA_TGT_TARGET_RESET:
>> +pr_debug("%ld: TARGET_RESET received\n", sess->vha->host_no);
>> +transl_tmr_func = TMR_TARGET_WARM_RESET;
>> +break;
>> +case QLA_TGT_LUN_RESET:
>> +pr_debug("%ld: LUN_RESET received\n", sess->vha->host_no);
>> +transl_tmr_func = TMR_LUN_RESET;
>> +break;
>> +case QLA_TGT_CLEAR_TS:
>> +pr_debug("%ld: CLEAR_TS received\n", sess->vha->host_no);
>> +transl_tmr_func = TMR_CLEAR_TASK_SET;
>> +break;
>> +case QLA_TGT_ABORT_TS:
>> +pr_debug("%ld: ABORT_TS received\n", sess->vha->host_no);
>> +transl_tmr_func = TMR_ABORT_TASK_SET;
>> +break;
>> +default:
>> +pr_debug("%ld: Unknown task mgmt fn 0x%x\n",
>> +sess->vha->host_no, tmr_func);
>> +return -ENOSYS;
>> +break;
>> +}
>>
>> return target_submit_tmr(se_cmd, sess->se_sess, NULL, lun, mcmd,
>> tmr_func, GFP_ATOMIC, tag, TARGET_SCF_ACK_KREF);
>
>Hello Himanshu and Quinn,
>
>This patch introduces a new compiler warning when building with W=1,
>namely that transl_tmr_func is set but not used. Please review the code.
Sure. Will update patch.
>Thanks,
>
>Bart.
Re: [PATCH 03/11] qla2xxx: Make trace flags more readable.
On Fri, 2016-12-23 at 20:23 -0800, Himanshu Madhani wrote: > From: Quinn Tran > > This patch does not change any functionality. Please also mention in the patch description what the purpose of cmd_flags is. If I remember correctly the only purpose of most flags is to make analyzing crash dumps easier? Bart.-- 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] drivers: block: Remove unnecessary cast
On Wed, Jan 11, 2017 at 12:41:05PM -0600, Gustavo A. R. Silva wrote: > This issue was detected using Coccinelle and the following semantic patch: > > @@ > expression * e; > expression arg1, arg2; > type T; > @@ > > - e = (T *) > + e = > kmalloc(arg1, arg2); > > Signed-off-by: Gustavo A. R. Silva > --- > drivers/block/cciss_scsi.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) Why send this to me? -- 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 08/11] qla2xxx: Add framework for Async fabric discovery.
On 12/23/2016 08:23 PM, Himanshu Madhani wrote: > + sess->logout_completed = 0; > + be_sid[0] = sess->d_id.b.domain; > + be_sid[1] = sess->d_id.b.area; > + be_sid[2] = sess->d_id.b.al_pa; Hello Himanshu and Quinn, When building the qlt_create_sess() code with W=1 the compiler warns that values are assigned to the elements of the be_sid[] array but that these values are not used. Please review the code. Thanks, Bart. -- 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 09/11] qla2xxx: Add Dual mode support in the driver
On 12/23/2016 08:23 PM, Himanshu Madhani wrote: > -#define QLA_TGT_MODE_ENABLED() (ql2x_ini_mode != QLA2XXX_INI_MODE_ENABLED) > +#define QLA_TGT_MODE_ENABLED() \ > + ((ql2x_ini_mode != QLA2XXX_INI_MODE_ENABLED) || \ > + (ql2x_ini_mode == QLA2XXX_INI_MODE_DUAL)) Hello Himanshu and Quinn, Is this change needed? It looks redundant to me. For all possible ql2x_ini_mode values both the old and the new expression will yield the same value. Anyway, dual mode is a welcome improvement! Bart. -- 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 02/11] qla2xxx: Cleanup TMF code translation from qla_target.
On 12/23/2016 08:23 PM, Himanshu Madhani wrote:
> static int tcm_qla2xxx_handle_tmr(struct qla_tgt_mgmt_cmd *mcmd, uint32_t
> lun,
> - uint8_t tmr_func, uint32_t tag)
> + uint16_t tmr_func, uint32_t tag)
> {
> struct qla_tgt_sess *sess = mcmd->sess;
> struct se_cmd *se_cmd = &mcmd->se_cmd;
> + int transl_tmr_func;
> +
> + switch (tmr_func) {
> + case QLA_TGT_ABTS:
> + pr_debug("%ld: ABTS received\n", sess->vha->host_no);
> + transl_tmr_func = TMR_ABORT_TASK;
> + break;
> + case QLA_TGT_2G_ABORT_TASK:
> + pr_debug("%ld: 2G Abort Task received\n", sess->vha->host_no);
> + transl_tmr_func = TMR_ABORT_TASK;
> + break;
> + case QLA_TGT_CLEAR_ACA:
> + pr_debug("%ld: CLEAR_ACA received\n", sess->vha->host_no);
> + transl_tmr_func = TMR_CLEAR_ACA;
> + break;
> + case QLA_TGT_TARGET_RESET:
> + pr_debug("%ld: TARGET_RESET received\n", sess->vha->host_no);
> + transl_tmr_func = TMR_TARGET_WARM_RESET;
> + break;
> + case QLA_TGT_LUN_RESET:
> + pr_debug("%ld: LUN_RESET received\n", sess->vha->host_no);
> + transl_tmr_func = TMR_LUN_RESET;
> + break;
> + case QLA_TGT_CLEAR_TS:
> + pr_debug("%ld: CLEAR_TS received\n", sess->vha->host_no);
> + transl_tmr_func = TMR_CLEAR_TASK_SET;
> + break;
> + case QLA_TGT_ABORT_TS:
> + pr_debug("%ld: ABORT_TS received\n", sess->vha->host_no);
> + transl_tmr_func = TMR_ABORT_TASK_SET;
> + break;
> + default:
> + pr_debug("%ld: Unknown task mgmt fn 0x%x\n",
> + sess->vha->host_no, tmr_func);
> + return -ENOSYS;
> + break;
> + }
>
> return target_submit_tmr(se_cmd, sess->se_sess, NULL, lun, mcmd,
> tmr_func, GFP_ATOMIC, tag, TARGET_SCF_ACK_KREF);
Hello Himanshu and Quinn,
This patch introduces a new compiler warning when building with W=1,
namely that transl_tmr_func is set but not used. Please review the code.
Thanks,
Bart.
--
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] lpfc: avoid double free of resource identifiers
looks good. Thanks Signed-off-by: James Smart -- james On 1/11/2017 2:06 AM, Johannes Thumshirn wrote: From: Roberto Sassu Set variables initialized in lpfc_sli4_alloc_resource_identifiers() to NULL if an error occurred. Otherwise, lpfc_sli4_driver_resource_unset() attempts to free the memory again. Signed-off-by: Roberto Sassu Signed-off-by: Johannes Thumshirn --- drivers/scsi/lpfc/lpfc_sli.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c index 4faa767..a78a3df 100644 --- a/drivers/scsi/lpfc/lpfc_sli.c +++ b/drivers/scsi/lpfc/lpfc_sli.c @@ -5954,18 +5954,25 @@ lpfc_sli4_alloc_resource_identifiers(struct lpfc_hba *phba) free_vfi_bmask: kfree(phba->sli4_hba.vfi_bmask); + phba->sli4_hba.vfi_bmask = NULL; free_xri_ids: kfree(phba->sli4_hba.xri_ids); + phba->sli4_hba.xri_ids = NULL; free_xri_bmask: kfree(phba->sli4_hba.xri_bmask); + phba->sli4_hba.xri_bmask = NULL; free_vpi_ids: kfree(phba->vpi_ids); + phba->vpi_ids = NULL; free_vpi_bmask: kfree(phba->vpi_bmask); + phba->vpi_bmask = NULL; free_rpi_ids: kfree(phba->sli4_hba.rpi_ids); + phba->sli4_hba.rpi_ids = NULL; free_rpi_bmask: kfree(phba->sli4_hba.rpi_bmask); + phba->sli4_hba.rpi_bmask = NULL; err_exit: return rc; } -- 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] ibmvscsis: Fix max transfer length
Current code incorrectly calculates the max transfer length, since it is assuming a 4k page table, but ppc64 all run on 64k page tables. Cc: sta...@vger.kernel.org Reported-by: Steven Royer Tested-by: Steven Royer Signed-off-by: Bryant G. Ly --- drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c index 8fb5c54..9c91e75 100644 --- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c +++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c @@ -46,6 +46,7 @@ #defineINITIAL_SRP_LIMIT 800 #defineDEFAULT_MAX_SECTORS 256 +#define MAX_TXU1024 * 1024 static uint max_vdma_size = MAX_H_COPY_RDMA; @@ -1443,7 +1444,7 @@ static long ibmvscsis_adapter_info(struct scsi_info *vscsi, info->mad_version = cpu_to_be32(MAD_VERSION_1); info->os_type = cpu_to_be32(LINUX); memset(&info->port_max_txu[0], 0, sizeof(info->port_max_txu)); - info->port_max_txu[0] = cpu_to_be32(128 * PAGE_SIZE); + info->port_max_txu[0] = cpu_to_be32(MAX_TXU); dma_wmb(); rc = h_copy_rdma(sizeof(*info), vscsi->dds.window[LOCAL].liobn, -- 2.5.4 (Apple Git-61) -- 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] ibmvscsis: Fix max transfer length
Current code incorrectly calculates the max transfer length, since it is assuming a 4k page table, but ppc64 all run on 64k page tables. Cc: sta...@vger.kernel.org Reported-by: Steven Royer Tested-by: Steven Royer Signed-off-by: Bryant G. Ly --- drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c index 8fb5c54..3b4d36b 100644 --- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c +++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c @@ -46,6 +46,7 @@ #defineINITIAL_SRP_LIMIT 800 #defineDEFAULT_MAX_SECTORS 256 +#define MAX_TXU1024 static uint max_vdma_size = MAX_H_COPY_RDMA; @@ -1443,7 +1444,7 @@ static long ibmvscsis_adapter_info(struct scsi_info *vscsi, info->mad_version = cpu_to_be32(MAD_VERSION_1); info->os_type = cpu_to_be32(LINUX); memset(&info->port_max_txu[0], 0, sizeof(info->port_max_txu)); - info->port_max_txu[0] = cpu_to_be32(128 * PAGE_SIZE); + info->port_max_txu[0] = cpu_to_be32(MAX_TXU); dma_wmb(); rc = h_copy_rdma(sizeof(*info), vscsi->dds.window[LOCAL].liobn, -- 2.5.4 (Apple Git-61) -- 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] preview - block layer help to detect sequential IO
Hi Kashyap,
[auto build test ERROR on v4.9-rc8]
[cannot apply to block/for-next linus/master linux/master next-20170111]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Kashyap-Desai/preview-block-layer-help-to-detect-sequential-IO/20170112-024228
config: i386-randconfig-a0-201702 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
block/blk-core.c: In function 'add_sequential':
>> block/blk-core.c:1899:16: error: 'struct task_struct' has no member named
>> 'sequential_io_avg'
blk_ewma_add(t->sequential_io_avg,
^
block/blk-core.c:1893:10: note: in definition of macro 'blk_ewma_add'
(ewma) *= (weight) - 1; \
^~~~
>> block/blk-core.c:1899:16: error: 'struct task_struct' has no member named
>> 'sequential_io_avg'
blk_ewma_add(t->sequential_io_avg,
^
block/blk-core.c:1894:10: note: in definition of macro 'blk_ewma_add'
(ewma) += (val) << factor; \
^~~~
>> block/blk-core.c:1900:5: error: 'struct task_struct' has no member named
>> 'sequential_io'
t->sequential_io, 8, 0);
^
block/blk-core.c:1894:20: note: in definition of macro 'blk_ewma_add'
(ewma) += (val) << factor; \
^~~
>> block/blk-core.c:1899:16: error: 'struct task_struct' has no member named
>> 'sequential_io_avg'
blk_ewma_add(t->sequential_io_avg,
^
block/blk-core.c:1895:10: note: in definition of macro 'blk_ewma_add'
(ewma) /= (weight); \
^~~~
>> block/blk-core.c:1899:16: error: 'struct task_struct' has no member named
>> 'sequential_io_avg'
blk_ewma_add(t->sequential_io_avg,
^
block/blk-core.c:1896:10: note: in definition of macro 'blk_ewma_add'
(ewma) >> factor; \
^~~~
block/blk-core.c:1902:3: error: 'struct task_struct' has no member named
'sequential_io'
t->sequential_io = 0;
^~
block/blk-core.c: In function 'generic_make_request_checks':
block/blk-core.c:2012:7: error: 'struct task_struct' has no member named
'sequential_io'
task->sequential_io = i->sequential;
^~
In file included from block/blk-core.c:14:0:
block/blk-core.c:2020:21: error: 'struct task_struct' has no member named
'sequential_io'
sectors = max(task->sequential_io,
^
include/linux/kernel.h:747:2: note: in definition of macro '__max'
t1 max1 = (x); \
^~
block/blk-core.c:2020:13: note: in expansion of macro 'max'
sectors = max(task->sequential_io,
^~~
block/blk-core.c:2020:21: error: 'struct task_struct' has no member named
'sequential_io'
sectors = max(task->sequential_io,
^
include/linux/kernel.h:747:13: note: in definition of macro '__max'
t1 max1 = (x); \
^
block/blk-core.c:2020:13: note: in expansion of macro 'max'
sectors = max(task->sequential_io,
^~~
block/blk-core.c:2021:14: error: 'struct task_struct' has no member named
'sequential_io_avg'
task->sequential_io_avg) >> 9;
^
include/linux/kernel.h:748:2: note: in definition of macro '__max'
t2 max2 = (y); \
^~
block/blk-core.c:2020:13: note: in expansion of macro 'max'
sectors = max(task->sequential_io,
^~~
block/blk-core.c:2021:14: error: 'struct task_struct' has no member named
'sequential_io_avg'
task->sequential_io_avg) >> 9;
^
include/linux/kernel.h:748:13: note: in definition of macro '__max'
t2 max2 = (y); \
^
block/blk-core.c:2020:13: note: in expansion of macro 'max'
sectors = max(task->sequential_io,
^~~
vim +1899 block/blk-core.c
1887 }
1888
1889 static void add_sequential(struct task_struct *t)
1890 {
1891 #define blk_ewma_add(ewma, val, weight, factor)
\
1892 ({
Re: [PATCH 2/2] qla2xxx: remove irq_affinity_notifier
On 1/11/17, 8:55 AM, "Christoph Hellwig" wrote:
>Now that qla2xxx uses the IRQ layer affinity assignment affinity
>won't change over the life time of a device and the notifiers are
>useless.
>
>Signed-off-by: Christoph Hellwig
>---
> drivers/scsi/qla2xxx/qla_def.h | 1 -
> drivers/scsi/qla2xxx/qla_isr.c | 73 --
> 2 files changed, 74 deletions(-)
>
>diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
>index e5e0301..8c2e60a 100644
>--- a/drivers/scsi/qla2xxx/qla_def.h
>+++ b/drivers/scsi/qla2xxx/qla_def.h
>@@ -2754,7 +2754,6 @@ struct qla_msix_entry {
> uint16_t entry;
> char name[30];
> void *handle;
>- struct irq_affinity_notify irq_notify;
> int cpuid;
> };
>
>diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
>index 5f389a3..ca0b7dc 100644
>--- a/drivers/scsi/qla2xxx/qla_isr.c
>+++ b/drivers/scsi/qla2xxx/qla_isr.c
>@@ -19,10 +19,6 @@ static void qla2x00_status_entry(scsi_qla_host_t *, struct
>rsp_que *, void *);
> static void qla2x00_status_cont_entry(struct rsp_que *, sts_cont_entry_t *);
> static void qla2x00_error_entry(scsi_qla_host_t *, struct rsp_que *,
> sts_entry_t *);
>-static void qla_irq_affinity_notify(struct irq_affinity_notify *,
>-const cpumask_t *);
>-static void qla_irq_affinity_release(struct kref *);
>-
>
> /**
> * qla2100_intr_handler() - Process interrupts for the ISP2100 and ISP2200.
>@@ -2572,14 +2568,6 @@ void qla24xx_process_response_queue(struct
>scsi_qla_host *vha,
> if (!vha->flags.online)
> return;
>
>- if (rsp->msix && rsp->msix->cpuid != smp_processor_id()) {
>- /* if kernel does not notify qla of IRQ's CPU change,
>- * then set it here.
>- */
>- rsp->msix->cpuid = smp_processor_id();
>- ha->tgt.rspq_vector_cpuid = rsp->msix->cpuid;
>- }
>-
> while (rsp->ring_ptr->signature != RESPONSE_PROCESSED) {
> pkt = (struct sts_entry_24xx *)rsp->ring_ptr;
>
>@@ -3076,9 +3064,6 @@ qla24xx_enable_msix(struct qla_hw_data *ha, struct
>rsp_que *rsp)
> qentry->have_irq = 0;
> qentry->in_use = 0;
> qentry->handle = NULL;
>- qentry->irq_notify.notify = qla_irq_affinity_notify;
>- qentry->irq_notify.release = qla_irq_affinity_release;
>- qentry->cpuid = -1;
> }
>
> /* Enable MSI-X vectors for the base queue */
>@@ -3100,18 +3085,6 @@ qla24xx_enable_msix(struct qla_hw_data *ha, struct
>rsp_que *rsp)
> goto msix_register_fail;
> qentry->have_irq = 1;
> qentry->in_use = 1;
>-
>- /* Register for CPU affinity notification. */
>- irq_set_affinity_notifier(qentry->vector, &qentry->irq_notify);
>-
>- /* Schedule work (ie. trigger a notification) to read cpu
>- * mask for this specific irq.
>- * kref_get is required because
>- * irq_affinity_notify() will do
>- * kref_put().
>- */
>- kref_get(&qentry->irq_notify.kref);
>- schedule_work(&qentry->irq_notify.work);
> }
>
> /*
>@@ -3308,49 +3281,3 @@ int qla25xx_request_irq(struct qla_hw_data *ha, struct
>qla_qpair *qpair,
> msix->handle = qpair;
> return ret;
> }
>-
>-
>-/* irq_set_affinity/irqbalance will trigger notification of cpu mask update */
>-static void qla_irq_affinity_notify(struct irq_affinity_notify *notify,
>- const cpumask_t *mask)
>-{
>- struct qla_msix_entry *e =
>- container_of(notify, struct qla_msix_entry, irq_notify);
>- struct qla_hw_data *ha;
>- struct scsi_qla_host *base_vha;
>- struct rsp_que *rsp = e->handle;
>-
>- /* user is recommended to set mask to just 1 cpu */
>- e->cpuid = cpumask_first(mask);
>-
>- ha = rsp->hw;
>- base_vha = pci_get_drvdata(ha->pdev);
>-
>- ql_dbg(ql_dbg_init, base_vha, 0x,
>- "%s: host %ld : vector %d cpu %d \n", __func__,
>- base_vha->host_no, e->vector, e->cpuid);
>-
>- if (e->have_irq) {
>- if ((IS_QLA83XX(ha) || IS_QLA27XX(ha)) &&
>- (e->entry == QLA83XX_RSPQ_MSIX_ENTRY_NUMBER)) {
>- ha->tgt.rspq_vector_cpuid = e->cpuid;
>- ql_dbg(ql_dbg_init, base_vha, 0x,
>- "%s: host%ld: rspq vector %d cpu %d runtime
>change\n",
>- __func__, base_vha->host_no, e->vector, e->cpuid);
>- }
>- }
>-}
>-
>-static void qla_irq_affinity_release(struct kref *ref)
>-{
>- struct irq_affinity_notify *notify =
>- container_of(ref, struct irq_affinity_notify, kref);
>- struct qla_msix_entry *e =
>- container_of(notify, struct qla_msix_entry, irq_notify);
>- struct rsp_que *rsp = e->handle;
>- str
Re: [PATCH 1/2] qla2xxx: fix MSI-X vector affinity
On 1/11/17, 8:55 AM, "Christoph Hellwig" wrote:
>The first two or three vectors in qla2xxx adapter are global and
>not associated with a specific queue. They should not have IRQ
>affinity assigned.
>
>Signed-off-by: Christoph Hellwig
>---
> drivers/scsi/qla2xxx/qla_def.h | 2 +-
> drivers/scsi/qla2xxx/qla_isr.c | 15 +++
> 2 files changed, 12 insertions(+), 5 deletions(-)
>
>diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
>index ef699b6..e5e0301 100644
>--- a/drivers/scsi/qla2xxx/qla_def.h
>+++ b/drivers/scsi/qla2xxx/qla_def.h
>@@ -2732,7 +2732,7 @@ struct isp_operations {
> #define QLA_MSIX_FW_MODE(m) (((m) & (BIT_7|BIT_8|BIT_9)) >> 7)
> #define QLA_MSIX_FW_MODE_1(m) (QLA_MSIX_FW_MODE(m) == 1)
>
>-#define QLA_MSIX_DEFAULT 0x00
>+#define QLA_BASE_VECTORS 2 /* default + RSP */
> #define QLA_MSIX_RSP_Q0x01
> #define QLA_ATIO_VECTOR 0x02
> #define QLA_MSIX_QPAIR_MULTIQ_RSP_Q 0x03
>diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
>index b9c113e..5f389a3 100644
>--- a/drivers/scsi/qla2xxx/qla_isr.c
>+++ b/drivers/scsi/qla2xxx/qla_isr.c
>@@ -3018,13 +3018,20 @@ static const struct qla_init_msix_entry
>qla82xx_msix_entries[] = {
> static int
> qla24xx_enable_msix(struct qla_hw_data *ha, struct rsp_que *rsp)
> {
>-#define MIN_MSIX_COUNT2
> int i, ret;
> struct qla_msix_entry *qentry;
> scsi_qla_host_t *vha = pci_get_drvdata(ha->pdev);
>+ struct irq_affinity desc = {
>+ .pre_vectors = QLA_BASE_VECTORS,
>+ };
>+
>+ if (QLA_TGT_MODE_ENABLED() && IS_ATIO_MSIX_CAPABLE(ha))
>+ desc.pre_vectors++;
>+
>+ ret = pci_alloc_irq_vectors_affinity(ha->pdev, QLA_BASE_VECTORS,
>+ ha->msix_count, PCI_IRQ_MSIX | PCI_IRQ_AFFINITY,
>+ &desc);
>
>- ret = pci_alloc_irq_vectors(ha->pdev, MIN_MSIX_COUNT, ha->msix_count,
>- PCI_IRQ_MSIX | PCI_IRQ_AFFINITY);
> if (ret < 0) {
> ql_log(ql_log_fatal, vha, 0x00c7,
> "MSI-X: Failed to enable support, "
>@@ -3075,7 +3082,7 @@ qla24xx_enable_msix(struct qla_hw_data *ha, struct
>rsp_que *rsp)
> }
>
> /* Enable MSI-X vectors for the base queue */
>- for (i = 0; i < (QLA_MSIX_RSP_Q + 1); i++) {
>+ for (i = 0; i < QLA_BASE_VECTORS; i++) {
> qentry = &ha->msix_entries[i];
> qentry->handle = rsp;
> rsp->msix = qentry;
>--
>2.1.4
>
Thanks for cleanup. Looks Good.
Acked-by: Himanshu Madhani
>
[PATCH] ibmvscsis: Fix max transfer length
Current code incorrectly calculates the max transfer length, since it is assuming a 4k page table, but ppc64 all run on 64k page tables. Cc: sta...@vger.kernel.org Reported-by: Steven Royer Tested-by: Steven Royer Signed-off-by: Bryant G. Ly --- drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c index 8fb5c54..3b4d36b 100644 --- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c +++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c @@ -46,6 +46,7 @@ #defineINITIAL_SRP_LIMIT 800 #defineDEFAULT_MAX_SECTORS 256 +#define MAX_TXU1024 static uint max_vdma_size = MAX_H_COPY_RDMA; @@ -1443,7 +1444,7 @@ static long ibmvscsis_adapter_info(struct scsi_info *vscsi, info->mad_version = cpu_to_be32(MAD_VERSION_1); info->os_type = cpu_to_be32(LINUX); memset(&info->port_max_txu[0], 0, sizeof(info->port_max_txu)); - info->port_max_txu[0] = cpu_to_be32(128 * PAGE_SIZE); + info->port_max_txu[0] = cpu_to_be32(MAX_TXU); dma_wmb(); rc = h_copy_rdma(sizeof(*info), vscsi->dds.window[LOCAL].liobn, -- 2.5.4 (Apple Git-61) -- 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] ibmvscsis: Fix max transfer length
On 1/11/17 12:57 PM, Bart Van Assche wrote: On Wed, 2017-01-11 at 12:02 -0600, Bryant G. Ly wrote: Current code incorrectly calculates the max transfer length, since it is assuming a 4k page table, but ppc64 all run on 64k page tables. Cc: sta...@vger.kernel.org Reported-by: Steven Royer Tested-by: Steven Royer Signed-off-by: Bryant G. Ly --- drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c index 8fb5c54..792a8bd 100644 --- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c +++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c @@ -1443,7 +1443,7 @@ static long ibmvscsis_adapter_info(struct scsi_info *vscsi, info->mad_version = cpu_to_be32(MAD_VERSION_1); info->os_type = cpu_to_be32(LINUX); memset(&info->port_max_txu[0], 0, sizeof(info->port_max_txu)); - info->port_max_txu[0] = cpu_to_be32(128 * PAGE_SIZE); + info->port_max_txu[0] = cpu_to_be32(16 * PAGE_SIZE); dma_wmb(); rc = h_copy_rdma(sizeof(*info), vscsi->dds.window[LOCAL].liobn, Hello Bryant, The old limit was intended to be 128 * 4 KB = 512 KB. The new limit is 16 * 64 KB = 1024 KB. Is that intended? Do I understand correctly that the max_txu value is independent of the page size? If so, have you considered to introduce a #define for the max_mtu value that specifies max_mtu as a number instead of as a multiple of the page size? At least in the SLES 10 SP3 ibmvscsis.c code max_mtu was not defined as a multiple of the page size. Hi Bart, Thanks for the review. You are correct, max_txu is independent of the page size. A define is probably best. The reason for this is people who are using tcmu-runner, they have a max transfer length of 1024KB, so if you exceed this value, then commands will fail. Thus to prevent people from experiencing this issue, we are going to limit our driver to that cap. The "allowed values" from a typical AIX disk can go all the way up to 16MB. Typically the max values do default at 512KB though. -Bryant. -- 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] ibmvscsis: fix sleeping in interrupt context
Currently, dma_alloc_coherent is being called with a GFP_KERNEL
flag which allows it to sleep in an interrupt context, need to
change to GFP_ATOMIC.
Cc: sta...@vger.kernel.org
Tested-by: Steven Royer
Reviewed-by: Michael Cyr
Signed-off-by: Bryant G. Ly
---
drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
index 792a8bd..8e308fd 100644
--- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
+++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
@@ -1391,7 +1391,7 @@ static long ibmvscsis_adapter_info(struct scsi_info
*vscsi,
}
info = dma_alloc_coherent(&vscsi->dma_dev->dev, sizeof(*info), &token,
- GFP_KERNEL);
+ GFP_ATOMIC);
if (!info) {
dev_err(&vscsi->dev, "bad dma_alloc_coherent %p\n",
iue->target);
@@ -1509,7 +1509,7 @@ static int ibmvscsis_cap_mad(struct scsi_info *vscsi,
struct iu_entry *iue)
}
cap = dma_alloc_coherent(&vscsi->dma_dev->dev, olen, &token,
-GFP_KERNEL);
+GFP_ATOMIC);
if (!cap) {
dev_err(&vscsi->dev, "bad dma_alloc_coherent %p\n",
iue->target);
--
2.5.4 (Apple Git-61)
--
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] ibmvscsis: Fix max transfer length
On Wed, 2017-01-11 at 12:02 -0600, Bryant G. Ly wrote: > Current code incorrectly calculates the max transfer length, since > it is assuming a 4k page table, but ppc64 all run on 64k page tables. > > Cc: sta...@vger.kernel.org > Reported-by: Steven Royer > Tested-by: Steven Royer > Signed-off-by: Bryant G. Ly > --- > drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c > b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c > index 8fb5c54..792a8bd 100644 > --- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c > +++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c > @@ -1443,7 +1443,7 @@ static long ibmvscsis_adapter_info(struct scsi_info > *vscsi, > info->mad_version = cpu_to_be32(MAD_VERSION_1); > info->os_type = cpu_to_be32(LINUX); > memset(&info->port_max_txu[0], 0, sizeof(info->port_max_txu)); > - info->port_max_txu[0] = cpu_to_be32(128 * PAGE_SIZE); > + info->port_max_txu[0] = cpu_to_be32(16 * PAGE_SIZE); > > dma_wmb(); > rc = h_copy_rdma(sizeof(*info), vscsi->dds.window[LOCAL].liobn, Hello Bryant, The old limit was intended to be 128 * 4 KB = 512 KB. The new limit is 16 * 64 KB = 1024 KB. Is that intended? Do I understand correctly that the max_txu value is independent of the page size? If so, have you considered to introduce a #define for the max_mtu value that specifies max_mtu as a number instead of as a multiple of the page size? At least in the SLES 10 SP3 ibmvscsis.c code max_mtu was not defined as a multiple of the page size. Thanks, Bart.-- 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] drivers: block: Remove unnecessary cast
This issue was detected using Coccinelle and the following semantic patch: @@ expression * e; expression arg1, arg2; type T; @@ - e = (T *) + e = kmalloc(arg1, arg2); Signed-off-by: Gustavo A. R. Silva --- drivers/block/cciss_scsi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/block/cciss_scsi.c b/drivers/block/cciss_scsi.c index a18de9d..98ba8fc 100644 --- a/drivers/block/cciss_scsi.c +++ b/drivers/block/cciss_scsi.c @@ -647,8 +647,7 @@ cciss_scsi_setup(ctlr_info_t *h) struct cciss_scsi_adapter_data_t * shba; ccissscsi[h->ctlr].ndevices = 0; - shba = (struct cciss_scsi_adapter_data_t *) - kmalloc(sizeof(*shba), GFP_KERNEL); + shba = kmalloc(sizeof(*shba), GFP_KERNEL); if (shba == NULL) return; shba->scsi_host = NULL; -- 2.5.0 -- 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] ibmvscsis: Fix max transfer length
Current code incorrectly calculates the max transfer length, since it is assuming a 4k page table, but ppc64 all run on 64k page tables. Cc: sta...@vger.kernel.org Reported-by: Steven Royer Tested-by: Steven Royer Signed-off-by: Bryant G. Ly --- drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c index 8fb5c54..792a8bd 100644 --- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c +++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c @@ -1443,7 +1443,7 @@ static long ibmvscsis_adapter_info(struct scsi_info *vscsi, info->mad_version = cpu_to_be32(MAD_VERSION_1); info->os_type = cpu_to_be32(LINUX); memset(&info->port_max_txu[0], 0, sizeof(info->port_max_txu)); - info->port_max_txu[0] = cpu_to_be32(128 * PAGE_SIZE); + info->port_max_txu[0] = cpu_to_be32(16 * PAGE_SIZE); dma_wmb(); rc = h_copy_rdma(sizeof(*info), vscsi->dds.window[LOCAL].liobn, -- 2.5.4 (Apple Git-61) -- 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
two fixes for the qla2xxx MSI-X changes in 4.10-rc
Hi Himanshu, two small updates to to a) fix the way affinity is assigned for qla2xxx, and b) remove the dead interrupt affinity notifiers. -- 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] qla2xxx: fix MSI-X vector affinity
The first two or three vectors in qla2xxx adapter are global and
not associated with a specific queue. They should not have IRQ
affinity assigned.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/qla2xxx/qla_def.h | 2 +-
drivers/scsi/qla2xxx/qla_isr.c | 15 +++
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
index ef699b6..e5e0301 100644
--- a/drivers/scsi/qla2xxx/qla_def.h
+++ b/drivers/scsi/qla2xxx/qla_def.h
@@ -2732,7 +2732,7 @@ struct isp_operations {
#define QLA_MSIX_FW_MODE(m)(((m) & (BIT_7|BIT_8|BIT_9)) >> 7)
#define QLA_MSIX_FW_MODE_1(m) (QLA_MSIX_FW_MODE(m) == 1)
-#define QLA_MSIX_DEFAULT 0x00
+#define QLA_BASE_VECTORS 2 /* default + RSP */
#define QLA_MSIX_RSP_Q 0x01
#define QLA_ATIO_VECTOR0x02
#define QLA_MSIX_QPAIR_MULTIQ_RSP_Q0x03
diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
index b9c113e..5f389a3 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -3018,13 +3018,20 @@ static const struct qla_init_msix_entry
qla82xx_msix_entries[] = {
static int
qla24xx_enable_msix(struct qla_hw_data *ha, struct rsp_que *rsp)
{
-#define MIN_MSIX_COUNT 2
int i, ret;
struct qla_msix_entry *qentry;
scsi_qla_host_t *vha = pci_get_drvdata(ha->pdev);
+ struct irq_affinity desc = {
+ .pre_vectors = QLA_BASE_VECTORS,
+ };
+
+ if (QLA_TGT_MODE_ENABLED() && IS_ATIO_MSIX_CAPABLE(ha))
+ desc.pre_vectors++;
+
+ ret = pci_alloc_irq_vectors_affinity(ha->pdev, QLA_BASE_VECTORS,
+ ha->msix_count, PCI_IRQ_MSIX | PCI_IRQ_AFFINITY,
+ &desc);
- ret = pci_alloc_irq_vectors(ha->pdev, MIN_MSIX_COUNT, ha->msix_count,
- PCI_IRQ_MSIX | PCI_IRQ_AFFINITY);
if (ret < 0) {
ql_log(ql_log_fatal, vha, 0x00c7,
"MSI-X: Failed to enable support, "
@@ -3075,7 +3082,7 @@ qla24xx_enable_msix(struct qla_hw_data *ha, struct
rsp_que *rsp)
}
/* Enable MSI-X vectors for the base queue */
- for (i = 0; i < (QLA_MSIX_RSP_Q + 1); i++) {
+ for (i = 0; i < QLA_BASE_VECTORS; i++) {
qentry = &ha->msix_entries[i];
qentry->handle = rsp;
rsp->msix = qentry;
--
2.1.4
--
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] qla2xxx: remove irq_affinity_notifier
Now that qla2xxx uses the IRQ layer affinity assignment affinity
won't change over the life time of a device and the notifiers are
useless.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/qla2xxx/qla_def.h | 1 -
drivers/scsi/qla2xxx/qla_isr.c | 73 --
2 files changed, 74 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
index e5e0301..8c2e60a 100644
--- a/drivers/scsi/qla2xxx/qla_def.h
+++ b/drivers/scsi/qla2xxx/qla_def.h
@@ -2754,7 +2754,6 @@ struct qla_msix_entry {
uint16_t entry;
char name[30];
void *handle;
- struct irq_affinity_notify irq_notify;
int cpuid;
};
diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
index 5f389a3..ca0b7dc 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -19,10 +19,6 @@ static void qla2x00_status_entry(scsi_qla_host_t *, struct
rsp_que *, void *);
static void qla2x00_status_cont_entry(struct rsp_que *, sts_cont_entry_t *);
static void qla2x00_error_entry(scsi_qla_host_t *, struct rsp_que *,
sts_entry_t *);
-static void qla_irq_affinity_notify(struct irq_affinity_notify *,
-const cpumask_t *);
-static void qla_irq_affinity_release(struct kref *);
-
/**
* qla2100_intr_handler() - Process interrupts for the ISP2100 and ISP2200.
@@ -2572,14 +2568,6 @@ void qla24xx_process_response_queue(struct scsi_qla_host
*vha,
if (!vha->flags.online)
return;
- if (rsp->msix && rsp->msix->cpuid != smp_processor_id()) {
- /* if kernel does not notify qla of IRQ's CPU change,
-* then set it here.
-*/
- rsp->msix->cpuid = smp_processor_id();
- ha->tgt.rspq_vector_cpuid = rsp->msix->cpuid;
- }
-
while (rsp->ring_ptr->signature != RESPONSE_PROCESSED) {
pkt = (struct sts_entry_24xx *)rsp->ring_ptr;
@@ -3076,9 +3064,6 @@ qla24xx_enable_msix(struct qla_hw_data *ha, struct
rsp_que *rsp)
qentry->have_irq = 0;
qentry->in_use = 0;
qentry->handle = NULL;
- qentry->irq_notify.notify = qla_irq_affinity_notify;
- qentry->irq_notify.release = qla_irq_affinity_release;
- qentry->cpuid = -1;
}
/* Enable MSI-X vectors for the base queue */
@@ -3100,18 +3085,6 @@ qla24xx_enable_msix(struct qla_hw_data *ha, struct
rsp_que *rsp)
goto msix_register_fail;
qentry->have_irq = 1;
qentry->in_use = 1;
-
- /* Register for CPU affinity notification. */
- irq_set_affinity_notifier(qentry->vector, &qentry->irq_notify);
-
- /* Schedule work (ie. trigger a notification) to read cpu
-* mask for this specific irq.
-* kref_get is required because
- * irq_affinity_notify() will do
- * kref_put().
- */
- kref_get(&qentry->irq_notify.kref);
- schedule_work(&qentry->irq_notify.work);
}
/*
@@ -3308,49 +3281,3 @@ int qla25xx_request_irq(struct qla_hw_data *ha, struct
qla_qpair *qpair,
msix->handle = qpair;
return ret;
}
-
-
-/* irq_set_affinity/irqbalance will trigger notification of cpu mask update */
-static void qla_irq_affinity_notify(struct irq_affinity_notify *notify,
- const cpumask_t *mask)
-{
- struct qla_msix_entry *e =
- container_of(notify, struct qla_msix_entry, irq_notify);
- struct qla_hw_data *ha;
- struct scsi_qla_host *base_vha;
- struct rsp_que *rsp = e->handle;
-
- /* user is recommended to set mask to just 1 cpu */
- e->cpuid = cpumask_first(mask);
-
- ha = rsp->hw;
- base_vha = pci_get_drvdata(ha->pdev);
-
- ql_dbg(ql_dbg_init, base_vha, 0x,
- "%s: host %ld : vector %d cpu %d \n", __func__,
- base_vha->host_no, e->vector, e->cpuid);
-
- if (e->have_irq) {
- if ((IS_QLA83XX(ha) || IS_QLA27XX(ha)) &&
- (e->entry == QLA83XX_RSPQ_MSIX_ENTRY_NUMBER)) {
- ha->tgt.rspq_vector_cpuid = e->cpuid;
- ql_dbg(ql_dbg_init, base_vha, 0x,
- "%s: host%ld: rspq vector %d cpu %d runtime
change\n",
- __func__, base_vha->host_no, e->vector, e->cpuid);
- }
- }
-}
-
-static void qla_irq_affinity_release(struct kref *ref)
-{
- struct irq_affinity_notify *notify =
- container_of(ref, struct irq_affinity_notify, kref);
- struct qla_msix_entry *e =
- container_of(notify, struct qla_msix_entry, irq_notify);
- struct rsp_que *rsp = e->handle;
- struct scsi_qla_host *base_vha = pci_get_drvdata(rsp->hw->pdev);
-
- ql_dbg(ql_dbg_init, base_vha, 0x,
-
Re: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
On 01/11/2017 05:26 PM, Bart Van Assche wrote: > On Wed, 2017-01-11 at 17:22 +0100, Hannes Reinecke wrote: >> On 01/11/2017 05:12 PM, h...@infradead.org wrote: >>> On Wed, Jan 11, 2017 at 04:08:31PM +, Bart Van Assche wrote: A typical Ethernet network adapter delays the generation of an interrupt after it has received a packet. A typical block device or HBA does not delay the generation of an interrupt that reports an I/O completion. >>> >>> NVMe allows for configurable interrupt coalescing, as do a few modern >>> SCSI HBAs. >> >> Essentially every modern SCSI HBA does interrupt coalescing; otherwise >> the queuing interface won't work efficiently. > > Hello Hannes, > > The first e-mail in this e-mail thread referred to measurements against a > block device for which interrupt coalescing was not enabled. I think that > the measurements have to be repeated against a block device for which > interrupt coalescing is enabled. > Guess what we'll be doing in the next few days ... 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: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
On Wed, 2017-01-11 at 17:22 +0100, Hannes Reinecke wrote: > On 01/11/2017 05:12 PM, h...@infradead.org wrote: > > On Wed, Jan 11, 2017 at 04:08:31PM +, Bart Van Assche wrote: > > > A typical Ethernet network adapter delays the generation of an > > > interrupt > > > after it has received a packet. A typical block device or HBA does not > > > delay > > > the generation of an interrupt that reports an I/O completion. > > > > NVMe allows for configurable interrupt coalescing, as do a few modern > > SCSI HBAs. > > Essentially every modern SCSI HBA does interrupt coalescing; otherwise > the queuing interface won't work efficiently. Hello Hannes, The first e-mail in this e-mail thread referred to measurements against a block device for which interrupt coalescing was not enabled. I think that the measurements have to be repeated against a block device for which interrupt coalescing is enabled. Bart.-- 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: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
On 01/11/2017 05:12 PM, h...@infradead.org wrote: > On Wed, Jan 11, 2017 at 04:08:31PM +, Bart Van Assche wrote: >> A typical Ethernet network adapter delays the generation of an interrupt >> after it has received a packet. A typical block device or HBA does not delay >> the generation of an interrupt that reports an I/O completion. > > NVMe allows for configurable interrupt coalescing, as do a few modern > SCSI HBAs. Essentially every modern SCSI HBA does interrupt coalescing; otherwise the queuing interface won't work efficiently. Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (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: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
On 01/11/2017 09:12 AM, h...@infradead.org wrote: > On Wed, Jan 11, 2017 at 04:08:31PM +, Bart Van Assche wrote: >> A typical Ethernet network adapter delays the generation of an interrupt >> after it has received a packet. A typical block device or HBA does not delay >> the generation of an interrupt that reports an I/O completion. > > NVMe allows for configurable interrupt coalescing, as do a few modern > SCSI HBAs. Unfortunately it's way too coarse on NVMe, with the timer being in 100 usec increments... I've had mixed success with the depth trigger. -- Jens Axboe -- 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: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
On Wed, Jan 11, 2017 at 04:08:31PM +, Bart Van Assche wrote: [...] > A typical Ethernet network adapter delays the generation of an interrupt > after it has received a packet. A typical block device or HBA does not delay > the generation of an interrupt that reports an I/O completion. I think that > is why polling is more effective for network adapters than for block > devices. I'm not sure whether it is possible to achieve benefits similar to > NAPI for block devices without implementing interrupt coalescing in the > block device firmware. Note: for block device implementations that use the > RDMA API, the RDMA API supports interrupt coalescing (see also > ib_modify_cq()). Well you can always turn off IRQ generation in the HBA just before scheuduling the poll handler and re-enable it after you've exhausted your budget or used too much time, can't you? I'll do some prototyping and tests tomorrow so we have some more ground for discussion. Byte, Johannes -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- 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: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
On Wed, 2017-01-11 at 14:43 +0100, Johannes Thumshirn wrote: > I'd like to attend LSF/MM and would like to discuss polling for block > drivers. > > Currently there is blk-iopoll but it is neither as widely used as NAPI in > the networking field and accoring to Sagi's findings in [1] performance > with polling is not on par with IRQ usage. > > On LSF/MM I'd like to whether it is desirable to have NAPI like polling in > more block drivers and how to overcome the currently seen performance > issues. > > [1] http://lists.infradead.org/pipermail/linux-nvme/2016-October/006975.ht > ml A typical Ethernet network adapter delays the generation of an interrupt after it has received a packet. A typical block device or HBA does not delay the generation of an interrupt that reports an I/O completion. I think that is why polling is more effective for network adapters than for block devices. I'm not sure whether it is possible to achieve benefits similar to NAPI for block devices without implementing interrupt coalescing in the block device firmware. Note: for block device implementations that use the RDMA API, the RDMA API supports interrupt coalescing (see also ib_modify_cq()). An example of the interrupt coalescing parameters for a network adapter: # ethtool -c em1 | grep -E 'rx-usecs:|tx-usecs:' rx-usecs: 3 tx-usecs: 0 Bart.-- 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: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
On Wed, Jan 11, 2017 at 04:08:31PM +, Bart Van Assche wrote: > A typical Ethernet network adapter delays the generation of an interrupt > after it has received a packet. A typical block device or HBA does not delay > the generation of an interrupt that reports an I/O completion. NVMe allows for configurable interrupt coalescing, as do a few modern SCSI HBAs. -- 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: Advanced Format SAT devices show incorrect physical block size
On Tue, 10 Jan 2017, James Bottomley wrote:
> On Tue, 2017-01-10 at 16:00 -0500, Alan Stern wrote:
> > In theory, I suppose we could change the kernel so that it would
> > default to READ CAPACITY(16) for devices that report a SCSI level >=
> > 3, or something along those lines. In general we hesitate to make
> > changes of this sort, because they almost always end up breaking
> > _some_ devices -- and if that happens then the change is reverted,
> > with no exceptions. Linus has a very strict rule about not breaking
> > working systems.
>
> You shouldn't have to change anything: it already does (otherwise how
> else would we detect physical exponent for proper SCSI devices) see
> sd.c:sd_try_rc16_first(). It always returns false for USB because you
> set sdev->try_rc_10_first
In fact, this approach probably won't work. See Bugzilla entries
#43265 and #43391. The devices in those reports claimed to be ANSI
level 4, but they failed anyway.
If you guys want to try the quirk flag, you can apply the patch below.
Then set the usb-storage module parameter quirks=::k where
and are the Vendor and Product ID codes for your device (as 4
hex digits).
In the long run, however, this is not a viable approach. We'd be
better off with an explicit blacklist.
Alan Stern
Index: usb-4.x/drivers/usb/storage/usb.c
===
--- usb-4.x.orig/drivers/usb/storage/usb.c
+++ usb-4.x/drivers/usb/storage/usb.c
@@ -498,7 +498,7 @@ void usb_stor_adjust_quirks(struct usb_d
US_FL_INITIAL_READ10 | US_FL_WRITE_CACHE |
US_FL_NO_ATA_1X | US_FL_NO_REPORT_OPCODES |
US_FL_MAX_SECTORS_240 | US_FL_NO_REPORT_LUNS |
- US_FL_ALWAYS_SYNC);
+ US_FL_ALWAYS_SYNC | US_FL_NEEDS_CAP16);
p = quirks;
while (*p) {
@@ -551,6 +551,9 @@ void usb_stor_adjust_quirks(struct usb_d
case 'j':
f |= US_FL_NO_REPORT_LUNS;
break;
+ case 'k':
+ f |= US_FL_NEEDS_CAP16;
+ break;
case 'l':
f |= US_FL_NOT_LOCKABLE;
break;
--
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: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
On 01/11/2017 04:07 PM, Jens Axboe wrote: > On 01/11/2017 06:43 AM, Johannes Thumshirn wrote: >> Hi all, >> >> I'd like to attend LSF/MM and would like to discuss polling for block >> drivers. >> >> Currently there is blk-iopoll but it is neither as widely used as NAPI in the >> networking field and accoring to Sagi's findings in [1] performance with >> polling is not on par with IRQ usage. >> >> On LSF/MM I'd like to whether it is desirable to have NAPI like polling in >> more block drivers and how to overcome the currently seen performance issues. > > It would be an interesting topic to discuss, as it is a shame that blk-iopoll > isn't used more widely. > Indeed; some drivers like lpfc already _have_ a polling mode, but not hooked up to blk-iopoll. Would be really cool to get that going. Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (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: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
On 01/11/2017 08:07 AM, Jens Axboe wrote: > On 01/11/2017 06:43 AM, Johannes Thumshirn wrote: >> Hi all, >> >> I'd like to attend LSF/MM and would like to discuss polling for block >> drivers. >> >> Currently there is blk-iopoll but it is neither as widely used as NAPI in the >> networking field and accoring to Sagi's findings in [1] performance with >> polling is not on par with IRQ usage. >> >> On LSF/MM I'd like to whether it is desirable to have NAPI like polling in >> more block drivers and how to overcome the currently seen performance issues. > > It would be an interesting topic to discuss, as it is a shame that blk-iopoll > isn't used more widely. Forgot to mention - it should only be a topic, if experimentation has been done and results gathered to pin point what the issues are, so we have something concrete to discus. I'm not at all interested in a hand wavy discussion on the topic. -- Jens Axboe -- 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: Advanced Format SAT devices show incorrect physical block size
On Wed, 11 Jan 2017, Pali Rohár wrote: > On Tuesday 10 January 2017 15:29:23 Alan Stern wrote: > > > Tom Yan wrote that smartctl/hdparm "works" because they use the SCSI ATA > > > PASSTHROUGH command. It is not an option for kernel? > > > > No, because many devices do not implement SCSI ATA PASSTHROUGH. > > (Consider devices whose underlying technology does not use ATA or SATA, > > for example.) And some of the ones that don't implement it will die if > > you try to send them an ATA PASSTHROUGH command. > > It is not possible to detect if underlaying device is ATA? I don't know any reliable way to do it. Besides, even if the device is ATA, you're still out of luck if the USB-SATA bridge doesn't support ATA PASSTHROUGH. > > You have to understand that consumer USB storage really is very > > low quality in many cases. Vendors aim for low cost rather than high > > reliability or correctness. > > Understood. But lot of distributions call hdparm for inserted disks and > also set some APM (or at least check it)... That means there is already > some way how to deal with these problems (in userspace). Maybe. Or maybe users simply don't use hdparm if it causes problems for them. You don't have a similar option with the kernel. Alan Stern -- 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: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
On 01/11/2017 06:43 AM, Johannes Thumshirn wrote: > Hi all, > > I'd like to attend LSF/MM and would like to discuss polling for block drivers. > > Currently there is blk-iopoll but it is neither as widely used as NAPI in the > networking field and accoring to Sagi's findings in [1] performance with > polling is not on par with IRQ usage. > > On LSF/MM I'd like to whether it is desirable to have NAPI like polling in > more block drivers and how to overcome the currently seen performance issues. It would be an interesting topic to discuss, as it is a shame that blk-iopoll isn't used more widely. -- Jens Axboe -- 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: Advanced Format SAT devices show incorrect physical block size
On Tue, 10 Jan 2017, Dainius Masiliūnas wrote: > On Tue, Jan 10, 2017 at 9:00 PM, Alan Stern wrote: > > It is used for preventing the kernel from issuing a READ CAPACITY(16) > > command to the device. Normally the kernel would do this if the reply > > to READ CAPACITY(10) indicated there were more than 2^32 blocks (about > > 2 TB). > > Ah, OK, that makes sense. Though that's still not a proper solution, > and if anything it's confusing for the users: if they plug in a >2 TiB > drive and it breaks, the user will assume that it's the fault of the > drive and not the USB case, or that the case is incapable of handling > such large drives, whereas the true reason is completely different. I'm not sure what you mean. If the quirk flag is set and the user plugs in a >2-TB drive, it won't break. It just won't report the correct size, but at least it will continue to work in a degraded fashion. > > In theory, I suppose we could change the kernel so that it would > > default to READ CAPACITY(16) for devices that report a SCSI level >= 3, > > or something along those lines. In general we hesitate to make changes > > of this sort, because they almost always end up breaking _some_ > > devices -- and if that happens then the change is reverted, with no > > exceptions. Linus has a very strict rule about not breaking working > > systems. > > Well, the problems are 1) we don't really know how many such > misbehaving drives there are, since only those with >2 TiB drives > experience it, thus it's hard to know what effect such change would > have, and 2) there is no way to make the kernel output the true value > even if you know your drive is working fine. We could add that easily enough: a usb-storage quirk to set the NEEDS_CAP16 flag. But it would be better if this wasn't necessary. > And when a drive breaks due to the 16 command, is there a way to > revive it, perhaps by trying to reconnect? That would allow the kernel > to try it first, see that it failed after that command was sent, then > issue a warning in the log saying that this device should have a > quirk, reset and continue with the quirk applied. I'm not sure what you mean by "trying to reconnect". The recovery method most likely to work is to unplug the USB cable and then re-attach it. Issuing a reset might work in some cases and not in others; we have seen examples of devices that crash extremely hard when given something they don't know how to handle. > Also, is `sg_readcap -16` a proper test to determine whether the > device works as expected? You mean, to determine whether the device can handle a READ CAPACITY(16) command? Yes, since that is the command it sends. Alan Stern -- 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 RFC] sas: convert to bsg-lib
Convert the SAS transport class over to using bsg-lib instead of doing "raw"
bsg access.
Signed-off-by: Johannes Thumshirn
---
drivers/scsi/scsi_transport_sas.c | 41 +++
1 file changed, 16 insertions(+), 25 deletions(-)
diff --git a/drivers/scsi/scsi_transport_sas.c
b/drivers/scsi/scsi_transport_sas.c
index 60b651b..b87edfe 100644
--- a/drivers/scsi/scsi_transport_sas.c
+++ b/drivers/scsi/scsi_transport_sas.c
@@ -187,25 +187,19 @@ static void sas_smp_request(struct request_queue *q,
struct Scsi_Host *shost,
}
}
-static void sas_host_smp_request(struct request_queue *q)
-{
- sas_smp_request(q, (struct Scsi_Host *)q->queuedata, NULL);
-}
-
-static void sas_non_host_smp_request(struct request_queue *q)
-{
- struct sas_rphy *rphy = q->queuedata;
- sas_smp_request(q, rphy_to_shost(rphy), rphy);
-}
-
-static void sas_host_release(struct device *dev)
+static int sas_bsg_dispatch(struct bsg_job *job)
{
+ struct device *dev = job->dev;
struct Scsi_Host *shost = dev_to_shost(dev);
- struct sas_host_attrs *sas_host = to_sas_host_attrs(shost);
- struct request_queue *q = sas_host->q;
+ struct sas_rphy *rphy = dev_to_rphy(dev);
+ struct request_queue *q = job->req->q;
- if (q)
- blk_cleanup_queue(q);
+ if (rphy)
+ sas_smp_request(q, rphy_to_shost(rphy), rphy);
+ else
+ sas_smp_request(q, shost, NULL);
+
+ return 0;
}
static int sas_bsg_initialize(struct Scsi_Host *shost, struct sas_rphy *rphy)
@@ -215,7 +209,6 @@ static int sas_bsg_initialize(struct Scsi_Host *shost,
struct sas_rphy *rphy)
struct device *dev;
char namebuf[20];
const char *name;
- void (*release)(struct device *);
if (!to_sas_internal(shost->transportt)->f->smp_handler) {
printk("%s can't handle SMP requests\n", shost->hostt->name);
@@ -223,22 +216,20 @@ static int sas_bsg_initialize(struct Scsi_Host *shost,
struct sas_rphy *rphy)
}
if (rphy) {
- q = blk_init_queue(sas_non_host_smp_request, NULL);
dev = &rphy->dev;
name = dev_name(dev);
- release = NULL;
} else {
- q = blk_init_queue(sas_host_smp_request, NULL);
dev = &shost->shost_gendev;
- snprintf(namebuf, sizeof(namebuf),
-"sas_host%d", shost->host_no);
- name = namebuf;
- release = sas_host_release;
+ name = kasprintf(GFP_KERNEL, "sas_host%d", shost->host_no);
+ if (!name)
+ return -ENOMEM;
}
+
+ q = __scsi_alloc_queue(shost, bsg_request_fn);
if (!q)
return -ENOMEM;
- error = bsg_register_queue(q, dev, name, release);
+ error = bsg_setup_queue(dev, queue, name, sas_bsg_dispatch, 0);
if (error) {
blk_cleanup_queue(q);
return -ENOMEM;
--
2.10.2
--
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: [LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
On 01/11/2017 02:43 PM, Johannes Thumshirn wrote: > Hi all, > > I'd like to attend LSF/MM and would like to discuss polling for block drivers. > > Currently there is blk-iopoll but it is neither as widely used as NAPI in the > networking field and accoring to Sagi's findings in [1] performance with > polling is not on par with IRQ usage. > > On LSF/MM I'd like to whether it is desirable to have NAPI like polling in > more block drivers and how to overcome the currently seen performance issues. > > [1] http://lists.infradead.org/pipermail/linux-nvme/2016-October/006975.html > Yup. I'm all for it. Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (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
[LSF/MM TOPIC][LSF/MM ATTEND] NAPI polling for block drivers
Hi all, I'd like to attend LSF/MM and would like to discuss polling for block drivers. Currently there is blk-iopoll but it is neither as widely used as NAPI in the networking field and accoring to Sagi's findings in [1] performance with polling is not on par with IRQ usage. On LSF/MM I'd like to whether it is desirable to have NAPI like polling in more block drivers and how to overcome the currently seen performance issues. [1] http://lists.infradead.org/pipermail/linux-nvme/2016-October/006975.html Byte, Johannes -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- 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: Advanced Format SAT devices show incorrect physical block size
On Tuesday 10 January 2017 15:29:23 Alan Stern wrote: > > Tom Yan wrote that smartctl/hdparm "works" because they use the SCSI ATA > > PASSTHROUGH command. It is not an option for kernel? > > No, because many devices do not implement SCSI ATA PASSTHROUGH. > (Consider devices whose underlying technology does not use ATA or SATA, > for example.) And some of the ones that don't implement it will die if > you try to send them an ATA PASSTHROUGH command. It is not possible to detect if underlaying device is ATA? > You have to understand that consumer USB storage really is very > low quality in many cases. Vendors aim for low cost rather than high > reliability or correctness. Understood. But lot of distributions call hdparm for inserted disks and also set some APM (or at least check it)... That means there is already some way how to deal with these problems (in userspace). -- Pali Rohár pali.ro...@gmail.com -- 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: Advanced Format SAT devices show incorrect physical block size
On Tuesday 10 January 2017 14:12:25 James Bottomley wrote: > On Tue, 2017-01-10 at 16:00 -0500, Alan Stern wrote: > > In theory, I suppose we could change the kernel so that it would > > default to READ CAPACITY(16) for devices that report a SCSI level >= > > 3, or something along those lines. In general we hesitate to make > > changes of this sort, because they almost always end up breaking > > _some_ devices -- and if that happens then the change is reverted, > > with no exceptions. Linus has a very strict rule about not breaking > > working systems. > > You shouldn't have to change anything: it already does (otherwise how > else would we detect physical exponent for proper SCSI devices) see > sd.c:sd_try_rc16_first(). It always returns false for USB because you > set sdev->try_rc_10_first So.. what does it mean? Can we enable READ CAPACITY(16) for some USB devices? -- Pali Rohár pali.ro...@gmail.com -- 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] qla4xxx: remove two unused MSI-X related #defines
On Wed, Jan 11, 2017 at 02:26:52PM +0100, Christoph Hellwig wrote: > Spotted while preparing qla2xxx changes as the symbols exist in both > drivers (sigh..). > > Signed-off-by: Christoph Hellwig > --- Looks good, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- 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] qla4xxx: remove two unused MSI-X related #defines
Spotted while preparing qla2xxx changes as the symbols exist in both
drivers (sigh..).
Signed-off-by: Christoph Hellwig
---
drivers/scsi/qla4xxx/ql4_def.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/scsi/qla4xxx/ql4_def.h b/drivers/scsi/qla4xxx/ql4_def.h
index aeebefb..fc23371 100644
--- a/drivers/scsi/qla4xxx/ql4_def.h
+++ b/drivers/scsi/qla4xxx/ql4_def.h
@@ -408,9 +408,6 @@ struct qla4_8xxx_legacy_intr_set {
};
/* MSI-X Support */
-
-#define QLA_MSIX_DEFAULT 0
-#define QLA_MSIX_RSP_Q 1
#define QLA_MSIX_ENTRIES 2
/*
--
2.1.4
--
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] preview - block layer help to detect sequential IO
Objective of this patch is -
To move code used in bcache module in block layer which is used to find IO
stream.
Reference code @drivers/md/bcache/request.c check_should_bypass().
This is a high level patch for review and understand if it is worth to follow ?
As of now bcache module use this logic, but good to have it in block layer and
expose function for external use.
In this patch, I move logic of sequential IO search in block layer and exposed
function blk_queue_rq_seq_cutoff.
Low level driver just need to call if they want stream detection per request
queue.
For my testing I just added call blk_queue_rq_seq_cutoff(sdev->request_queue,
4) megaraid_sas driver.
In general, code of bcache module was referred and they are doing almost same
as what we want to do in
megaraid_sas driver below patch -
http://marc.info/?l=linux-scsi&m=148245616108288&w=2
bcache implementation use search algorithm (hashed based on bio start sector)
and detects 128 streams. wanted those implementation to skip
sequential IO
to be placed on SSD and move it direct to the HDD.
Will it be good design to keep this algorithm open at block layer (as proposed
in patch.) ?
Signed-off-by: Kashyap desai
---
diff --git a/block/blk-core.c b/block/blk-core.c
index 14d7c07..2e93d14 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -693,6 +693,7 @@ struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask,
int node_id)
{
struct request_queue *q;
int err;
+ struct seq_io_tracker *io;
q = kmem_cache_alloc_node(blk_requestq_cachep,
gfp_mask | __GFP_ZERO, node_id);
@@ -761,6 +762,15 @@ struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask,
int node_id)
if (blkcg_init_queue(q))
goto fail_ref;
+
+ q->sequential_cutoff = 0;
+ spin_lock_init(&q->io_lock);
+ INIT_LIST_HEAD(&q->io_lru);
+
+ for (io = q->io; io < q->io + BLK_RECENT_IO; io++) {
+ list_add(&io->lru, &q->io_lru);
+ hlist_add_head(&io->hash, q->io_hash + BLK_RECENT_IO);
+ }
return q;
@@ -1876,6 +1886,26 @@ static inline int bio_check_eod(struct bio *bio,
unsigned int nr_sectors)
return 0;
}
+static void add_sequential(struct task_struct *t)
+{
+#define blk_ewma_add(ewma, val, weight, factor) \
+({ \
+(ewma) *= (weight) - 1; \
+(ewma) += (val) << factor; \
+(ewma) /= (weight); \
+(ewma) >> factor; \
+})
+
+ blk_ewma_add(t->sequential_io_avg,
+t->sequential_io, 8, 0);
+
+ t->sequential_io = 0;
+}
+static struct hlist_head *blk_iohash(struct request_queue *q, uint64_t k)
+{
+ return &q->io_hash[hash_64(k, BLK_RECENT_IO_BITS)];
+}
+
static noinline_for_stack bool
generic_make_request_checks(struct bio *bio)
{
@@ -1884,6 +1914,7 @@ static inline int bio_check_eod(struct bio *bio, unsigned
int nr_sectors)
int err = -EIO;
char b[BDEVNAME_SIZE];
struct hd_struct *part;
+ struct task_struct *task = current;
might_sleep();
@@ -1957,6 +1988,42 @@ static inline int bio_check_eod(struct bio *bio,
unsigned int nr_sectors)
if (!blkcg_bio_issue_check(q, bio))
return false;
+ if (q->sequential_cutoff) {
+ struct seq_io_tracker *i;
+ unsigned sectors;
+
+ spin_lock(&q->io_lock);
+
+ hlist_for_each_entry(i, blk_iohash(q, bio->bi_iter.bi_sector),
hash)
+ if (i->last == bio->bi_iter.bi_sector &&
+ time_before(jiffies, i->jiffies))
+ goto found;
+
+ i = list_first_entry(&q->io_lru, struct seq_io_tracker, lru);
+
+ add_sequential(task);
+ i->sequential = 0;
+found:
+ if (i->sequential + bio->bi_iter.bi_size > i->sequential)
+ i->sequential += bio->bi_iter.bi_size;
+
+ i->last = bio_end_sector(bio);
+ i->jiffies = jiffies + msecs_to_jiffies(5000);
+ task->sequential_io = i->sequential;
+
+ hlist_del(&i->hash);
+ hlist_add_head(&i->hash, blk_iohash(q, i->last));
+ list_move_tail(&i->lru, &q->io_lru);
+
+ spin_unlock(&q->io_lock);
+
+ sectors = max(task->sequential_io,
+ task->sequential_io_avg) >> 9;
+ if (sectors >= q->sequential_cutoff >> 9) {
+ bio->is_sequential = true;
+ }
+ }
+
trace_block_bio_queue(q, bio);
return true;
diff --git a/block/blk
[PATCH] lpfc: avoid double free of resource identifiers
From: Roberto Sassu Set variables initialized in lpfc_sli4_alloc_resource_identifiers() to NULL if an error occurred. Otherwise, lpfc_sli4_driver_resource_unset() attempts to free the memory again. Signed-off-by: Roberto Sassu Signed-off-by: Johannes Thumshirn --- drivers/scsi/lpfc/lpfc_sli.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c index 4faa767..a78a3df 100644 --- a/drivers/scsi/lpfc/lpfc_sli.c +++ b/drivers/scsi/lpfc/lpfc_sli.c @@ -5954,18 +5954,25 @@ lpfc_sli4_alloc_resource_identifiers(struct lpfc_hba *phba) free_vfi_bmask: kfree(phba->sli4_hba.vfi_bmask); + phba->sli4_hba.vfi_bmask = NULL; free_xri_ids: kfree(phba->sli4_hba.xri_ids); + phba->sli4_hba.xri_ids = NULL; free_xri_bmask: kfree(phba->sli4_hba.xri_bmask); + phba->sli4_hba.xri_bmask = NULL; free_vpi_ids: kfree(phba->vpi_ids); + phba->vpi_ids = NULL; free_vpi_bmask: kfree(phba->vpi_bmask); + phba->vpi_bmask = NULL; free_rpi_ids: kfree(phba->sli4_hba.rpi_ids); + phba->sli4_hba.rpi_ids = NULL; free_rpi_bmask: kfree(phba->sli4_hba.rpi_bmask); + phba->sli4_hba.rpi_bmask = NULL; err_exit: return rc; } -- 2.10.2 -- 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
[LSF/MM TOPIC][LSF/MM ATTEND] multipath redesign
Hi all, I'd like to attend LSF/MM this year, and would like to discuss a redesign of the multipath handling. With recent kernels we've got quite some functionality required for multipathing already implemented, making some design decisions of the original multipath-tools implementation quite pointless. I'm working on a proof-of-concept implementation which just uses a simple configfs interface and doesn't require a daemon altogether. At LSF/MM I'd like to discuss how to move forward here, and whether we'd like to stay with the current device-mapper integration or move away from that towards a stand-alone implementation. Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (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: [LFS/MM TOPIC][LFS/MM ATTEND]: - Storage Stack and Driver Testing methodology.
On 01/11/2017 10:24 AM, Christoph Hellwig wrote: > On Wed, Jan 11, 2017 at 10:19:45AM +0100, Johannes Thumshirn wrote: >> Well, something I was thinking about but didn't find enough time to actually >> implement is making a xfstestes like test suite written using sg3_utils for >> SCSI. > > Ronnie's libiscsi testsuite can use SG_IO for a new years now: > > https://github.com/sahlberg/libiscsi/tree/master/test-tool > > and has been very useful to find bus in various protocol > implementations. > >> This idea could very well be extented to NVMe > > Chaitanya suite is doing something similar for NVMe, although the > coverage is still much more limited so far. > One of the discussion points here indeed would be if we want to go in the direction of a protocol-specific testsuites (of which we already have several) or if it makes sense to move to functional testing. And if we can have a common interface / documentation on how these things should run. Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (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 14/15] block/bsg: move queue creation into bsg_setup_queue
On 01/11/2017 10:01 AM, Christoph Hellwig wrote: > On Wed, Jan 11, 2017 at 09:59:17AM +0100, Hannes Reinecke wrote: >> I'd advocate to discuss this at LSF. >> Now that Mike moved the bio-based mpath stuff back in things got even >> more complex. > > Yeah. If we'd _only_ have bio based support it would simplify things > a lot, but as a third parallel path it's not exactly making things easier. > >> I'll be posting a patchset for reimplementing multipath as a stand-alone >> driver shortly; that'll give us a good starting point on how we want >> multipath to evolve. >> >> Who knows; we might even manage to move multipath out of device-mapper >> altogether. >> That would make Mike very happy, and I wouldn't mind, either :-) > > Heh. I'm curious how you want to do that while keeping existing setups > working, though. which will become challenging, indeed. ATM it's just a testbed on how things could work; we've got most of the required infrastucture in the kernel nowadays, so that we can just drop most of the complexity from the present multipath-tools mess. In the end it might even boil down to update the existing device-mapper multipath implementation. We'll see. Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (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 v1] scsi: ufs: fix arguments order some trace calls
On 11/01/17 00:48, Subhash Jadavani wrote:
> Colin Ian King reported that with
> commit 7ff5ab473633 ("scsi: ufs: add tracing support") static analysis
> is reporting that we may have swapped arguments on calls to:
> trace_ufshcd_runtime_resume,
> trace_ufshcd_runtime_suspend,
> trace_ufshcd_system_suspend,
> trace_ufshcd_system_resume,
> and trace_ufshcd_init
>
> Where:
> hba->uic_link_state is passed to dev_state
> hba->curr_dev_pwr_mode is passed to link_state
>
> This wasn't intentional so it's a bug. This change fixed this bug.
>
> Reported-by: Colin Ian King
> Signed-off-by: Subhash Jadavani
> ---
> drivers/scsi/ufs/ufshcd.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index be6322e..6b56eb0 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -5805,7 +5805,7 @@ static int ufshcd_probe_hba(struct ufs_hba *hba)
>
> trace_ufshcd_init(dev_name(hba->dev), ret,
> ktime_to_us(ktime_sub(ktime_get(), start)),
> - hba->uic_link_state, hba->curr_dev_pwr_mode);
> + hba->curr_dev_pwr_mode, hba->uic_link_state);
> return ret;
> }
>
> @@ -6819,7 +6819,7 @@ int ufshcd_system_suspend(struct ufs_hba *hba)
> out:
> trace_ufshcd_system_suspend(dev_name(hba->dev), ret,
> ktime_to_us(ktime_sub(ktime_get(), start)),
> - hba->uic_link_state, hba->curr_dev_pwr_mode);
> + hba->curr_dev_pwr_mode, hba->uic_link_state);
> if (!ret)
> hba->is_sys_suspended = true;
> return ret;
> @@ -6852,7 +6852,7 @@ int ufshcd_system_resume(struct ufs_hba *hba)
> out:
> trace_ufshcd_system_resume(dev_name(hba->dev), ret,
> ktime_to_us(ktime_sub(ktime_get(), start)),
> - hba->uic_link_state, hba->curr_dev_pwr_mode);
> + hba->curr_dev_pwr_mode, hba->uic_link_state);
> return ret;
> }
> EXPORT_SYMBOL(ufshcd_system_resume);
> @@ -6880,7 +6880,7 @@ int ufshcd_runtime_suspend(struct ufs_hba *hba)
> out:
> trace_ufshcd_runtime_suspend(dev_name(hba->dev), ret,
> ktime_to_us(ktime_sub(ktime_get(), start)),
> - hba->uic_link_state, hba->curr_dev_pwr_mode);
> + hba->curr_dev_pwr_mode, hba->uic_link_state);
> return ret;
> }
> EXPORT_SYMBOL(ufshcd_runtime_suspend);
> @@ -6921,7 +6921,7 @@ int ufshcd_runtime_resume(struct ufs_hba *hba)
> out:
> trace_ufshcd_runtime_resume(dev_name(hba->dev), ret,
> ktime_to_us(ktime_sub(ktime_get(), start)),
> - hba->uic_link_state, hba->curr_dev_pwr_mode);
> + hba->curr_dev_pwr_mode, hba->uic_link_state);
> return ret;
> }
> EXPORT_SYMBOL(ufshcd_runtime_resume);
>
Thanks, looks good to me.
Acked-by: Colin Ian King
--
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: [LFS/MM TOPIC][LFS/MM ATTEND]: - Storage Stack and Driver Testing methodology.
On Wed, Jan 11, 2017 at 10:19:45AM +0100, Johannes Thumshirn wrote: > Well, something I was thinking about but didn't find enough time to actually > implement is making a xfstestes like test suite written using sg3_utils for > SCSI. Ronnie's libiscsi testsuite can use SG_IO for a new years now: https://github.com/sahlberg/libiscsi/tree/master/test-tool and has been very useful to find bus in various protocol implementations. > This idea could very well be extented to NVMe Chaitanya suite is doing something similar for NVMe, although the coverage is still much more limited so far. -- 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: [LFS/MM TOPIC][LFS/MM ATTEND]: - Storage Stack and Driver Testing methodology.
On Tue, Jan 10, 2017 at 10:40:53PM +, Chaitanya Kulkarni wrote: > Resending it at as a plain text. > > From: Chaitanya Kulkarni > Sent: Tuesday, January 10, 2017 2:37 PM > To: lsf...@lists.linux-foundation.org > Cc: linux-fsde...@vger.kernel.org; linux-bl...@vger.kernel.org; > linux-n...@lists.infradead.org; linux-scsi@vger.kernel.org; > linux-...@vger.kernel.org > Subject: [LFS/MM TOPIC][LFS/MM ATTEND]: - Storage Stack and Driver Testing > methodology. > > > Hi Folks, > > I would like to propose a general discussion on Storage stack and device > driver testing. > > Purpose:- > - > The main objective of this discussion is to address the need for > a Unified Test Automation Framework which can be used by different subsystems > in the kernel in order to improve the overall development and stability > of the storage stack. > > For Example:- > From my previous experience, I've worked on the NVMe driver testing last year > and we > have developed simple unit test framework > (https://github.com/linux-nvme/nvme-cli/tree/master/tests). > In current implementation Upstream NVMe Driver supports following subsystems:- > 1. PCI Host. > 2. RDMA Target. > 3. Fiber Channel Target (in progress). > Today due to lack of centralized automated test framework NVMe Driver testing > is > scattered and performed using the combination of various utilities like > nvme-cli/tests, > nvmet-cli, shell scripts (git://git.infradead.org/nvme-fabrics.git > nvmf-selftests) etc. > > In order to improve overall driver stability with various subsystems, it will > be beneficial > to have a Unified Test Automation Framework (UTAF) which will centralize > overall > testing. > > This topic will allow developers from various subsystem engage in the > discussion about > how to collaborate efficiently instead of having discussions on lengthy email > threads. > > Participants:- > -- > I'd like to invite developers from different subsystems to discuss an > approach towards > a unified testing methodology for storage stack and device drivers belongs to > different subsystems. > > Topics for Discussion:- > -- > As a part of discussion following are some of the key points which we can > focus on:- > 1. What are the common components of the kernel used by the various > subsystems? > 2. What are the potential target drivers which can benefit from this > approach? > (e.g. NVMe, NVMe Over Fabric, Open Channel Solid State Drives etc.) > 3. What are the desired features that can be implemented in this Framework? > (code coverage, unit tests, stress testings, regression, generating > Coccinelle reports etc.) > 4. Desirable Report generation mechanism? > 5. Basic performance validation? > 6. Whether QEMU can be used to emulate some of the H/W functionality to > create a test > platform? (Optional subsystem specific) Well, something I was thinking about but didn't find enough time to actually implement is making a xfstestes like test suite written using sg3_utils for SCSI. This idea could very well be extented to NVMe, AHCI, blk, etc... Byte, Johannes -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- 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] libsas: fix \"sysfs group not found\" warnings at port teardown time
On 11/01/2017 06:29, seeteena wrote: Hi All, Let me know if this patch is accepted in Upsteam? let me know the commit id If it is the patch I think it is then it is not upstream (https://patchwork.kernel.org/patch/6450731/). I did propose a patch at the end of last year which fixed the warn, but it introduced some other potential hotplug issue. An engineer in my organisation proposed a re-work of libsas to fix all the hotplug issues, but it was not pushed and never got far: https://lkml.org/lkml/2016/9/12/1225 John -- 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 -- 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: qedi: select UIO
On 11/01/17 9:40 AM, "Martin K. Petersen" wrote: >> "Ewan" == Ewan D Milne writes: > >Ewan> Randy posted a similar patch back in December but I don't think >Ewan> there was ever a reply to Christoph's question about why qedi >Ewan> depends on uio. > >I did queue up Randy's patch to shut up the build warnings. But we're >still looking for a long term fix or an explanation as to why UIO is >needed in the first place. Similar to bnx2i driver, qedi driver also has a dependency over iscsiuio to provide ARP and DHCP functionality for iscsi offload, and the communication to the driver is done via uio interface. https://github.com/open-iscsi/open-iscsi/blob/master/iscsiuio/README Thanks, Manish -- 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 14/15] block/bsg: move queue creation into bsg_setup_queue
On Wed, Jan 11, 2017 at 09:59:17AM +0100, Hannes Reinecke wrote: > I'd advocate to discuss this at LSF. > Now that Mike moved the bio-based mpath stuff back in things got even > more complex. Yeah. If we'd _only_ have bio based support it would simplify things a lot, but as a third parallel path it's not exactly making things easier. > I'll be posting a patchset for reimplementing multipath as a stand-alone > driver shortly; that'll give us a good starting point on how we want > multipath to evolve. > > Who knows; we might even manage to move multipath out of device-mapper > altogether. > That would make Mike very happy, and I wouldn't mind, either :-) Heh. I'm curious how you want to do that while keeping existing setups working, though. -- 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 14/15] block/bsg: move queue creation into bsg_setup_queue
On Wed, Jan 11, 2017 at 09:56:01AM +0100, Johannes Thumshirn wrote: > I'll dig it up and RFC post it. It's currently untested though as I > currently don't have a SMP capable SAS HBA here. > > Do you have an mptXsas available? Unfortunately not. But I think Hannes has, he has recently played around with the interrupt handling for the driver. -- 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 14/15] block/bsg: move queue creation into bsg_setup_queue
On 01/11/2017 09:45 AM, Christoph Hellwig wrote: > On Wed, Jan 11, 2017 at 09:42:44AM +0100, Johannes Thumshirn wrote: >> On Tue, Jan 10, 2017 at 04:06:19PM +0100, Christoph Hellwig wrote: >>> Simply the boilerplate code needed for bsg nodes a bit. >>> >>> Signed-off-by: Christoph Hellwig >>> --- >> >> that reminds me of posting my SAS bsg-lib patch... > > Yes. Having SAS use bsg-lib, and bsg-lib switched away from abusing > struct request_queue would make this series a lot cleaner. > > So maybe we should get that into the scsi tree for 4.10 together > with the prep patches in this series as a priority and defer the actual > struct request changes once again. That should also give us some more > time to sort out the dm-mpath story.. I'd advocate to discuss this at LSF. Now that Mike moved the bio-based mpath stuff back in things got even more complex. I'll be posting a patchset for reimplementing multipath as a stand-alone driver shortly; that'll give us a good starting point on how we want multipath to evolve. Who knows; we might even manage to move multipath out of device-mapper altogether. That would make Mike very happy, and I wouldn't mind, either :-) Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (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 14/15] block/bsg: move queue creation into bsg_setup_queue
On Wed, Jan 11, 2017 at 09:45:12AM +0100, Christoph Hellwig wrote: > On Wed, Jan 11, 2017 at 09:42:44AM +0100, Johannes Thumshirn wrote: > > On Tue, Jan 10, 2017 at 04:06:19PM +0100, Christoph Hellwig wrote: > > > Simply the boilerplate code needed for bsg nodes a bit. > > > > > > Signed-off-by: Christoph Hellwig > > > --- > > > > that reminds me of posting my SAS bsg-lib patch... > > Yes. Having SAS use bsg-lib, and bsg-lib switched away from abusing > struct request_queue would make this series a lot cleaner. > > So maybe we should get that into the scsi tree for 4.10 together > with the prep patches in this series as a priority and defer the actual > struct request changes once again. That should also give us some more > time to sort out the dm-mpath story.. I'll dig it up and RFC post it. It's currently untested though as I currently don't have a SMP capable SAS HBA here. Do you have an mptXsas available? Byte, Johannes -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- 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 14/15] block/bsg: move queue creation into bsg_setup_queue
On Wed, Jan 11, 2017 at 09:42:44AM +0100, Johannes Thumshirn wrote: > On Tue, Jan 10, 2017 at 04:06:19PM +0100, Christoph Hellwig wrote: > > Simply the boilerplate code needed for bsg nodes a bit. > > > > Signed-off-by: Christoph Hellwig > > --- > > that reminds me of posting my SAS bsg-lib patch... Yes. Having SAS use bsg-lib, and bsg-lib switched away from abusing struct request_queue would make this series a lot cleaner. So maybe we should get that into the scsi tree for 4.10 together with the prep patches in this series as a priority and defer the actual struct request changes once again. That should also give us some more time to sort out the dm-mpath story.. -- 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 01/15] virtio_blk: avoid DMA to stack for the sense buffer
On Wed, Jan 11, 2017 at 09:26:46AM +0100, Johannes Thumshirn wrote: > Isn't that one already queued in Jens' tree? Yes, it's now queued up. Patch 2 was submitted as well and should hopefully go into the next 4.10 RC. -- 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 14/15] block/bsg: move queue creation into bsg_setup_queue
On Tue, Jan 10, 2017 at 04:06:19PM +0100, Christoph Hellwig wrote: > Simply the boilerplate code needed for bsg nodes a bit. > > Signed-off-by: Christoph Hellwig > --- that reminds me of posting my SAS bsg-lib patch... Anyways looks good, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- 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 01/15] virtio_blk: avoid DMA to stack for the sense buffer
On Tue, Jan 10, 2017 at 04:06:06PM +0100, Christoph Hellwig wrote: > Most users of BLOCK_PC requests allocate the sense buffer on the stack, > so to avoid DMA to the stack copy them to a field in the heap allocated > virtblk_req structure. Without that any attempt at SCSI passthrough I/O, > including the SG_IO ioctl from userspace will crash the kernel. Note that > this includes running tools like hdparm even when the host does not have > SCSI passthrough enabled. > > Signed-off-by: Christoph Hellwig > --- Isn't that one already queued in Jens' tree? Byte, Johannes -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- 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
