From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932673AbdC2LRO (ORCPT ); Wed, 29 Mar 2017 07:17:14 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:4847 "EHLO dggrg02-dlp.huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S932596AbdC2LQN (ORCPT ); Wed, 29 Mar 2017 07:16:13 -0400 Subject: Re: [PATCH 1/2] scsi: sas: flush destruct workqueue on device unregister To: Johannes Thumshirn , "Martin K . Petersen" References: <9580eaf323f5da17dcace9e32b22a1df4099961d.1490775958.git.jthumshirn@suse.de> CC: Tejun Heo , James Bottomley , "Dan Williams" , Jack Wang , Hannes Reinecke , Linux SCSI Mailinglist , Linux Kernel Mailinglist From: John Garry Message-ID: <02778435-6c67-0ac9-2faa-03ebb7934477@huawei.com> Date: Wed, 29 Mar 2017 12:15:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <9580eaf323f5da17dcace9e32b22a1df4099961d.1490775958.git.jthumshirn@suse.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.203.181.155] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.58DB9769.0067,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ae265ac05b8a9891a205b800e4972a9a Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29/03/2017 10:41, Johannes Thumshirn wrote: > In the advent of an SAS device unregister we have to wait for all destruct > works to be done to not accidently delay deletion of a SAS rphy or it's > children to the point when we're removing the SCSI or SAS hosts. > > Signed-off-by: Johannes Thumshirn > --- > drivers/scsi/libsas/sas_discover.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/scsi/libsas/sas_discover.c b/drivers/scsi/libsas/sas_discover.c > index 60de662..75b18f1 100644 > --- a/drivers/scsi/libsas/sas_discover.c > +++ b/drivers/scsi/libsas/sas_discover.c > @@ -382,9 +382,13 @@ void sas_unregister_dev(struct asd_sas_port *port, struct domain_device *dev) > } > > if (!test_and_set_bit(SAS_DEV_DESTROY, &dev->state)) { > + struct sas_discovery *disc = &dev->port->disc; > + struct sas_work *sw = &disc->disc_work[DISCE_DESTRUCT].work; > + > sas_rphy_unlink(dev->rphy); > list_move_tail(&dev->disco_list_node, &port->destroy_list); > sas_discover_event(dev->port, DISCE_DESTRUCT); > + flush_work(&sw->work); I quickly tested plugging out the expander and we never get past this call to flush - a hang results: root@(none)$ [ 243.357088] INFO: task kworker/u32:1:106 blocked for more than 120 seconds. [ 243.364030] Not tainted 4.11.0-rc1-13687-g2562e6a-dirty #1388 [ 243.370282] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 243.378086] kworker/u32:1 D 0 106 2 0x00000000 [ 243.383566] Workqueue: scsi_wq_0 sas_phye_loss_of_signal [ 243.388863] Call trace: [ 243.391314] [] __switch_to+0xa4/0xb0 [ 243.396442] [] __schedule+0x1b4/0x5d0 [ 243.401654] [] schedule+0x38/0x9c [ 243.406520] [] schedule_timeout+0x194/0x294 [ 243.412249] [] wait_for_common+0xb0/0x144 [ 243.417805] [] wait_for_completion+0x14/0x1c [ 243.423623] [] flush_work+0xe0/0x1a8 [ 243.428747] [] sas_unregister_dev+0xf8/0x110 [ 243.434563] [] sas_unregister_domain_devices+0x4c/0xc8 [ 243.441242] [] sas_deform_port+0x14c/0x15c [ 243.446886] [] sas_phye_loss_of_signal+0x48/0x54 [ 243.453048] [] process_one_work+0x138/0x2d8 [ 243.458776] [] worker_thread+0x58/0x424 [ 243.464161] [] kthread+0xf4/0x120 [ 243.469024] [] ret_from_fork+0x10/0x50 [ 364.189094] INFO: task kworker/u32:1:106 blocked for more than 120 seconds. [ 364.196035] Not tainted 4.11.0-rc1-13687-g2562e6a-dirty #1388 [ 364.202281] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 364.210085] kworker/u32:1 D 0 106 2 0x00000000 [ 364.215558] Workqueue: scsi_wq_0 sas_phye_loss_of_signal [ 364.220855] Call trace: [ 364.223303] [] __switch_to+0xa4/0xb0 [ 364.228428] [] __schedule+0x1b4/0x5d0 [ 364.233640] [] schedule+0x38/0x9c [ 364.238506] [] schedule_timeout+0x194/0x294 [ 364.244237] [] wait_for_common+0xb0/0x144 [ 364.249793] [] wait_for_completion+0x14/0x1c [ 364.255610] [] flush_work+0xe0/0x1a8 [ 364.260736] [] sas_unregister_dev+0xf8/0x110 [ 364.266551] [] sas_unregister_domain_devices+0x4c/0xc8 [ 364.273230] [] sas_deform_port+0x14c/0x15c [ 364.278872] [] sas_phye_loss_of_signal+0x48/0x54 [ 364.285034] [] process_one_work+0x138/0x2d8 [ 364.290763] [] worker_thread+0x58/0x424 [ 364.296147] [] kthread+0xf4/0x120 [ 364.301013] [] ret_from_fork+0x10/0x50 Is the issue that we are trying to flush the queue when we are working in the same queue context? Thanks, John > } > } > >