Re: [PATCH] scsi_transport_fc: Unexport scsi_is_fc_vport()
On 03/28/2016 11:37 PM, Bart Van Assche wrote:
> Running the command "git grep -nHw scsi_is_fc_vport" shows that this
> function is only called from inside scsi_transport_fc.c. Hence unexport
> this function.
>
> Signed-off-by: Bart Van Assche
> Cc: Hannes Reinecke
> Cc: James Smart
> ---
> drivers/scsi/scsi_transport_fc.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/scsi_transport_fc.c
> b/drivers/scsi/scsi_transport_fc.c
> index 8a88226..90afe5d 100644
> --- a/drivers/scsi/scsi_transport_fc.c
> +++ b/drivers/scsi/scsi_transport_fc.c
> @@ -2027,11 +2027,10 @@ static void fc_vport_dev_release(struct device *dev)
> kfree(vport);
> }
>
> -int scsi_is_fc_vport(const struct device *dev)
> +static int scsi_is_fc_vport(const struct device *dev)
> {
> return dev->release == fc_vport_dev_release;
> }
> -EXPORT_SYMBOL(scsi_is_fc_vport);
>
> static int fc_vport_match(struct attribute_container *cont,
> struct device *dev)
>
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 2/2] scsi_dh_alua: Fix a recently introduced deadlock
On 03/28/2016 08:14 PM, Bart Van Assche wrote:
> While retesting the SRP initiator I ran the command "rmmod mlx4_ib"
> while I/O was in progress. That command triggers SCSI device removal
> indirectly. Avoid that this action triggers the following deadlock:
>
> =
> [ INFO: inconsistent lock state ]
> 4.6.0-rc0-dbg+ #2 Tainted: G O
> -
> inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
> multipathd/484 [HC0[0]:SC0[0]:HE1:SE1] takes:
> (&(&pg->lock)->rlock){+.?...}, at: []
> alua_bus_detach+0x52/0xa0 [scsi_dh_alua]
> {IN-SOFTIRQ-W} state was registered at:
> [] __lock_acquire+0x7e9/0x1ad0
> [] lock_acquire+0x60/0x80
> [] _raw_spin_lock_irqsave+0x3e/0x60
> [] alua_rtpg_queue+0x41/0x1d0 [scsi_dh_alua]
> [] alua_check+0xe1/0x220 [scsi_dh_alua]
> [] alua_check_sense+0x99/0xb0 [scsi_dh_alua]
> [] scsi_check_sense+0x71/0x3f0
> [] scsi_decide_disposition+0x18b/0x1d0
> [] scsi_softirq_done+0x52/0x140
> [] blk_done_softirq+0x52/0x90
> [] __do_softirq+0x10f/0x230
> [] irq_exit+0xa8/0xb0
> [] do_IRQ+0x65/0x110
> [] ret_from_intr+0x0/0x19
> [] kmem_cache_alloc+0x151/0x190
> [] create_object+0x34/0x2d0
> [] kmemleak_alloc_percpu+0x56/0xd0
> [] pcpu_alloc+0x38d/0x660
> [] __alloc_percpu_gfp+0xd/0x10
> [] __percpu_counter_init+0x55/0xb0
> [] blkg_alloc+0x79/0x230
> [] blkcg_init_queue+0x26/0x1d0
> [] blk_alloc_queue_node+0x27d/0x2e0
> [] dm_create+0x20c/0x570 [dm_mod]
> [] dev_create+0x56/0x2c0 [dm_mod]
> [] ctl_ioctl+0x26e/0x520 [dm_mod]
> [] dm_ctl_ioctl+0xe/0x20 [dm_mod]
> [] do_vfs_ioctl+0x8e/0x660
> [] SyS_ioctl+0x3c/0x70
> [] entry_SYSCALL_64_fastpath+0x1c/0xac
> irq event stamp: 4290931
> hardirqs last enabled at (4290931): [ 1662.892772]
> [] _raw_spin_unlock_irqrestore+0x31/0x50
> hardirqs last disabled at (4290930): []
> _raw_spin_lock_irqsave+0x17/0x60
> softirqs last enabled at (4290774): []
> __do_softirq+0x1cb/0x230
> softirqs last disabled at (4289831): [] irq_exit+0xa8/0xb0
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
>CPU0
>
> lock(&(&pg->lock)->rlock);
>
> lock(&(&pg->lock)->rlock);
>
> *** DEADLOCK ***
>
> 2 locks held by multipathd/484:
> #0: (&bdev->bd_mutex){+.+.+.}, at: []
> __blkdev_put+0x33/0x360
> #1: (sd_ref_mutex){+.+...}, at: [] scsi_disk_put+0x1c/0x40
>
> stack backtrace:
> CPU: 6 PID: 484 Comm: multipathd Tainted: G O4.6.0-rc0-dbg+ #2
> Call Trace:
> [] dump_stack+0x67/0x92
> [] print_usage_bug+0x215/0x240
> [] mark_lock+0x54a/0x610
> [] __lock_acquire+0x845/0x1ad0
> [] lock_acquire+0x60/0x80
> [] _raw_spin_lock+0x33/0x50
> [] alua_bus_detach+0x52/0xa0 [scsi_dh_alua]
> [] scsi_dh_release_device+0x17/0x50
> [] scsi_device_dev_release_usercontext+0x2a/0x120
> [] execute_in_process_context+0x80/0x90
> [] scsi_device_dev_release+0x17/0x20
> [] device_release+0x2d/0x90
> [] kobject_release+0x7a/0x190
> [] kobject_put+0x26/0x50
> [] put_device+0x12/0x20
> [] scsi_device_put+0x26/0x30
> [] scsi_disk_put+0x2d/0x40
> [] sd_release+0x48/0xb0
> [] __blkdev_put+0x29e/0x360
> [] blkdev_put+0x49/0x170
> [] blkdev_close+0x20/0x30
> [] __fput+0xe8/0x1f0
> [] fput+0x9/0x10
> [] task_work_run+0x6e/0xa0
> [] exit_to_usermode_loop+0xa9/0xb0
> [] syscall_return_slowpath+0xb0/0xc0
> [] entry_SYSCALL_64_fastpath+0xaa/0xac
>
> Fixes: cb0a168cb6b8 (scsi_dh_alua: update 'access_state' field)
> Signed-off-by: Bart Van Assche
> Cc: Hannes Reinecke
> Signed-off-by: Bart Van Assche
> ---
> drivers/scsi/device_handler/scsi_dh_alua.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c
> b/drivers/scsi/device_handler/scsi_dh_alua.c
> index a404a41..8eaed05 100644
> --- a/drivers/scsi/device_handler/scsi_dh_alua.c
> +++ b/drivers/scsi/device_handler/scsi_dh_alua.c
> @@ -1112,9 +1112,9 @@ static void alua_bus_detach(struct scsi_device *sdev)
> h->sdev = NULL;
> spin_unlock(&h->pg_lock);
> if (pg) {
> - spin_lock(&pg->lock);
> + spin_lock_irq(&pg->lock);
> list_del_rcu(&h->node);
> - spin_unlock(&pg->lock);
> + spin_unlock_irq(&pg->lock);
> kref_put(&pg->kref, release_port_group);
> }
> sdev->handler_data = NULL;
>
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] Declare local symbols static
On 03/28/2016 08:13 PM, Bart Van Assche wrote: > Avoid that building with W=1 causes gcc to report warnings about > symbols that have not been declared. > > Signed-off-by: Bart Van Assche > Cc: Hannes Reinecke > --- > drivers/scsi/scsi_sysfs.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > 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
[Bug 98171] [Regression] Marvell SE91xx SATA 3 controllers not recognized correctly
https://bugzilla.kernel.org/show_bug.cgi?id=98171 amal...@yahoo.com changed: What|Removed |Added CC||amal...@yahoo.com --- Comment #8 from amal...@yahoo.com --- I am seeing the same error on my Xubuntu 15.10 system at every boot. [1.707400] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [1.707518] ata14.00: ATAPI: MARVELL VIRTUALL, 1.09, max UDMA/66 [1.707679] ata14.00: configured for UDMA/66 [1.934951] ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 [1.934998] ata14.00: irq_stat 0x4001 [1.935040] ata14.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 1 dma 16640 in Inquiry 12 01 00 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x3 (HSM violation) [1.935089] ata14: hard resetting link [2.262449] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [2.262751] ata14.00: configured for UDMA/66 [2.262825] ata14: EH complete SATA controller: Marvell Technology Group Ltd. 88SE9123 PCIe SATA 6.0 Gb/s controller (rev 11) Kernel: 4.2.0-34-generic #39-Ubuntu SMP Thu Mar 10 22:13:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux (Xubuntu 15.10) Motherboard: Gigabyte Technology Co., Ltd. GA-970A-UD3P Hoping to see this issue addressed shortly. -- 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] sd: Fix excessive capacity printing on devices with blocks bigger than 512 bytes
During revalidate we check whether device capacity has changed before we
decide whether to output disk information or not.
The check for old capacity failed to take into account that we scaled
sdkp->capacity based on the reported logical block size. And therefore
the capacity test would always fail for devices with sectors bigger than
512 bytes and we would print several copies of the same discovery
information.
Avoid scaling sdkp->capacity and instead adjust the value on the fly
when setting the block device capacity and generating fake C/H/S
geometry.
Signed-off-by: Martin K. Petersen
Reported-by: Hannes Reinecke
---
drivers/scsi/sd.c | 28
drivers/scsi/sd.h | 7 ++-
2 files changed, 14 insertions(+), 21 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 5a5457ac9cdb..8401697ff6aa 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1275,18 +1275,19 @@ static int sd_getgeo(struct block_device *bdev, struct
hd_geometry *geo)
struct scsi_disk *sdkp = scsi_disk(bdev->bd_disk);
struct scsi_device *sdp = sdkp->device;
struct Scsi_Host *host = sdp->host;
+ sector_t capacity = logical_to_sectors(sdp, sdkp->capacity);
int diskinfo[4];
/* default to most commonly used values */
-diskinfo[0] = 0x40;/* 1 << 6 */
- diskinfo[1] = 0x20; /* 1 << 5 */
- diskinfo[2] = sdkp->capacity >> 11;
-
+ diskinfo[0] = 0x40; /* 1 << 6 */
+ diskinfo[1] = 0x20; /* 1 << 5 */
+ diskinfo[2] = capacity >> 11;
+
/* override with calculated, extended default, or driver values */
if (host->hostt->bios_param)
- host->hostt->bios_param(sdp, bdev, sdkp->capacity, diskinfo);
+ host->hostt->bios_param(sdp, bdev, capacity, diskinfo);
else
- scsicam_bios_param(bdev, sdkp->capacity, diskinfo);
+ scsicam_bios_param(bdev, capacity, diskinfo);
geo->heads = diskinfo[0];
geo->sectors = diskinfo[1];
@@ -2337,14 +2338,6 @@ got_data:
if (sdkp->capacity > 0x)
sdp->use_16_for_rw = 1;
- /* Rescale capacity to 512-byte units */
- if (sector_size == 4096)
- sdkp->capacity <<= 3;
- else if (sector_size == 2048)
- sdkp->capacity <<= 2;
- else if (sector_size == 1024)
- sdkp->capacity <<= 1;
-
blk_queue_physical_block_size(sdp->request_queue,
sdkp->physical_block_size);
sdkp->device->sector_size = sector_size;
@@ -2812,11 +2805,6 @@ static int sd_try_extended_inquiry(struct scsi_device
*sdp)
return 0;
}
-static inline u32 logical_to_sectors(struct scsi_device *sdev, u32 blocks)
-{
- return blocks << (ilog2(sdev->sector_size) - 9);
-}
-
/**
* sd_revalidate_disk - called the first time a new disk is seen,
* performs disk spin up, read_capacity, etc.
@@ -2900,7 +2888,7 @@ static int sd_revalidate_disk(struct gendisk *disk)
/* Combine with controller limits */
q->limits.max_sectors = min(rw_max, queue_max_hw_sectors(q));
- set_capacity(disk, sdkp->capacity);
+ set_capacity(disk, logical_to_sectors(sdp, sdkp->capacity));
sd_config_write_same(sdkp);
kfree(buffer);
diff --git a/drivers/scsi/sd.h b/drivers/scsi/sd.h
index 5f2a84aff29f..654630bb7d0e 100644
--- a/drivers/scsi/sd.h
+++ b/drivers/scsi/sd.h
@@ -65,7 +65,7 @@ struct scsi_disk {
struct device dev;
struct gendisk *disk;
atomic_topeners;
- sector_tcapacity; /* size in 512-byte sectors */
+ sector_tcapacity; /* size in logical blocks */
u32 max_xfer_blocks;
u32 opt_xfer_blocks;
u32 max_ws_blocks;
@@ -146,6 +146,11 @@ static inline int scsi_medium_access_command(struct
scsi_cmnd *scmd)
return 0;
}
+static inline sector_t logical_to_sectors(struct scsi_device *sdev, sector_t
blocks)
+{
+ return blocks << (ilog2(sdev->sector_size) - 9);
+}
+
/*
* A DIF-capable target device can be formatted with different
* protection schemes. Currently 0 through 3 are defined:
--
2.7.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
Re: [PATCH] sd: fixup capacity calculation for 4k drives
> "Ewan" == Ewan D Milne writes: Ewan/Hannes, Sorry I dropped the ball on this. My eyes started bleeding. Ewan> If we change the meaning of the scsi_disk->capacity field to be Ewan> logical sectors, we also have to change sd_getgeo() in sd.c, do we Ewan> not? I did consider that before sending the original patch but didn't see a problem. In looking closer, however, it does appear that we'd inadvertently change the reported geometry for 4Kn devices that are sufficiently small. So I fixed that up. Ewan> The ->capacity field is also accessed by last_sector_hacks() in Ewan> drivers/usb/storage/transport.c, although it kind of looks like Ewan> that code might not have been correct for 4K sectors with the Ewan> scaled value. That case I had missed. Ew, gross! But yes, that was broken to begin with. I have to admit I was going back and forth how to fix this. But in the end I find it really ugly that capacity suddenly changes from logical blocks to block layer sectors. And I prefer to make that conversion explicit when it is necessary. Amended patch follows... -- 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 v2 0/2] Fix regression and performance issue in cxlflash
> "Uma" == Uma Krishnan writes:
Hey Uma,
Uma> This series has a couple of patches in cxlflash. The first patch
Uma> is critical as it fixes a regression that was introduced by Commit
Uma> 6ded8b3cbd9a ("cxlflash: Unmap problem state area before detaching
Uma> master context") as part of the first SCSI push for v4.6.
Uma> The second patch addresses a performance issue.
main.c | 138 -
main.h |5 --
2 files changed, 97 insertions(+), 46 deletions(-)
This starts to push the limits of what constitutes "a bug fix".
I let it slide because you submitted inside the merge window. Applied to
4.6/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: [PATCHv2 0/3] scsi trace updates
> "Hannes" == Hannes Reinecke writes: Hannes> here are some some small updates to scsi tracing; it fixes the Hannes> decoding for MAINTENANCE_IN and MAINTENANCE_OUT and adds Hannes> definitions for the new ZBC_IN and ZBC_OUT commands. Applied to 4.7/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: [PATCHv3] scsi: disable automatic target scan
> "Hannes" == Hannes Reinecke writes: Hannes> On larger installations it is useful to disable automatic LUN Hannes> scanning, and only add the required LUNs via udev rules. This Hannes> can speed up bootup dramatically. Hannes> This patch introduces a new scan module parameter value Hannes> 'manual', which works like 'none', but can be overriden by Hannes> setting the 'rescan' value from scsi_scan_target to Hannes> 'SCSI_SCAN_MANUAL'. And it updates all relevant callers to set Hannes> the 'rescan' value to 'SCSI_SCAN_MANUAL' if invoked via the Hannes> 'scan' option in sysfs. Applied to 4.7/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: Make the iscsi lld create a WQ_HIGHPRI workqueue itself
On Mon, Mar 28, 2016 at 4:53 PM, Mike Christie wrote:
> On 03/28/2016 03:46 PM, Richard Sharpe wrote:
>> Hi folks,
>>
>> We noticed recently while testing with large numbers of iSCSI
>> connections that iscsid was going to heroic lengths to change the nice
>> value of the iSCSI work queue to -20. It becomes very expensive with
>> hundreds of connections.
>>
>> This small patch has the LLD do the work,
>>
>> Feedback welcome.
>>
>> A small patch will be needed for the user-space tools as well. I will
>> send one in if someone else does not do so.
>>
>> -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操)
>>
>>
>> 0001-Make-the-iscsi-lld-create-a-WQ_HIGHPRI-workqueue.patch
>>
>>
>> From c0f04a66b29a9190109740c03ee9e65bb62afe28 Mon Sep 17 00:00:00 2001
>> From: Richard Sharpe
>> Date: Mon, 28 Mar 2016 13:36:18 -0700
>> Subject: [PATCH] Make the iscsi lld create a WQ_HIGHPRI workqueue.
>>
>> The open-iscsi tools go to heroic efforts to change the nice value of
>> the iscsi workqueue to -20. It scans all processes in /proc and
>> when it finds the one it is interested in calls setpriority.
>>
>> When you are connecting to a reasonable number of iSCSI targets this
>> can be costly.
>>
>> This small patch has the iscsi LLD do the work itself. It seems like
>> the least intrusive way to acheive the result.
>>
>> A small patch will be needed in the open-iscsi userspace tools
>> as well.
>>
>> Signed-off-by: Richard Sharpe
>> ---
>> drivers/scsi/libiscsi.c |4 +++-
>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
>> index 6bffd91..abaefe1 100644
>> --- a/drivers/scsi/libiscsi.c
>> +++ b/drivers/scsi/libiscsi.c
>> @@ -2615,9 +2615,11 @@ struct Scsi_Host *iscsi_host_alloc(struct
>> scsi_host_template *sht,
>> ihost = shost_priv(shost);
>>
>> if (xmit_can_sleep) {
>> + int wq_flags = __WQ_LEGACY | WQ_MEM_RECLAIM | WQ_HIGHPRI;
>
>
> I do not think we need to or are supposed to be setting __WQ_LEGACY. It
> looks like it was only to catch the case here
OK, I will fix that and resubmit.
> https://lkml.org/lkml/2016/1/29/179
>
>
>
>> snprintf(ihost->workq_name, sizeof(ihost->workq_name),
>> "iscsi_q_%d", shost->host_no);
>> - ihost->workq =
>> create_singlethread_workqueue(ihost->workq_name);
>> + ihost->workq = alloc_ordered_workqueue("%s", wq_flags,
>> + ihost->workq_name);
>> if (!ihost->workq)
>> goto free_host;
>> }
>> --
>
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
--
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: Make the iscsi lld create a WQ_HIGHPRI workqueue itself
On 03/28/2016 03:46 PM, Richard Sharpe wrote:
> Hi folks,
>
> We noticed recently while testing with large numbers of iSCSI
> connections that iscsid was going to heroic lengths to change the nice
> value of the iSCSI work queue to -20. It becomes very expensive with
> hundreds of connections.
>
> This small patch has the LLD do the work,
>
> Feedback welcome.
>
> A small patch will be needed for the user-space tools as well. I will
> send one in if someone else does not do so.
>
> -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操)
>
>
> 0001-Make-the-iscsi-lld-create-a-WQ_HIGHPRI-workqueue.patch
>
>
> From c0f04a66b29a9190109740c03ee9e65bb62afe28 Mon Sep 17 00:00:00 2001
> From: Richard Sharpe
> Date: Mon, 28 Mar 2016 13:36:18 -0700
> Subject: [PATCH] Make the iscsi lld create a WQ_HIGHPRI workqueue.
>
> The open-iscsi tools go to heroic efforts to change the nice value of
> the iscsi workqueue to -20. It scans all processes in /proc and
> when it finds the one it is interested in calls setpriority.
>
> When you are connecting to a reasonable number of iSCSI targets this
> can be costly.
>
> This small patch has the iscsi LLD do the work itself. It seems like
> the least intrusive way to acheive the result.
>
> A small patch will be needed in the open-iscsi userspace tools
> as well.
>
> Signed-off-by: Richard Sharpe
> ---
> drivers/scsi/libiscsi.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
> index 6bffd91..abaefe1 100644
> --- a/drivers/scsi/libiscsi.c
> +++ b/drivers/scsi/libiscsi.c
> @@ -2615,9 +2615,11 @@ struct Scsi_Host *iscsi_host_alloc(struct
> scsi_host_template *sht,
> ihost = shost_priv(shost);
>
> if (xmit_can_sleep) {
> + int wq_flags = __WQ_LEGACY | WQ_MEM_RECLAIM | WQ_HIGHPRI;
I do not think we need to or are supposed to be setting __WQ_LEGACY. It
looks like it was only to catch the case here
https://lkml.org/lkml/2016/1/29/179
> snprintf(ihost->workq_name, sizeof(ihost->workq_name),
> "iscsi_q_%d", shost->host_no);
> - ihost->workq = create_singlethread_workqueue(ihost->workq_name);
> + ihost->workq = alloc_ordered_workqueue("%s", wq_flags,
> + ihost->workq_name);
> if (!ihost->workq)
> goto free_host;
> }
> --
--
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 3/3] Avoid that I/O completion processing triggers lockup complaints
Avoid that I/O completion processing triggers the following complaints
if kernel debug options that slow down the kernel significantly are
enabled:
NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [kdmwork-254:2:358]
irq event stamp: 15233868
hardirqs last enabled at (15233867): []
_raw_spin_unlock_irq+0x27/0x40
hardirqs last disabled at (15233868): []
apic_timer_interrupt+0x84/0x90
softirqs last enabled at (15233850): []
__do_softirq+0x1cb/0x230
softirqs last disabled at (15233743): [] irq_exit+0xa8/0xb0
CPU: 3 PID: 358 Comm: kdmwork-254:2
RIP: 0010:[] []
_raw_spin_unlock_irq+0x2f/0x40
Call Trace:
[] scsi_request_fn+0x118/0x600
[] __blk_run_queue+0x2e/0x40
[] __elv_add_request+0x75/0x1f0
[] blk_insert_cloned_request+0x101/0x190
[] map_request+0x18e/0x210 [dm_mod]
[] map_tio_request+0x1d/0x40 [dm_mod]
[] kthread_worker_fn+0x7d/0x1a0
[] kthread+0xea/0x100
[] ret_from_fork+0x3f/0x70
INFO: rcu_sched self-detected stall on CPU
3-...: (6497 ticks this GP) idle=fb9/142/0 softirq=2044956/2045037
fqs=5414
(t=6500 jiffies g=219289 c=219288 q=7233211)
Task dump for CPU 3:
kdmwork-254:2 R running task0 358 2 0x0008
Call Trace:
[] sched_show_task+0xbf/0x150
[] dump_cpu_task+0x32/0x40
[] rcu_dump_cpu_stacks+0x89/0xe0
[] rcu_check_callbacks+0x439/0x730
[] update_process_times+0x34/0x60
[] tick_sched_handle.isra.18+0x20/0x50
[] tick_sched_timer+0x38/0x70
[] __hrtimer_run_queues+0xa5/0x1c0
[] hrtimer_interrupt+0xa6/0x1b0
[] smp_trace_apic_timer_interrupt+0x63/0x90
[] smp_apic_timer_interrupt+0x9/0x10
[] apic_timer_interrupt+0x89/0x90
[] __slab_free+0xc6/0x270
[] kmem_cache_free+0x159/0x160
[] kiocb_free+0x32/0x40
[] aio_complete+0x1e5/0x3c0
[] dio_complete+0x75/0x1d0
[] dio_bio_end_aio+0x7a/0x130
[] bio_endio+0x3a/0x60
[] blk_update_request+0x7c/0x2a0
[] end_clone_bio+0x41/0x70 [dm_mod]
[] bio_endio+0x3a/0x60
[] blk_update_request+0x7c/0x2a0
[] scsi_end_request+0x2e/0x1d0
[] scsi_io_completion+0xb4/0x610
[] scsi_finish_command+0xca/0x120
[] scsi_softirq_done+0x120/0x140
[] blk_done_softirq+0x72/0x90
[] __do_softirq+0x10f/0x230
[] irq_exit+0xa8/0xb0
[] do_IRQ+0x65/0x110
[] common_interrupt+0x89/0x89
[] __multipath_map.isra.16+0x145/0x260 [dm_multipath]
[] multipath_map+0x12/0x20 [dm_multipath]
[] map_request+0x43/0x210 [dm_mod]
[] map_tio_request+0x1d/0x40 [dm_mod]
[] kthread_worker_fn+0x7d/0x1a0
[] kthread+0xea/0x100
[] ret_from_fork+0x3f/0x70
Signed-off-by: Bart Van Assche
---
drivers/scsi/scsi_lib.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 8106515..3bf6c33 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1770,13 +1770,14 @@ static void scsi_request_fn(struct request_queue *q)
struct Scsi_Host *shost;
struct scsi_cmnd *cmd;
struct request *req;
+ int i;
/*
-* To start with, we keep looping until the queue is empty, or until
-* the host is no longer able to accept any more requests.
+* Loop until the queue is empty, until the host is no longer able to
+* accept any more requests or until 256 requests have been processed.
*/
shost = sdev->host;
- for (;;) {
+ for (i = 256; i > 0; i--) {
int rtn;
/*
* get next queueable request. We do this early to make sure
@@ -1861,6 +1862,9 @@ static void scsi_request_fn(struct request_queue *q)
spin_lock_irq(q->queue_lock);
}
+ if (unlikely(i == 0))
+ blk_delay_queue(q, 0);
+
return;
host_not_ready:
--
2.7.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 2/3] block: Limit work processed in softirq context
Avoid that complaints like the one below are reported against a
debug kernel:
NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [disk11_0:2708]
irq event stamp: 17120809
hardirqs last enabled at (17120808): []
_raw_spin_unlock_irqrestore+0x31/0x50
hardirqs last disabled at (17120809): [] 0x88046f223bd0
softirqs last enabled at (17120794): []
scst_check_blocked_dev+0x77/0x1c0 [scst]
softirqs last disabled at (17120795): []
do_softirq_own_stack+0x1c/0x30
RIP: 0010:[] []
_raw_spin_unlock_irqrestore+0x33/0x50
Call Trace:
[] free_debug_processing+0x270/0x3a0
[] __slab_free+0x17a/0x2c0
[] kmem_cache_free+0x1b4/0x1d0
[] mempool_free_slab+0x12/0x20
[] mempool_free+0x26/0x80
[] bio_free+0x49/0x60
[] bio_put+0x1e/0x30
[] end_clone_bio+0x21/0x70 [dm_mod]
[] bio_endio+0x52/0x60
[] blk_update_request+0x7c/0x2a0
[] scsi_end_request+0x2e/0x1d0
[] scsi_io_completion+0xb4/0x610
[] scsi_finish_command+0xca/0x120
[] scsi_softirq_done+0x120/0x140
[] blk_done_softirq+0x76/0x90
[] __do_softirq+0x10f/0x230
[] do_softirq_own_stack+0x1c/0x30
Signed-off-by: Bart Van Assche
---
block/blk-softirq.c | 20
1 file changed, 20 insertions(+)
diff --git a/block/blk-softirq.c b/block/blk-softirq.c
index 53b1737..d4d2fe4 100644
--- a/block/blk-softirq.c
+++ b/block/blk-softirq.c
@@ -21,10 +21,22 @@ static DEFINE_PER_CPU(struct list_head, blk_cpu_done);
static void blk_done_softirq(struct softirq_action *h)
{
struct list_head *cpu_list, local_list;
+ struct request *e;
+ bool reraise = false;
+ int i = 0;
local_irq_disable();
cpu_list = this_cpu_ptr(&blk_cpu_done);
+ list_for_each_entry(e, cpu_list, ipi_list) {
+ if (++i < 256)
+ continue;
+ list_cut_position(&local_list, cpu_list, &e->ipi_list);
+ reraise = true;
+ goto enable_irq;
+ }
list_replace_init(cpu_list, &local_list);
+
+enable_irq:
local_irq_enable();
while (!list_empty(&local_list)) {
@@ -34,6 +46,14 @@ static void blk_done_softirq(struct softirq_action *h)
list_del_init(&rq->ipi_list);
rq->q->softirq_done_fn(rq);
}
+
+ if (!reraise)
+ return;
+
+ local_irq_disable();
+ if (!list_empty(cpu_list))
+ raise_softirq_irqoff(BLOCK_SOFTIRQ);
+ local_irq_enable();
}
#ifdef CONFIG_SMP
--
2.7.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/3] kernel/kthread.c: Avoid CPU lockups
Avoid that complaints similar to the one below are reported against
a debug kernel:
NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [kdmwork-25 4:2:23313]
irq event stamp: 16320042
hardirqs last enabled at (16320041): []
_raw_spin_unlock_irq+0x27/0x40
hardirqs last disabled at (16320042): [] 0x8803ffbe3cd8
softirqs last enabled at (16319960): []
__do_softirq+0x1cb/0x230
softirqs last disabled at (16319715): [] irq_exit+0xa8/0xb0
CPU: 1 PID: 23313 Comm: kdmwork-254:2
RIP: 0010:[] []
_raw_spin_unlock_irq+0x2f/0x40
Call Trace:
[] scsi_request_fn+0x11f/0x630
[] __blk_run_queue+0x2e/0x40
[] __elv_add_request+0x75/0x1f0
[] blk_insert_cloned_request+0x101/0x190
[] map_request+0x16a/0x1b0 [dm_mod]
[] map_tio_request+0x1d/0x40 [dm_mod]
[] kthread_worker_fn+0x82/0x1a0
[] kthread+0xea/0x100
[] ret_from_fork+0x22/0x40
Signed-off-by: Bart Van Assche
---
kernel/kthread.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/kthread.c b/kernel/kthread.c
index 9ff173d..516ca6b 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -593,6 +593,7 @@ repeat:
if (work) {
__set_current_state(TASK_RUNNING);
work->func(work);
+ cond_resched_rcu_qs();
} else if (!freezing(current))
schedule();
--
2.7.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/3] Improve block layer scheduling fairness
Recent tests revealed that on kernels with CONFIG_PREEMPT disabled and with kernel debugging options like CONFIG_PROVE_LOCKING enabled that block/SCSI/dm workloads with a high queue depth cause soft lockup complaints to appear. Avoid this by voluntarily giving up the CPU in time for such workloads. The patches in this series are: 0001-kernel-kthread.c-Avoid-CPU-lockups.patch 0002-block-Limit-work-processed-in-softirq-context.patch 0003-Avoid-that-I-O-completion-processing-triggers-lockup.patch -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] scsi_transport_fc: Unexport scsi_is_fc_vport()
Running the command "git grep -nHw scsi_is_fc_vport" shows that this
function is only called from inside scsi_transport_fc.c. Hence unexport
this function.
Signed-off-by: Bart Van Assche
Cc: Hannes Reinecke
Cc: James Smart
---
drivers/scsi/scsi_transport_fc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
index 8a88226..90afe5d 100644
--- a/drivers/scsi/scsi_transport_fc.c
+++ b/drivers/scsi/scsi_transport_fc.c
@@ -2027,11 +2027,10 @@ static void fc_vport_dev_release(struct device *dev)
kfree(vport);
}
-int scsi_is_fc_vport(const struct device *dev)
+static int scsi_is_fc_vport(const struct device *dev)
{
return dev->release == fc_vport_dev_release;
}
-EXPORT_SYMBOL(scsi_is_fc_vport);
static int fc_vport_match(struct attribute_container *cont,
struct device *dev)
--
2.7.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
Move two declarations from scsi_scan.c into scsi_priv.h
Consistency of the declarations that have been moved can only be checked by the compiler if these are present in a header file that is included from both the source file with the definition and the source file with the caller(s). Hence move these two declarations. Signed-off-by: Bart Van Assche --- drivers/scsi/scsi_priv.h | 2 ++ drivers/scsi/scsi_scan.c | 2 -- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/scsi_priv.h b/drivers/scsi/scsi_priv.h index 27b4d0a..68f7f22 100644 --- a/drivers/scsi/scsi_priv.h +++ b/drivers/scsi/scsi_priv.h @@ -83,6 +83,8 @@ int scsi_noretry_cmd(struct scsi_cmnd *scmd); extern int scsi_maybe_unblock_host(struct scsi_device *sdev); extern void scsi_device_unbusy(struct scsi_device *sdev); extern void scsi_queue_insert(struct scsi_cmnd *cmd, int reason); +extern void scsi_requeue_run_queue(struct work_struct *work); +extern void scsi_evt_thread(struct work_struct *work); extern void scsi_io_completion(struct scsi_cmnd *, unsigned int); extern void scsi_run_host_queues(struct Scsi_Host *shost); extern struct request_queue *scsi_alloc_queue(struct scsi_device *sdev); diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c index 97074c9..9f021e4 100644 --- a/drivers/scsi/scsi_scan.c +++ b/drivers/scsi/scsi_scan.c @@ -214,8 +214,6 @@ static struct scsi_device *scsi_alloc_sdev(struct scsi_target *starget, struct scsi_device *sdev; int display_failure_msg = 1, ret; struct Scsi_Host *shost = dev_to_shost(starget->dev.parent); - extern void scsi_evt_thread(struct work_struct *work); - extern void scsi_requeue_run_queue(struct work_struct *work); sdev = kzalloc(sizeof(*sdev) + shost->transportt->device_size, GFP_ATOMIC); -- 2.7.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] Fix a bdi reregistration race, v3
Avoid that the sd driver registers a BDI device with a name that
is still in use. This patch avoids that the following warning gets
triggered:
WARNING: CPU: 7 PID: 203 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x68/0x80()
sysfs: cannot create duplicate filename '/devices/virtual/bdi/8:32'
Workqueue: events_unbound async_run_entry_fn
Call Trace:
[] dump_stack+0x4c/0x65
[] warn_slowpath_common+0x8a/0xc0
[] warn_slowpath_fmt+0x46/0x50
[] sysfs_warn_dup+0x68/0x80
[] sysfs_create_dir_ns+0x7e/0x90
[] kobject_add_internal+0xa8/0x320
[] kobject_add+0x60/0xb0
[] device_add+0x107/0x5e0
[] device_create_groups_vargs+0xd8/0x100
[] device_create_vargs+0x1c/0x20
[] bdi_register+0x63/0x2a0
[] bdi_register_dev+0x27/0x30
[] add_disk+0x1a9/0x4e0
[] sd_probe_async+0x119/0x1d0 [sd_mod]
[] async_run_entry_fn+0x4a/0x140
[] process_one_work+0x1d8/0x7c0
[] worker_thread+0x114/0x460
[] kthread+0xf8/0x110
[] ret_from_fork+0x3f/0x70
Signed-off-by: Bart Van Assche
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc:
---
drivers/scsi/scsi_sysfs.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 2b642b1..567f2a0 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -1272,9 +1272,26 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
return error;
}
+static int scsi_return_dev(struct device *dev, void *data)
+{
+ struct device **childp = data;
+
+ *childp = dev;
+ return 0;
+}
+
+/* Caller must call put_device() if this function does not return NULL. */
+static struct device *scsi_get_child_dev(struct device *dev)
+{
+ struct device *child = NULL;
+
+ device_for_each_child(dev, &child, scsi_return_dev);
+ return get_device(child);
+}
+
void __scsi_remove_device(struct scsi_device *sdev)
{
- struct device *dev = &sdev->sdev_gendev;
+ struct device *dev = &sdev->sdev_gendev, *sdkp = NULL;
/*
* This cleanup path is not reentrant and while it is impossible
@@ -1289,6 +1306,7 @@ void __scsi_remove_device(struct scsi_device *sdev)
return;
bsg_unregister_queue(sdev->request_queue);
+ sdkp = scsi_get_child_dev(dev);
device_unregister(&sdev->sdev_dev);
transport_remove_device(dev);
scsi_dh_remove_device(sdev);
@@ -1305,6 +1323,16 @@ void __scsi_remove_device(struct scsi_device *sdev)
blk_cleanup_queue(sdev->request_queue);
cancel_work_sync(&sdev->requeue_work);
+ /*
+* blk_cleanup_queue() unregisters the BDI device. The name of the
+* BDI device is derived from the dev_t of the /dev/sd device.
+* Keep a reference to the /dev/sd device until the BDI device
+* has been unregistered to avoid that a BDI device with the same
+* name gets registered before blk_cleanup_queue() has finished.
+*/
+ if (sdkp)
+ put_device(sdkp);
+
if (sdev->host->hostt->slave_destroy)
sdev->host->hostt->slave_destroy(sdev);
transport_destroy_device(dev);
--
2.7.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: [PATCH] Fix a bdi reregistration race, v2
On 11/30/2015 11:23 PM, Christoph Hellwig wrote: On Mon, Nov 30, 2015 at 05:18:50PM -0800, Bart Van Assche wrote: Since the original patch caused a regression, please proceed with reverting the original patch. Regarding this patch: is there anyone on the CC-list of this e-mail who can review it ? I'm not too fond of the approach. I'd much prefer if SCSI would just release the dev_t later, similar to DM or MD. (replying to an e-mail of four months ago) Hello Christoph, Sorry that it took so long but last week I finally found the time to look further into this. I will post a third version of this patch. 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: Make the iscsi lld create a WQ_HIGHPRI workqueue itself
Hi folks, We noticed recently while testing with large numbers of iSCSI connections that iscsid was going to heroic lengths to change the nice value of the iSCSI work queue to -20. It becomes very expensive with hundreds of connections. This small patch has the LLD do the work, Feedback welcome. A small patch will be needed for the user-space tools as well. I will send one in if someone else does not do so. -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操) 0001-Make-the-iscsi-lld-create-a-WQ_HIGHPRI-workqueue.patch Description: Binary data
Re: [PATCH 2/2] scsi_dh_alua: Fix a recently introduced deadlock
In similar testing last month with mlx4_ib I was able to generate the same
lockup so this patch will help.
If I get a chance will add a Tested-by this week.
Reviewed-by: Laurence Oberman
Laurence Oberman
Principal Software Maintenance Engineer
Red Hat Global Support Services
- Original Message -
From: "Bart Van Assche"
To: "James Bottomley" , "Martin K.
Petersen"
Cc: "Hannes Reinecke" , "Christoph Hellwig" ,
linux-scsi@vger.kernel.org
Sent: Monday, March 28, 2016 2:14:04 PM
Subject: [PATCH 2/2] scsi_dh_alua: Fix a recently introduced deadlock
While retesting the SRP initiator I ran the command "rmmod mlx4_ib"
while I/O was in progress. That command triggers SCSI device removal
indirectly. Avoid that this action triggers the following deadlock:
=
[ INFO: inconsistent lock state ]
4.6.0-rc0-dbg+ #2 Tainted: G O
-
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
multipathd/484 [HC0[0]:SC0[0]:HE1:SE1] takes:
(&(&pg->lock)->rlock){+.?...}, at: []
alua_bus_detach+0x52/0xa0 [scsi_dh_alua]
{IN-SOFTIRQ-W} state was registered at:
[] __lock_acquire+0x7e9/0x1ad0
[] lock_acquire+0x60/0x80
[] _raw_spin_lock_irqsave+0x3e/0x60
[] alua_rtpg_queue+0x41/0x1d0 [scsi_dh_alua]
[] alua_check+0xe1/0x220 [scsi_dh_alua]
[] alua_check_sense+0x99/0xb0 [scsi_dh_alua]
[] scsi_check_sense+0x71/0x3f0
[] scsi_decide_disposition+0x18b/0x1d0
[] scsi_softirq_done+0x52/0x140
[] blk_done_softirq+0x52/0x90
[] __do_softirq+0x10f/0x230
[] irq_exit+0xa8/0xb0
[] do_IRQ+0x65/0x110
[] ret_from_intr+0x0/0x19
[] kmem_cache_alloc+0x151/0x190
[] create_object+0x34/0x2d0
[] kmemleak_alloc_percpu+0x56/0xd0
[] pcpu_alloc+0x38d/0x660
[] __alloc_percpu_gfp+0xd/0x10
[] __percpu_counter_init+0x55/0xb0
[] blkg_alloc+0x79/0x230
[] blkcg_init_queue+0x26/0x1d0
[] blk_alloc_queue_node+0x27d/0x2e0
[] dm_create+0x20c/0x570 [dm_mod]
[] dev_create+0x56/0x2c0 [dm_mod]
[] ctl_ioctl+0x26e/0x520 [dm_mod]
[] dm_ctl_ioctl+0xe/0x20 [dm_mod]
[] do_vfs_ioctl+0x8e/0x660
[] SyS_ioctl+0x3c/0x70
[] entry_SYSCALL_64_fastpath+0x1c/0xac
irq event stamp: 4290931
hardirqs last enabled at (4290931): [ 1662.892772]
[] _raw_spin_unlock_irqrestore+0x31/0x50
hardirqs last disabled at (4290930): []
_raw_spin_lock_irqsave+0x17/0x60
softirqs last enabled at (4290774): []
__do_softirq+0x1cb/0x230
softirqs last disabled at (4289831): [] irq_exit+0xa8/0xb0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(&(&pg->lock)->rlock);
lock(&(&pg->lock)->rlock);
*** DEADLOCK ***
2 locks held by multipathd/484:
#0: (&bdev->bd_mutex){+.+.+.}, at: []
__blkdev_put+0x33/0x360
#1: (sd_ref_mutex){+.+...}, at: [] scsi_disk_put+0x1c/0x40
stack backtrace:
CPU: 6 PID: 484 Comm: multipathd Tainted: G O4.6.0-rc0-dbg+ #2
Call Trace:
[] dump_stack+0x67/0x92
[] print_usage_bug+0x215/0x240
[] mark_lock+0x54a/0x610
[] __lock_acquire+0x845/0x1ad0
[] lock_acquire+0x60/0x80
[] _raw_spin_lock+0x33/0x50
[] alua_bus_detach+0x52/0xa0 [scsi_dh_alua]
[] scsi_dh_release_device+0x17/0x50
[] scsi_device_dev_release_usercontext+0x2a/0x120
[] execute_in_process_context+0x80/0x90
[] scsi_device_dev_release+0x17/0x20
[] device_release+0x2d/0x90
[] kobject_release+0x7a/0x190
[] kobject_put+0x26/0x50
[] put_device+0x12/0x20
[] scsi_device_put+0x26/0x30
[] scsi_disk_put+0x2d/0x40
[] sd_release+0x48/0xb0
[] __blkdev_put+0x29e/0x360
[] blkdev_put+0x49/0x170
[] blkdev_close+0x20/0x30
[] __fput+0xe8/0x1f0
[] fput+0x9/0x10
[] task_work_run+0x6e/0xa0
[] exit_to_usermode_loop+0xa9/0xb0
[] syscall_return_slowpath+0xb0/0xc0
[] entry_SYSCALL_64_fastpath+0xaa/0xac
Fixes: cb0a168cb6b8 (scsi_dh_alua: update 'access_state' field)
Signed-off-by: Bart Van Assche
Cc: Hannes Reinecke
Signed-off-by: Bart Van Assche
---
drivers/scsi/device_handler/scsi_dh_alua.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c
b/drivers/scsi/device_handler/scsi_dh_alua.c
index a404a41..8eaed05 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -1112,9 +1112,9 @@ static void alua_bus_detach(struct scsi_device *sdev)
h->sdev = NULL;
spin_unlock(&h->pg_lock);
if (pg) {
- spin_lock(&pg->lock);
+ spin_lock_irq(&pg->lock);
list_del_rcu(&h->node);
- spin_unlock(&pg->lock);
+ spin_unlock_irq(&pg->lock);
kref_put(&pg->kref, release_port_group);
}
sdev->handler_data = NULL;
--
2.7.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
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body
Re: [PATCH v1 0/2] genirq: support multiple IRQ notifier.
On Fri, Mar 25, 2016 at 12:32:43PM -0700, Christoph Hellwig wrote: > On Fri, Mar 25, 2016 at 08:51:51AM -0700, Weongyo Jeong wrote: > > Each irq_desc only supports one IRQ affinity notifier at current > > implementation so when we try to register another notifier, it silently > > unregister previous entry and register new one. > > > > However the problem is that if CONFIG_RFS_ACCEL is set, at current > > implementation no way to set additional IRQ affinity notifier for > > some NIC cards RFS enabled because it already used for RFS. > > With this patch we can register multiple IRQ affinity notifiers. > > The whole concept of these irq affinity notifiers seems wrong to me. > > If a device supports MSI-X it should simply request per-cpu or per-node > vectors and we should prevent affinity changes for them. This could be a silly question. Are you meaning that we should remove feature of IRQ affinity notifiers and device writer should explicitly set CPU affinity with masking when it requests IRQ? And then some CPU affinity of IRQ are still changable via /proc/irq//smp_affinity and some aren't for device drivers, right? Regards, Weongyo Jeong -- 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] scsi_dh_alua: Fix a recently introduced deadlock
While retesting the SRP initiator I ran the command "rmmod mlx4_ib"
while I/O was in progress. That command triggers SCSI device removal
indirectly. Avoid that this action triggers the following deadlock:
=
[ INFO: inconsistent lock state ]
4.6.0-rc0-dbg+ #2 Tainted: G O
-
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
multipathd/484 [HC0[0]:SC0[0]:HE1:SE1] takes:
(&(&pg->lock)->rlock){+.?...}, at: []
alua_bus_detach+0x52/0xa0 [scsi_dh_alua]
{IN-SOFTIRQ-W} state was registered at:
[] __lock_acquire+0x7e9/0x1ad0
[] lock_acquire+0x60/0x80
[] _raw_spin_lock_irqsave+0x3e/0x60
[] alua_rtpg_queue+0x41/0x1d0 [scsi_dh_alua]
[] alua_check+0xe1/0x220 [scsi_dh_alua]
[] alua_check_sense+0x99/0xb0 [scsi_dh_alua]
[] scsi_check_sense+0x71/0x3f0
[] scsi_decide_disposition+0x18b/0x1d0
[] scsi_softirq_done+0x52/0x140
[] blk_done_softirq+0x52/0x90
[] __do_softirq+0x10f/0x230
[] irq_exit+0xa8/0xb0
[] do_IRQ+0x65/0x110
[] ret_from_intr+0x0/0x19
[] kmem_cache_alloc+0x151/0x190
[] create_object+0x34/0x2d0
[] kmemleak_alloc_percpu+0x56/0xd0
[] pcpu_alloc+0x38d/0x660
[] __alloc_percpu_gfp+0xd/0x10
[] __percpu_counter_init+0x55/0xb0
[] blkg_alloc+0x79/0x230
[] blkcg_init_queue+0x26/0x1d0
[] blk_alloc_queue_node+0x27d/0x2e0
[] dm_create+0x20c/0x570 [dm_mod]
[] dev_create+0x56/0x2c0 [dm_mod]
[] ctl_ioctl+0x26e/0x520 [dm_mod]
[] dm_ctl_ioctl+0xe/0x20 [dm_mod]
[] do_vfs_ioctl+0x8e/0x660
[] SyS_ioctl+0x3c/0x70
[] entry_SYSCALL_64_fastpath+0x1c/0xac
irq event stamp: 4290931
hardirqs last enabled at (4290931): [ 1662.892772]
[] _raw_spin_unlock_irqrestore+0x31/0x50
hardirqs last disabled at (4290930): []
_raw_spin_lock_irqsave+0x17/0x60
softirqs last enabled at (4290774): []
__do_softirq+0x1cb/0x230
softirqs last disabled at (4289831): [] irq_exit+0xa8/0xb0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(&(&pg->lock)->rlock);
lock(&(&pg->lock)->rlock);
*** DEADLOCK ***
2 locks held by multipathd/484:
#0: (&bdev->bd_mutex){+.+.+.}, at: []
__blkdev_put+0x33/0x360
#1: (sd_ref_mutex){+.+...}, at: [] scsi_disk_put+0x1c/0x40
stack backtrace:
CPU: 6 PID: 484 Comm: multipathd Tainted: G O4.6.0-rc0-dbg+ #2
Call Trace:
[] dump_stack+0x67/0x92
[] print_usage_bug+0x215/0x240
[] mark_lock+0x54a/0x610
[] __lock_acquire+0x845/0x1ad0
[] lock_acquire+0x60/0x80
[] _raw_spin_lock+0x33/0x50
[] alua_bus_detach+0x52/0xa0 [scsi_dh_alua]
[] scsi_dh_release_device+0x17/0x50
[] scsi_device_dev_release_usercontext+0x2a/0x120
[] execute_in_process_context+0x80/0x90
[] scsi_device_dev_release+0x17/0x20
[] device_release+0x2d/0x90
[] kobject_release+0x7a/0x190
[] kobject_put+0x26/0x50
[] put_device+0x12/0x20
[] scsi_device_put+0x26/0x30
[] scsi_disk_put+0x2d/0x40
[] sd_release+0x48/0xb0
[] __blkdev_put+0x29e/0x360
[] blkdev_put+0x49/0x170
[] blkdev_close+0x20/0x30
[] __fput+0xe8/0x1f0
[] fput+0x9/0x10
[] task_work_run+0x6e/0xa0
[] exit_to_usermode_loop+0xa9/0xb0
[] syscall_return_slowpath+0xb0/0xc0
[] entry_SYSCALL_64_fastpath+0xaa/0xac
Fixes: cb0a168cb6b8 (scsi_dh_alua: update 'access_state' field)
Signed-off-by: Bart Van Assche
Cc: Hannes Reinecke
Signed-off-by: Bart Van Assche
---
drivers/scsi/device_handler/scsi_dh_alua.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c
b/drivers/scsi/device_handler/scsi_dh_alua.c
index a404a41..8eaed05 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -1112,9 +1112,9 @@ static void alua_bus_detach(struct scsi_device *sdev)
h->sdev = NULL;
spin_unlock(&h->pg_lock);
if (pg) {
- spin_lock(&pg->lock);
+ spin_lock_irq(&pg->lock);
list_del_rcu(&h->node);
- spin_unlock(&pg->lock);
+ spin_unlock_irq(&pg->lock);
kref_put(&pg->kref, release_port_group);
}
sdev->handler_data = NULL;
--
2.7.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] Declare local symbols static
Avoid that building with W=1 causes gcc to report warnings about
symbols that have not been declared.
Signed-off-by: Bart Van Assche
Cc: Hannes Reinecke
---
drivers/scsi/scsi_sysfs.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 92ffd24..2b642b1 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -81,6 +81,7 @@ const char *scsi_host_state_name(enum scsi_host_state state)
return name;
}
+#ifdef CONFIG_SCSI_DH
static const struct {
unsigned char value;
char*name;
@@ -94,7 +95,7 @@ static const struct {
{ SCSI_ACCESS_STATE_TRANSITIONING, "transitioning" },
};
-const char *scsi_access_state_name(unsigned char state)
+static const char *scsi_access_state_name(unsigned char state)
{
int i;
char *name = NULL;
@@ -107,6 +108,7 @@ const char *scsi_access_state_name(unsigned char state)
}
return name;
}
+#endif
static int check_set(unsigned long long *val, char *src)
{
@@ -226,7 +228,7 @@ show_shost_state(struct device *dev, struct
device_attribute *attr, char *buf)
}
/* DEVICE_ATTR(state) clashes with dev_attr_state for sdev */
-struct device_attribute dev_attr_hstate =
+static struct device_attribute dev_attr_hstate =
__ATTR(state, S_IRUGO | S_IWUSR, show_shost_state, store_shost_state);
static ssize_t
@@ -401,7 +403,7 @@ static struct attribute *scsi_sysfs_shost_attrs[] = {
NULL
};
-struct attribute_group scsi_shost_attr_group = {
+static struct attribute_group scsi_shost_attr_group = {
.attrs =scsi_sysfs_shost_attrs,
};
--
2.7.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] scsi_dh_alua fixes for kernel v4.6
Hello James and Martin, Please consider the two patches in this series for inclusion in kernel v4.6. These patches are what I came up with while retesting the v4.6-rc1 scsi_dh_alua handler. The actual patches are: 0001-scsi-Declare-local-symbols-static.patch 0002-scsi_dh_alua-Fix-a-recently-introduced-deadlock.patch 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 0/2] scsi: remove orphaned modular code from non-modular drivers
[Re: [PATCH 0/2] scsi: remove orphaned modular code from non-modular drivers]
On 27/03/2016 (Sun 22:31) James Bottomley wrote:
> On Sun, 2016-03-27 at 13:00 -0400, Paul Gortmaker wrote:
> > In the ongoing audit/cleanup of non-modular code needlessly using
> > modular infrastructure, the SCSI subsystem fortunately only contains
> > two instances that I detected. Both are for legacy drivers that
> > predate the git epoch, so cleary there is no demand for converting
> > these drivers to be tristate.
> >
> > For anyone new to the underlying goal of this cleanup, we are trying
> > to not use module support for code that isn't buildable as a module
> > since:
> >
> > (1) it is easy to accidentally write unused module_exit and remove
> > code
> > (2) it can be misleading when reading the source, thinking it can be
> > modular when the Makefile and/or Kconfig prohibit it
> > (3) it requires the include of the module.h header file which in
> > turn
> > includes nearly everything else, thus adding to CPP overhead.
> > (4) it gets copied/replicated into other code and spreads like
> > weeds.
>
> I don't really buy any of these as being credible issues for the
> ancient drivers, so there doesn't appear to be an real benefit to this
> conversion; however, besides the danger of touching old stuff, there
> are some down sides:
Thanks James for your review and always interesting/alternative
viewpoints. You seem pretty clear in your conviction here, so I won't
bother making counter points ; best we just agree to disagree, and I
won't bother you with these patches again.
Paul.
--
>
> > -MODULE_DESCRIPTION("Sun3x ESP SCSI driver");
> > -MODULE_AUTHOR("Thomas Bogendoerfer (tsbog...@alpha.franken.de)");
> > -MODULE_LICENSE("GPL");
> > -MODULE_VERSION(DRV_VERSION);
>
> These tags are usefully greppable for drivers, regardless of whether
> they generate actual kernel side information.
>
> > We explicitly disallow a driver unbind, since that doesn't have a
> > sensible use case anyway, and it allows us to drop the ".remove"
> > code for non-modular drivers.
>
> That's bogus. I use bind and unbind a lot for testing built in drivers
> but the usual user use case is for resetting the devices.
>
> > Build tested for mips (jazz) and m68k (sun3x) on 4.6-rc1 to ensure no
> > silly typos crept in.
>
> For trivial changes, build testing is not really sufficient: a
> significant fraction of them break something that isn't spotted by the
> reviewers. For the older drivers, this isn't discovered for months to
> years and then someone has to go digging back through all the so called
> trivial changes to find which one it was.
>
> James
>
--
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/5] mempool based chained scatterlist alloc/free api
On Thu, Mar 24, 2016 at 8:46 AM, James Bottomley wrote: > On Thu, 2016-03-24 at 08:09 -0700, Ming Lin wrote: >> On Wed, Mar 23, 2016 at 12:40 AM, Christoph Hellwig >> wrote: >> > On Tue, Mar 22, 2016 at 03:03:11PM -0700, Ming Lin wrote: >> > > From: Ming Lin >> > > >> > > The fist 4 patches make the SG related >> > > definitions/structs/functions >> > > in SCSI code generic and the last patch move it to lib/sg_pool.c. >> > > >> > > I still keep the macro "SG_MEMPOOL_NR" since it's used in 3 >> > > places. >> > >> > I don't ѕee the point, but I'm not going to block the series over >> > it either. >> > >> > The new series looks really nice to me! >> > >> > Reviewed-by: Christoph Hellwig >> >> Hi James, >> >> This series touches several sub-systems. >> What's the best way to merge it? > > It has a minor intrusion into > > drivers/ata/pata_icside.c | 2 +- > drivers/infiniband/ulp/srp/ib_srp.c | 4 +- > drivers/usb/storage/scsiglue.c | 2 +- > > Apart from that, it's all SCSI, so the SCSI tree would seem to be the > best one. Are you OK to merge it? Thanks. -- 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
