Re: [Open-FCoE] [PATCH] fc: ensure scan_work isn't active when freeing fc_rport
On Mon, Jun 02, 2014 at 04:22:50PM -0700, Vasu Dev wrote: On Fri, 2014-05-30 at 10:59 -0400, Neil Horman wrote: debugfs caught this: WARNING: at lib/debugobjects.c:260 debug_print_object+0x83/0xa0() ODEBUG: free active (active state 0) object type: work_struct hint: fc_scsi_scan_rport+0x0/0xd0 [scsi_transport_fc] CPU: 1 PID: 184 Comm: kworker/1:1 Tainted: GW -- 3.10.0-123.el7.x86_64.debug #1 Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 Workqueue: fc_wq_5 fc_rport_final_delete [scsi_transport_fc] Call Trace: [8169efec] dump_stack+0x19/0x1b [8106cbd1] warn_slowpath_common+0x61/0x80 [8106cc4c] warn_slowpath_fmt+0x5c/0x80 [8133e003] debug_print_object+0x83/0xa0 [a04e2f40] ? fc_parse_wwn+0x100/0x100 [8133f23b] debug_check_no_obj_freed+0x22b/0x270 [a04e127e] ? fc_rport_dev_release+0x1e/0x30 [811db3e9] kfree+0xd9/0x2d0 [a04e127e] fc_rport_dev_release+0x1e/0x30 [81428032] device_release+0x32/0xa0 [8132701e] kobject_release+0x7e/0x1b0 [81326ed8] kobject_put+0x28/0x60 [81428397] put_device+0x17/0x20 [a04e5025] fc_rport_final_delete+0x165/0x210 [810959b0] process_one_work+0x220/0x710 [81095944] ? process_one_work+0x1b4/0x710 [81095fbb] worker_thread+0x11b/0x3a0 [81095ea0] ? process_one_work+0x710/0x710 [8109e0cd] kthread+0xed/0x100 [8109dfe0] ? insert_kthread_work+0x80/0x80 [816b2fec] ret_from_fork+0x7c/0xb0 [8109dfe0] ? insert_kthread_work+0x80/0x80 Seems to be because the scan_work work_struct might be active when the housing fc_rport struct gets freed. Ensure that we cancel it prior to freeing the rport Signed-off-by: Neil Horman nhor...@tuxdriver.com CC: linux-scsi@vger.kernel.org CC: Robert Love robert.w.l...@intel.com CC: Vasu Dev vasu@intel.com --- drivers/scsi/scsi_transport_fc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c index 4628fd5..5bd552c 100644 --- a/drivers/scsi/scsi_transport_fc.c +++ b/drivers/scsi/scsi_transport_fc.c @@ -2548,6 +2548,7 @@ fc_rport_final_delete(struct work_struct *work) fc_flush_devloss(shost); if (!cancel_delayed_work(rport-dev_loss_work)) fc_flush_devloss(shost); + cancel_work_sync(rport-scan_work); Make sense to ensure pending work canceled, adding James Smart for his ACK as transport FC class author. Reviewed-by: Vasu Dev vasu@intel.com spin_lock_irqsave(shost-host_lock, flags); rport-flags = ~FC_RPORT_DEVLOSS_PENDING; } Ping James, I beleve Christoph is still waiting on a review from you here. Neil -- 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: [Open-FCoE] [PATCH] fc: ensure scan_work isn't active when freeing fc_rport
On Mon, Jun 09, 2014 at 03:16:37PM -0400, Neil Horman wrote: Given fcoe is quite mature now and its patches volume is very low, so getting its kernel patches directly to scsi subsystem should work fine and should be okay with James or Christophs to pull into scsi subsystem directly once I've my non-author signoff ACK there as described in this announcement at http://marc.info/?l=linux-scsim=140050839729415w=2 If no alternate suggestion or objection to this then I'll formally announce this on fcoe mailing list. However for any huges patches series bomb or RFCs, I'll request fcoe developers to send patches against scsi tree at fcoe devel list first and then if needed I can roll them up. Thanks, Vasu Copy that Vasu, Christoph, is that ok with you? That's fine with me. It would help greatly if you could make sure all the paches get a review or two very quickly so I can just pick them up immediately after reviewing them. -- 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: [Open-FCoE] [PATCH] fc: ensure scan_work isn't active when freeing fc_rport
On Tue, Jun 10, 2014 at 04:38:41AM -0700, Christoph Hellwig wrote: On Mon, Jun 09, 2014 at 03:16:37PM -0400, Neil Horman wrote: Given fcoe is quite mature now and its patches volume is very low, so getting its kernel patches directly to scsi subsystem should work fine and should be okay with James or Christophs to pull into scsi subsystem directly once I've my non-author signoff ACK there as described in this announcement at http://marc.info/?l=linux-scsim=140050839729415w=2 If no alternate suggestion or objection to this then I'll formally announce this on fcoe mailing list. However for any huges patches series bomb or RFCs, I'll request fcoe developers to send patches against scsi tree at fcoe devel list first and then if needed I can roll them up. Thanks, Vasu Copy that Vasu, Christoph, is that ok with you? That's fine with me. It would help greatly if you could make sure all the paches get a review or two very quickly so I can just pick them up immediately after reviewing them. Roger that, Vasu has already acked this. I thought there was a second, but I'm not sure, my mailbox is a bit messed up at the moment. Sorry for not cc-ing you on this sooner, I thought it was going to go through the FCoE tree initially Best Neil -- 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: [Open-FCoE] [PATCH] fc: ensure scan_work isn't active when freeing fc_rport
On Fri, 2014-06-06 at 16:54 -0400, Neil Horman wrote: On Mon, Jun 02, 2014 at 04:22:50PM -0700, Vasu Dev wrote: On Fri, 2014-05-30 at 10:59 -0400, Neil Horman wrote: debugfs caught this: WARNING: at lib/debugobjects.c:260 debug_print_object+0x83/0xa0() ODEBUG: free active (active state 0) object type: work_struct hint: fc_scsi_scan_rport+0x0/0xd0 [scsi_transport_fc] CPU: 1 PID: 184 Comm: kworker/1:1 Tainted: GW -- 3.10.0-123.el7.x86_64.debug #1 Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 Workqueue: fc_wq_5 fc_rport_final_delete [scsi_transport_fc] Call Trace: [8169efec] dump_stack+0x19/0x1b [8106cbd1] warn_slowpath_common+0x61/0x80 [8106cc4c] warn_slowpath_fmt+0x5c/0x80 [8133e003] debug_print_object+0x83/0xa0 [a04e2f40] ? fc_parse_wwn+0x100/0x100 [8133f23b] debug_check_no_obj_freed+0x22b/0x270 [a04e127e] ? fc_rport_dev_release+0x1e/0x30 [811db3e9] kfree+0xd9/0x2d0 [a04e127e] fc_rport_dev_release+0x1e/0x30 [81428032] device_release+0x32/0xa0 [8132701e] kobject_release+0x7e/0x1b0 [81326ed8] kobject_put+0x28/0x60 [81428397] put_device+0x17/0x20 [a04e5025] fc_rport_final_delete+0x165/0x210 [810959b0] process_one_work+0x220/0x710 [81095944] ? process_one_work+0x1b4/0x710 [81095fbb] worker_thread+0x11b/0x3a0 [81095ea0] ? process_one_work+0x710/0x710 [8109e0cd] kthread+0xed/0x100 [8109dfe0] ? insert_kthread_work+0x80/0x80 [816b2fec] ret_from_fork+0x7c/0xb0 [8109dfe0] ? insert_kthread_work+0x80/0x80 Seems to be because the scan_work work_struct might be active when the housing fc_rport struct gets freed. Ensure that we cancel it prior to freeing the rport Signed-off-by: Neil Horman nhor...@tuxdriver.com CC: linux-scsi@vger.kernel.org CC: Robert Love robert.w.l...@intel.com CC: Vasu Dev vasu@intel.com --- drivers/scsi/scsi_transport_fc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c index 4628fd5..5bd552c 100644 --- a/drivers/scsi/scsi_transport_fc.c +++ b/drivers/scsi/scsi_transport_fc.c @@ -2548,6 +2548,7 @@ fc_rport_final_delete(struct work_struct *work) fc_flush_devloss(shost); if (!cancel_delayed_work(rport-dev_loss_work)) fc_flush_devloss(shost); + cancel_work_sync(rport-scan_work); Make sense to ensure pending work canceled, adding James Smart for his ACK as transport FC class author. Reviewed-by: Vasu Dev vasu@intel.com Ping on this, Something just occured to me. I was thinking (perhaps erroneously) that this would go through the FCoE tree, but I don't see that you've setup a tree yet vasu (and Rob's has been idle for 6 months). Whats the plan for this (and future) fcoe patchs. Will you have a tree, or will we send this through Christophs new scsi tree perhaps? Thanks Neil for bringing this, I and Rob also had off list discussion on this just last week. Given fcoe is quite mature now and its patches volume is very low, so getting its kernel patches directly to scsi subsystem should work fine and should be okay with James or Christophs to pull into scsi subsystem directly once I've my non-author signoff ACK there as described in this announcement at http://marc.info/?l=linux-scsim=140050839729415w=2 If no alternate suggestion or objection to this then I'll formally announce this on fcoe mailing list. However for any huges patches series bomb or RFCs, I'll request fcoe developers to send patches against scsi tree at fcoe devel list first and then if needed I can roll them up. Thanks, Vasu -- 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: [Open-FCoE] [PATCH] fc: ensure scan_work isn't active when freeing fc_rport
On Mon, Jun 09, 2014 at 11:09:43AM -0700, Vasu Dev wrote: On Fri, 2014-06-06 at 16:54 -0400, Neil Horman wrote: On Mon, Jun 02, 2014 at 04:22:50PM -0700, Vasu Dev wrote: On Fri, 2014-05-30 at 10:59 -0400, Neil Horman wrote: debugfs caught this: WARNING: at lib/debugobjects.c:260 debug_print_object+0x83/0xa0() ODEBUG: free active (active state 0) object type: work_struct hint: fc_scsi_scan_rport+0x0/0xd0 [scsi_transport_fc] CPU: 1 PID: 184 Comm: kworker/1:1 Tainted: GW -- 3.10.0-123.el7.x86_64.debug #1 Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 Workqueue: fc_wq_5 fc_rport_final_delete [scsi_transport_fc] Call Trace: [8169efec] dump_stack+0x19/0x1b [8106cbd1] warn_slowpath_common+0x61/0x80 [8106cc4c] warn_slowpath_fmt+0x5c/0x80 [8133e003] debug_print_object+0x83/0xa0 [a04e2f40] ? fc_parse_wwn+0x100/0x100 [8133f23b] debug_check_no_obj_freed+0x22b/0x270 [a04e127e] ? fc_rport_dev_release+0x1e/0x30 [811db3e9] kfree+0xd9/0x2d0 [a04e127e] fc_rport_dev_release+0x1e/0x30 [81428032] device_release+0x32/0xa0 [8132701e] kobject_release+0x7e/0x1b0 [81326ed8] kobject_put+0x28/0x60 [81428397] put_device+0x17/0x20 [a04e5025] fc_rport_final_delete+0x165/0x210 [810959b0] process_one_work+0x220/0x710 [81095944] ? process_one_work+0x1b4/0x710 [81095fbb] worker_thread+0x11b/0x3a0 [81095ea0] ? process_one_work+0x710/0x710 [8109e0cd] kthread+0xed/0x100 [8109dfe0] ? insert_kthread_work+0x80/0x80 [816b2fec] ret_from_fork+0x7c/0xb0 [8109dfe0] ? insert_kthread_work+0x80/0x80 Seems to be because the scan_work work_struct might be active when the housing fc_rport struct gets freed. Ensure that we cancel it prior to freeing the rport Signed-off-by: Neil Horman nhor...@tuxdriver.com CC: linux-scsi@vger.kernel.org CC: Robert Love robert.w.l...@intel.com CC: Vasu Dev vasu@intel.com --- drivers/scsi/scsi_transport_fc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c index 4628fd5..5bd552c 100644 --- a/drivers/scsi/scsi_transport_fc.c +++ b/drivers/scsi/scsi_transport_fc.c @@ -2548,6 +2548,7 @@ fc_rport_final_delete(struct work_struct *work) fc_flush_devloss(shost); if (!cancel_delayed_work(rport-dev_loss_work)) fc_flush_devloss(shost); + cancel_work_sync(rport-scan_work); Make sense to ensure pending work canceled, adding James Smart for his ACK as transport FC class author. Reviewed-by: Vasu Dev vasu@intel.com Ping on this, Something just occured to me. I was thinking (perhaps erroneously) that this would go through the FCoE tree, but I don't see that you've setup a tree yet vasu (and Rob's has been idle for 6 months). Whats the plan for this (and future) fcoe patchs. Will you have a tree, or will we send this through Christophs new scsi tree perhaps? Thanks Neil for bringing this, I and Rob also had off list discussion on this just last week. Given fcoe is quite mature now and its patches volume is very low, so getting its kernel patches directly to scsi subsystem should work fine and should be okay with James or Christophs to pull into scsi subsystem directly once I've my non-author signoff ACK there as described in this announcement at http://marc.info/?l=linux-scsim=140050839729415w=2 If no alternate suggestion or objection to this then I'll formally announce this on fcoe mailing list. However for any huges patches series bomb or RFCs, I'll request fcoe developers to send patches against scsi tree at fcoe devel list first and then if needed I can roll them up. Thanks, Vasu Copy that Vasu, Christoph, is that ok with you? Neil -- 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: [Open-FCoE] [PATCH] fc: ensure scan_work isn't active when freeing fc_rport
On Mon, Jun 02, 2014 at 04:22:50PM -0700, Vasu Dev wrote: On Fri, 2014-05-30 at 10:59 -0400, Neil Horman wrote: debugfs caught this: WARNING: at lib/debugobjects.c:260 debug_print_object+0x83/0xa0() ODEBUG: free active (active state 0) object type: work_struct hint: fc_scsi_scan_rport+0x0/0xd0 [scsi_transport_fc] CPU: 1 PID: 184 Comm: kworker/1:1 Tainted: GW -- 3.10.0-123.el7.x86_64.debug #1 Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 Workqueue: fc_wq_5 fc_rport_final_delete [scsi_transport_fc] Call Trace: [8169efec] dump_stack+0x19/0x1b [8106cbd1] warn_slowpath_common+0x61/0x80 [8106cc4c] warn_slowpath_fmt+0x5c/0x80 [8133e003] debug_print_object+0x83/0xa0 [a04e2f40] ? fc_parse_wwn+0x100/0x100 [8133f23b] debug_check_no_obj_freed+0x22b/0x270 [a04e127e] ? fc_rport_dev_release+0x1e/0x30 [811db3e9] kfree+0xd9/0x2d0 [a04e127e] fc_rport_dev_release+0x1e/0x30 [81428032] device_release+0x32/0xa0 [8132701e] kobject_release+0x7e/0x1b0 [81326ed8] kobject_put+0x28/0x60 [81428397] put_device+0x17/0x20 [a04e5025] fc_rport_final_delete+0x165/0x210 [810959b0] process_one_work+0x220/0x710 [81095944] ? process_one_work+0x1b4/0x710 [81095fbb] worker_thread+0x11b/0x3a0 [81095ea0] ? process_one_work+0x710/0x710 [8109e0cd] kthread+0xed/0x100 [8109dfe0] ? insert_kthread_work+0x80/0x80 [816b2fec] ret_from_fork+0x7c/0xb0 [8109dfe0] ? insert_kthread_work+0x80/0x80 Seems to be because the scan_work work_struct might be active when the housing fc_rport struct gets freed. Ensure that we cancel it prior to freeing the rport Signed-off-by: Neil Horman nhor...@tuxdriver.com CC: linux-scsi@vger.kernel.org CC: Robert Love robert.w.l...@intel.com CC: Vasu Dev vasu@intel.com --- drivers/scsi/scsi_transport_fc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c index 4628fd5..5bd552c 100644 --- a/drivers/scsi/scsi_transport_fc.c +++ b/drivers/scsi/scsi_transport_fc.c @@ -2548,6 +2548,7 @@ fc_rport_final_delete(struct work_struct *work) fc_flush_devloss(shost); if (!cancel_delayed_work(rport-dev_loss_work)) fc_flush_devloss(shost); + cancel_work_sync(rport-scan_work); Make sense to ensure pending work canceled, adding James Smart for his ACK as transport FC class author. Reviewed-by: Vasu Dev vasu@intel.com Ping on this, Something just occured to me. I was thinking (perhaps erroneously) that this would go through the FCoE tree, but I don't see that you've setup a tree yet vasu (and Rob's has been idle for 6 months). Whats the plan for this (and future) fcoe patchs. Will you have a tree, or will we send this through Christophs new scsi tree perhaps? Neil spin_lock_irqsave(shost-host_lock, flags); rport-flags = ~FC_RPORT_DEVLOSS_PENDING; } -- 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: [Open-FCoE] [PATCH] fc: ensure scan_work isn't active when freeing fc_rport
On Fri, 2014-05-30 at 10:59 -0400, Neil Horman wrote: debugfs caught this: WARNING: at lib/debugobjects.c:260 debug_print_object+0x83/0xa0() ODEBUG: free active (active state 0) object type: work_struct hint: fc_scsi_scan_rport+0x0/0xd0 [scsi_transport_fc] CPU: 1 PID: 184 Comm: kworker/1:1 Tainted: GW -- 3.10.0-123.el7.x86_64.debug #1 Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 Workqueue: fc_wq_5 fc_rport_final_delete [scsi_transport_fc] Call Trace: [8169efec] dump_stack+0x19/0x1b [8106cbd1] warn_slowpath_common+0x61/0x80 [8106cc4c] warn_slowpath_fmt+0x5c/0x80 [8133e003] debug_print_object+0x83/0xa0 [a04e2f40] ? fc_parse_wwn+0x100/0x100 [8133f23b] debug_check_no_obj_freed+0x22b/0x270 [a04e127e] ? fc_rport_dev_release+0x1e/0x30 [811db3e9] kfree+0xd9/0x2d0 [a04e127e] fc_rport_dev_release+0x1e/0x30 [81428032] device_release+0x32/0xa0 [8132701e] kobject_release+0x7e/0x1b0 [81326ed8] kobject_put+0x28/0x60 [81428397] put_device+0x17/0x20 [a04e5025] fc_rport_final_delete+0x165/0x210 [810959b0] process_one_work+0x220/0x710 [81095944] ? process_one_work+0x1b4/0x710 [81095fbb] worker_thread+0x11b/0x3a0 [81095ea0] ? process_one_work+0x710/0x710 [8109e0cd] kthread+0xed/0x100 [8109dfe0] ? insert_kthread_work+0x80/0x80 [816b2fec] ret_from_fork+0x7c/0xb0 [8109dfe0] ? insert_kthread_work+0x80/0x80 Seems to be because the scan_work work_struct might be active when the housing fc_rport struct gets freed. Ensure that we cancel it prior to freeing the rport Signed-off-by: Neil Horman nhor...@tuxdriver.com CC: linux-scsi@vger.kernel.org CC: Robert Love robert.w.l...@intel.com CC: Vasu Dev vasu@intel.com --- drivers/scsi/scsi_transport_fc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c index 4628fd5..5bd552c 100644 --- a/drivers/scsi/scsi_transport_fc.c +++ b/drivers/scsi/scsi_transport_fc.c @@ -2548,6 +2548,7 @@ fc_rport_final_delete(struct work_struct *work) fc_flush_devloss(shost); if (!cancel_delayed_work(rport-dev_loss_work)) fc_flush_devloss(shost); + cancel_work_sync(rport-scan_work); Make sense to ensure pending work canceled, adding James Smart for his ACK as transport FC class author. Reviewed-by: Vasu Dev vasu@intel.com spin_lock_irqsave(shost-host_lock, flags); rport-flags = ~FC_RPORT_DEVLOSS_PENDING; } -- 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
