From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Horman Subject: Re: [PATCH] fc: ensure scan_work isn't active when freeing fc_rport Date: Fri, 6 Jun 2014 16:54:09 -0400 Message-ID: <20140606205409.GD2543@hmsreliant.think-freely.org> References: <1401461974-7879-1-git-send-email-nhorman@tuxdriver.com> <1401751370.5752.5.camel@vi-devel> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1401751370.5752.5.camel@vi-devel> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fcoe-devel-bounces-s9riP+hp16TNLxjTenLetw@public.gmane.org Sender: fcoe-devel-bounces-s9riP+hp16TNLxjTenLetw@public.gmane.org To: Vasu Dev Cc: fcoe-devel-s9riP+hp16TNLxjTenLetw@public.gmane.org, linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-scsi@vger.kernel.org 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: G W > > -------------- 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: > > [] dump_stack+0x19/0x1b > > [] warn_slowpath_common+0x61/0x80 > > [] warn_slowpath_fmt+0x5c/0x80 > > [] debug_print_object+0x83/0xa0 > > [] ? fc_parse_wwn+0x100/0x100 > > > > [] debug_check_no_obj_freed+0x22b/0x270 > > [] ? fc_rport_dev_release+0x1e/0x30 > > [] kfree+0xd9/0x2d0 > > [] fc_rport_dev_release+0x1e/0x30 > > [] device_release+0x32/0xa0 > > [] kobject_release+0x7e/0x1b0 > > [] kobject_put+0x28/0x60 > > [] put_device+0x17/0x20 > > [] fc_rport_final_delete+0x165/0x210 > > [] process_one_work+0x220/0x710 > > [] ? process_one_work+0x1b4/0x710 > > [] worker_thread+0x11b/0x3a0 > > [] ? process_one_work+0x710/0x710 > > [] kthread+0xed/0x100 > > [] ? insert_kthread_work+0x80/0x80 > > [] ret_from_fork+0x7c/0xb0 > > [] ? 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 > > CC: linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > > CC: Robert Love > > CC: Vasu Dev > > --- > > 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 > 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; > > } > > >