Re: [PATCH v2] libsas: fix "sysfs group not found" warnings at port teardown time
On Wed, May 20, 2015 at 07:00:53PM -0400, Dan Williams wrote:
> Praveen reports:
>
> After some debugging this is what I have found
>
> sas_phye_loss_of_signal gets triggered on phy_event from mvsas
> sas_phye_loss_of_signal calls sas_deform_port
> sas_deform_port posts a DISCE_DESTRUCT event
> (sas_unregister_domain_devices-> sas_unregister_dev)
> sas_deform_port calls sas_port_delete
> sas_port_delete calls sas_port_delete_link
> sysfs_remove_group: kobject 'port-X:Y'
> sas_port_delete calls device_del
> sysfs_remove_group: kobject 'port-X:Y'
>
> sas_destruct_devices gets triggered for the destruct event
> (DISCE_DESTRUCT)
> sas_destruct_devices calls sas_rphy_delete
> sas_rphy_delete calls scsi_remove_device
> scsi_remove_device calls __scsi_remove_device
> __scsi_remove_device calls bsg_unregister_queue
> bsg_unregister_queue -> device_unregister ->
> device_del -> sysfs_remove_group: kobject 'X:0:0:0'
>
> Since X:0:0:0 falls under port-X:Y (which got deleted during
> sas_port_delete), this call results in the warning. All the later
> warnings in the dmesg output I sent earlier are trying to delete objects
> under port-X:Y. Since port-X:Y got recursively deleted, all these calls
> result in warnings. Since, the PHY and DISC events are processed in two
> different work queues (and one triggers the other), is there any way
> other than checking if the object exists in sysfs (in device_del) before
> deleting?
>
> [ cut here ]
> WARNING: CPU: 2 PID: 6 at fs/sysfs/group.c:219 device_del+0x40/0x1c0()
> sysfs group 818b97e0 not found for kobject '2:0:4:0'
> [..]
> CPU: 2 PID: 6 Comm: kworker/u8:0 Tainted: PW O
> 3.16.7-ckt9-logicube-ng.3 #1
> Hardware name: To be filled by O.E.M. To be filled by O.E.M./VT6085, BIOS
> 4.6.5 01/23/2015
> Workqueue: scsi_wq_2 sas_destruct_devices [libsas]
> 0009 8151cd18 88011b35bcd8 810687b7
> 88011a661400 88011b35bd28 8800c6e5e968 88028810
> 8800c89f2c00 8106881c 81733b68 0028
> Call Trace:
> [] ? dump_stack+0x41/0x51
> [] ? warn_slowpath_common+0x77/0x90
> [] ? warn_slowpath_fmt+0x4c/0x50
> [] ? device_del+0x40/0x1c0
> [] ? device_unregister+0x1a/0x70
> [] ? bsg_unregister_queue+0x5e/0xb0
> [] ? __scsi_remove_device+0xa9/0xd0 [scsi_mod]
>
> It appears we've always been double deleting the devices below sas_port,
> but recent sysfs changes now exposes this problem. Libsas should delete
> all the devices from rphy down before deleting the parent port.
>
> Cc:
> Reported-by: Praveen Murali
> Tested-by: Praveen Murali
> Signed-off-by: Dan Williams
> ---
>
> v2: drop the "---" separators that will confuse git-am. Thanks Luis!
>
Awesome, thanks a lot!
Cheers,
--
Luís
> drivers/scsi/libsas/sas_discover.c |6 +++---
> drivers/scsi/libsas/sas_port.c |1 -
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/scsi/libsas/sas_discover.c
> b/drivers/scsi/libsas/sas_discover.c
> index 60de66252fa2..a4db770fe8b0 100644
> --- a/drivers/scsi/libsas/sas_discover.c
> +++ b/drivers/scsi/libsas/sas_discover.c
> @@ -362,11 +362,14 @@ static void sas_destruct_devices(struct work_struct
> *work)
> clear_bit(DISCE_DESTRUCT, &port->disc.pending);
>
> list_for_each_entry_safe(dev, n, &port->destroy_list, disco_list_node) {
> + struct sas_port *sas_port =
> dev_to_sas_port(dev->rphy->dev.parent);
> +
> list_del_init(&dev->disco_list_node);
>
> sas_remove_children(&dev->rphy->dev);
> sas_rphy_delete(dev->rphy);
> sas_unregister_common_dev(port, dev);
> + sas_port_delete(sas_port);
> }
> }
>
> @@ -400,9 +403,6 @@ void sas_unregister_domain_devices(struct asd_sas_port
> *port, int gone)
>
> list_for_each_entry_safe(dev, n, &port->disco_list, disco_list_node)
> sas_unregister_dev(port, dev);
> -
> - port->port->rphy = NULL;
> -
> }
>
> void sas_device_set_phy(struct domain_device *dev, struct sas_port *port)
> diff --git a/drivers/scsi/libsas/sas_port.c b/drivers/scsi/libsas/sas_port.c
> index d3c5297c6c89..9a25ae3a52a4 100644
> --- a/drivers/scsi/libsas/sas_port.c
> +++ b/drivers/scsi/libsas/sas_port.c
> @@ -219,7 +219,6 @@ void sas_deform_port(struct asd_sas_phy *phy, int gone)
>
> if (port->num_phys == 1) {
> sas_unregister_domain_devices(port, gone);
> - sas_port_delete(port->port);
> port->port = NULL;
> } else {
> sas_port_delete_phy(port->port, phy->phy);
>
--
To un
Re: [PATCH] libsas: fix "sysfs group not found" warnings at port teardown time
On Wed, May 20, 2015 at 06:09:09PM -0400, Dan Williams wrote: > Praveen reports: > > --- > Just a minor comment, not related with the patch itself but with the commit message: the line above will cause major pain to anyone applying this patch using 'git am'. This is because git-mailinfo, when splitting the patch from the message, will assume the message stops here. git-am(1) documents this behaviour, the commit message ends with: - three-dashes and end-of-line, or - a line that begins with "diff -", or - a line that begins with "Index: " Cheers, -- Luís -- 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: Backport of a fix for HPSA (Disabling a disabled device problem during kdump) driver
On Mon, Apr 13, 2015 at 03:18:44PM +0200, Tomas Henzl wrote: > On 04/11/2015 12:45 AM, Vinson Lee wrote: > > On Tue, Jan 27, 2015 at 4:18 PM, Greg KH wrote: > >> On Tue, Jan 06, 2015 at 05:15:19PM +0100, Tomas Henzl wrote: > >>> On 01/05/2015 07:41 PM, Masoud Sharbiani wrote: > Dear stable maintainers, > Can you please backport commitid 132aa220b45d60e9b20def1e9d8be9422eed9616 > (hpsa: refine the pci enable/disable handling) to 3.10 stable (and > earlier, if applicable)? > >>> Please do not apply this patch isolated from his friend, the > >>> 859c75aba20264d87dd026bab0d0ca3bff385955 hpsa: add missing pci_set_master > >>> in kdump path > >>> needs to be applied together with the > >>> 132aa220b45d60e9b20def1e9d8be9422eed9616 . > >>> > >>> In addition to that, after the original issue goes away you may notice > >>> sometimes > >>> an unhandled irq 16 message, to fix this a patch is posted > >>> here http://www.spinics.net/lists/linux-scsi/msg80316.html > >>> This patch still awaits a maintainers review though. > >>> > >>> Probably the best idea is to wait until the issue is solved completely. > >> I'll wait, when it all gets worked out, please let stable@ know what > >> patches to apply where. > >> > >> thanks, > >> > >> greg k-h > >> -- > >> To unsubscribe from this list: send the line "unsubscribe stable" in > >> the body of a message to majord...@vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > Hi, Thomas. > > > > The unhandled irq 16 issue seems to be fixed by 4.0-rc1 commit "hpsa: > > turn off interrupts when kdump starts". > > > > Are the following patches suitable for stable now? > > Yes, I believe they are, just note that > 03741d9 hpsa: fix memory leak in kdump hard reset > is not a part of that group we discussed before, but it may be added > to stable too. > > Cheers, > Tomas > > > > > 3b74729 hpsa: turn off interrupts when kdump starts > > 03741d9 hpsa: fix memory leak in kdump hard reset > > 859c75a hpsa: add missing pci_set_master in kdump path > > 132aa22 hpsa: refine the pci enable/disable handling > > > > Cheers, > > Vinson > I am queuing these 4 patches for the 3.16 kernel as well. Cheers, -- Luís > -- > To unsubscribe from this list: send the line "unsubscribe stable" 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
[PATCH 3.16.y-ckt 116/170] scsi: Fix error handling in SCSI_IOCTL_SEND_COMMAND
3.16.7-ckt1 -stable review patch. If anyone has any objections, please let me
know.
--
From: Jan Kara
commit 84ce0f0e94ac97217398b3b69c21c7a62ebeed05 upstream.
When sg_scsi_ioctl() fails to prepare request to submit in
blk_rq_map_kern() we jump to a label where we just end up copying
(luckily zeroed-out) kernel buffer to userspace instead of reporting
error. Fix the problem by jumping to the right label.
CC: Jens Axboe
CC: linux-scsi@vger.kernel.org
Coverity-id: 1226871
Signed-off-by: Jan Kara
Fixed up the, now unused, out label.
Signed-off-by: Jens Axboe
Signed-off-by: Luis Henriques
---
block/scsi_ioctl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index 84ab119b6ffa..de3bd8287d81 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -490,7 +490,7 @@ int sg_scsi_ioctl(struct request_queue *q, struct gendisk
*disk, fmode_t mode,
if (bytes && blk_rq_map_kern(q, rq, buffer, bytes, __GFP_WAIT)) {
err = DRIVER_ERROR << 24;
- goto out;
+ goto error;
}
memset(sense, 0, sizeof(sense));
@@ -499,7 +499,6 @@ int sg_scsi_ioctl(struct request_queue *q, struct gendisk
*disk, fmode_t mode,
blk_execute_rq(q, disk, rq, 0);
-out:
err = rq->errors & 0xff;/* only 8 bit SCSI status */
if (err) {
if (rq->sense_len && rq->sense) {
--
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
[3.16.y-ckt extended stable] Patch "scsi: Fix error handling in SCSI_IOCTL_SEND_COMMAND" has been added to staging queue
This is a note to let you know that I have just added a patch titled
scsi: Fix error handling in SCSI_IOCTL_SEND_COMMAND
to the linux-3.16.y-queue branch of the 3.16.y-ckt extended stable tree
which can be found at:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.16.y-queue
This patch is scheduled to be released in version 3.16.7-ckt1.
If you, or anyone else, feels it should not be added to this tree, please
reply to this email.
For more information about the 3.16.y-ckt tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
Thanks.
-Luis
--
>From 3c8c784d1273b1f13ae894a5807ea7785be54623 Mon Sep 17 00:00:00 2001
From: Jan Kara
Date: Wed, 22 Oct 2014 20:13:39 -0600
Subject: scsi: Fix error handling in SCSI_IOCTL_SEND_COMMAND
commit 84ce0f0e94ac97217398b3b69c21c7a62ebeed05 upstream.
When sg_scsi_ioctl() fails to prepare request to submit in
blk_rq_map_kern() we jump to a label where we just end up copying
(luckily zeroed-out) kernel buffer to userspace instead of reporting
error. Fix the problem by jumping to the right label.
CC: Jens Axboe
CC: linux-scsi@vger.kernel.org
Coverity-id: 1226871
Signed-off-by: Jan Kara
Fixed up the, now unused, out label.
Signed-off-by: Jens Axboe
Signed-off-by: Luis Henriques
---
block/scsi_ioctl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index 84ab119b6ffa..de3bd8287d81 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -490,7 +490,7 @@ int sg_scsi_ioctl(struct request_queue *q, struct gendisk
*disk, fmode_t mode,
if (bytes && blk_rq_map_kern(q, rq, buffer, bytes, __GFP_WAIT)) {
err = DRIVER_ERROR << 24;
- goto out;
+ goto error;
}
memset(sense, 0, sizeof(sense));
@@ -499,7 +499,6 @@ int sg_scsi_ioctl(struct request_queue *q, struct gendisk
*disk, fmode_t mode,
blk_execute_rq(q, disk, rq, 0);
-out:
err = rq->errors & 0xff;/* only 8 bit SCSI status */
if (err) {
if (rq->sense_len && rq->sense) {
--
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] [SCSI] mptfusion: fix compilation warning
Function seq_mpt_print_ioc_summary is invoked only from functions that
depend on CONFIG_PROC_FS. This commit makes this function also depend
on this configuration. Also removes function forward declaration.
It fixes the following warning:
drivers/message/fusion/mptbase.c:6884:13: warning: 'seq_mpt_print_ioc_summary'
defined but not used [-Wunused-function]
Signed-off-by: Luis Henriques
---
drivers/message/fusion/mptbase.c | 65
1 file changed, 32 insertions(+), 33 deletions(-)
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 767ff4d..5cbe611 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -6637,7 +6637,38 @@ procmpt_destroy(void)
/*
* Handles read request from /proc/mpt/summary or /proc/mpt/iocN/summary.
*/
-static void seq_mpt_print_ioc_summary(MPT_ADAPTER *ioc, struct seq_file *m,
int showlan);
+
+static void seq_mpt_print_ioc_summary(MPT_ADAPTER *ioc, struct seq_file *m,
int showlan)
+{
+ char expVer[32];
+
+ mpt_get_fw_exp_ver(expVer, ioc);
+
+ /*
+* Shorter summary of attached ioc's...
+*/
+ seq_printf(m, "%s: %s, %s%08xh%s, Ports=%d, MaxQ=%d",
+ ioc->name,
+ ioc->prod_name,
+ MPT_FW_REV_MAGIC_ID_STRING, /* "FwRev=" or somesuch
*/
+ ioc->facts.FWVersion.Word,
+ expVer,
+ ioc->facts.NumberOfPorts,
+ ioc->req_depth);
+
+ if (showlan && (ioc->pfacts[0].ProtocolFlags &
MPI_PORTFACTS_PROTOCOL_LAN)) {
+ u8 *a = (u8*)&ioc->lan_cnfg_page1.HardwareAddressLow;
+ seq_printf(m, ", LanAddr=%02X:%02X:%02X:%02X:%02X:%02X",
+ a[5], a[4], a[3], a[2], a[1], a[0]);
+ }
+
+ seq_printf(m, ", IRQ=%d", ioc->pci_irq);
+
+ if (!ioc->active)
+ seq_printf(m, " (disabled)");
+
+ seq_putc(m, '\n');
+}
static int mpt_summary_proc_show(struct seq_file *m, void *v)
{
@@ -6881,38 +6912,6 @@ mpt_print_ioc_summary(MPT_ADAPTER *ioc, char *buffer,
int *size, int len, int sh
*size = y;
}
-static void seq_mpt_print_ioc_summary(MPT_ADAPTER *ioc, struct seq_file *m,
int showlan)
-{
- char expVer[32];
-
- mpt_get_fw_exp_ver(expVer, ioc);
-
- /*
-* Shorter summary of attached ioc's...
-*/
- seq_printf(m, "%s: %s, %s%08xh%s, Ports=%d, MaxQ=%d",
- ioc->name,
- ioc->prod_name,
- MPT_FW_REV_MAGIC_ID_STRING, /* "FwRev=" or somesuch
*/
- ioc->facts.FWVersion.Word,
- expVer,
- ioc->facts.NumberOfPorts,
- ioc->req_depth);
-
- if (showlan && (ioc->pfacts[0].ProtocolFlags &
MPI_PORTFACTS_PROTOCOL_LAN)) {
- u8 *a = (u8*)&ioc->lan_cnfg_page1.HardwareAddressLow;
- seq_printf(m, ", LanAddr=%02X:%02X:%02X:%02X:%02X:%02X",
- a[5], a[4], a[3], a[2], a[1], a[0]);
- }
-
- seq_printf(m, ", IRQ=%d", ioc->pci_irq);
-
- if (!ioc->active)
- seq_printf(m, " (disabled)");
-
- seq_putc(m, '\n');
-}
-
/**
* mpt_set_taskmgmt_in_progress_flag - set flags associated with task
management
* @ioc: Pointer to MPT_ADAPTER structure
--
1.8.3.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
[PATCH 74/75] [SCSI] nsp32: use mdelay instead of large udelay constants
3.5.7.19 -stable review patch. If anyone has any objections, please let me
know.
--
From: Arnd Bergmann
commit b497ceb964a80ebada3b9b3cea4261409039e25a upstream.
ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.
Signed-off-by: Arnd Bergmann
Acked-by: GOTO Masanori
Cc: YOKOTA Hiroshi
Cc: "James E.J. Bottomley"
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Luis Henriques
---
drivers/scsi/nsp32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/nsp32.c b/drivers/scsi/nsp32.c
index 62b6168..e705ed3 100644
--- a/drivers/scsi/nsp32.c
+++ b/drivers/scsi/nsp32.c
@@ -2926,7 +2926,7 @@ static void nsp32_do_bus_reset(nsp32_hw_data *data)
* reset SCSI bus
*/
nsp32_write1(base, SCSI_BUS_CONTROL, BUSCTL_RST);
- udelay(RESET_HOLD_TIME);
+ mdelay(RESET_HOLD_TIME / 1000);
nsp32_write1(base, SCSI_BUS_CONTROL, 0);
for(i = 0; i < 5; i++) {
intrdat = nsp32_read2(base, IRQ_STATUS); /* dummy read */
--
1.8.3.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
[ 3.5.y.z extended stable ] Patch "[SCSI] nsp32: use mdelay instead of large udelay constants" has been added to staging queue
This is a note to let you know that I have just added a patch titled
[SCSI] nsp32: use mdelay instead of large udelay constants
to the linux-3.5.y-queue branch of the 3.5.y.z extended stable tree
which can be found at:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.5.y-queue
If you, or anyone else, feels it should not be added to this tree, please
reply to this email.
For more information about the 3.5.y.z tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
Thanks.
-Luis
--
>From 48cf7e8bdb6559da3cd5801f0b79426c0db1e546 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann
Date: Thu, 14 Mar 2013 15:21:36 +0100
Subject: [PATCH] [SCSI] nsp32: use mdelay instead of large udelay constants
commit b497ceb964a80ebada3b9b3cea4261409039e25a upstream.
ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.
Signed-off-by: Arnd Bergmann
Acked-by: GOTO Masanori
Cc: YOKOTA Hiroshi
Cc: "James E.J. Bottomley"
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Luis Henriques
---
drivers/scsi/nsp32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/nsp32.c b/drivers/scsi/nsp32.c
index 62b6168..e705ed3 100644
--- a/drivers/scsi/nsp32.c
+++ b/drivers/scsi/nsp32.c
@@ -2926,7 +2926,7 @@ static void nsp32_do_bus_reset(nsp32_hw_data *data)
* reset SCSI bus
*/
nsp32_write1(base, SCSI_BUS_CONTROL, BUSCTL_RST);
- udelay(RESET_HOLD_TIME);
+ mdelay(RESET_HOLD_TIME / 1000);
nsp32_write1(base, SCSI_BUS_CONTROL, 0);
for(i = 0; i < 5; i++) {
intrdat = nsp32_read2(base, IRQ_STATUS); /* dummy read */
--
1.8.3.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: [stable] [SCSI] Fix incorrect memset in bnx2fc_parse_fcp_rsp
Ben Hutchings writes: > This looks like a candidate for stable: > > commit 16da05b1158d1bcb31656e636a8736a663b1cf1f > Author: Andi Kleen > Date: Mon Sep 3 20:50:30 2012 +0200 > > [SCSI] Fix incorrect memset in bnx2fc_parse_fcp_rsp > > Typically this sort of bug can result in leaking kernel memory to > userland, which is a security issue, but I don't know whether that's > true in this case. > > Ben. Thanks, I'm queuing it for the 3.5 kernel. Cheers, -- Luis signature.asc Description: PGP signature
