From: Yijing Wang <wangyijing@huawei.com> To: <jejb@linux.vnet.ibm.com>, <martin.petersen@oracle.com> Cc: <chenqilin2@huawei.com>, <hare@suse.com>, <linux-scsi@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <chenxiang66@hisilicon.com>, <huangdaode@hisilicon.com>, <wangkefeng.wang@huawei.com>, <zhaohongjiang@huawei.com>, <dingtianhong@huawei.com>, <guohanjun@huawei.com>, <john.garry@huawei.com>, <fangwei1@huawei.com>, <yanaijie@huawei.com>, <hch@lst.de>, <dan.j.williams@intel.com>, Yijing Wang <wangyijing@huawei.com> Subject: [PATCH 0/2] Enhance libsas hotplug feature Date: Sat, 20 May 2017 14:39:18 +0800 [thread overview] Message-ID: <1495262360-40135-1-git-send-email-wangyijing@huawei.com> (raw) Now the libsas hotplug has some issues, Dan Williams report a similar bug here before https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg39187.html The issues we have found 1. if LLDD burst reports lots of phy-up/phy-down sas events, some events may lost because a same sas events is pending now, finally libsas topo may different the hardware. 2. receive a phy down sas event, libsas call sas_deform_port to remove devices, it would first delete the sas port, then put a destruction discovery event in a new work, and queue it at the tail of workqueue, once the sas port be deleted, its children device will be deleted too, when the destruction work start, it will found the target device has been removed, and report a sysfs warnning. 3. since a hotplug process will be devided into several works, if a phy up sas event insert into phydown works, like destruction work ---> PORTE_BYTES_DMAED (sas_form_port) ---->PHYE_LOSS_OF_SIGNAL the hot remove flow would broken by PORTE_BYTES_DMAED event, it's not we expected, and issues would occur. The first patch fix the sas events lost, and the second one introudce wait-complete to fix the hotplug order issues. Yijing Wang (2): libsas: Don't process sas events in static works libsas: Enhance libsas hotplug drivers/scsi/libsas/sas_discover.c | 58 +++++++++++++++++------- drivers/scsi/libsas/sas_event.c | 90 ++++++++++++++++++++++++++------------ drivers/scsi/libsas/sas_expander.c | 9 +++- drivers/scsi/libsas/sas_init.c | 37 +++++++++++++--- drivers/scsi/libsas/sas_internal.h | 53 ++++++++++++++++++++++ drivers/scsi/libsas/sas_phy.c | 45 ++++--------------- drivers/scsi/libsas/sas_port.c | 22 +++++----- include/scsi/libsas.h | 21 +++++---- 8 files changed, 230 insertions(+), 105 deletions(-) -- 2.5.0
WARNING: multiple messages have this Message-ID (diff)
From: Yijing Wang <wangyijing@huawei.com> To: jejb@linux.vnet.ibm.com, martin.petersen@oracle.com Cc: chenqilin2@huawei.com, hare@suse.com, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, chenxiang66@hisilicon.com, huangdaode@hisilicon.com, wangkefeng.wang@huawei.com, zhaohongjiang@huawei.com, dingtianhong@huawei.com, guohanjun@huawei.com, john.garry@huawei.com, fangwei1@huawei.com, yanaijie@huawei.com, hch@lst.de, dan.j.williams@intel.com, Yijing Wang <wangyijing@huawei.com> Subject: [PATCH 0/2] Enhance libsas hotplug feature Date: Sat, 20 May 2017 14:39:18 +0800 [thread overview] Message-ID: <1495262360-40135-1-git-send-email-wangyijing@huawei.com> (raw) Now the libsas hotplug has some issues, Dan Williams report a similar bug here before https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg39187.html The issues we have found 1. if LLDD burst reports lots of phy-up/phy-down sas events, some events may lost because a same sas events is pending now, finally libsas topo may different the hardware. 2. receive a phy down sas event, libsas call sas_deform_port to remove devices, it would first delete the sas port, then put a destruction discovery event in a new work, and queue it at the tail of workqueue, once the sas port be deleted, its children device will be deleted too, when the destruction work start, it will found the target device has been removed, and report a sysfs warnning. 3. since a hotplug process will be devided into several works, if a phy up sas event insert into phydown works, like destruction work ---> PORTE_BYTES_DMAED (sas_form_port) ---->PHYE_LOSS_OF_SIGNAL the hot remove flow would broken by PORTE_BYTES_DMAED event, it's not we expected, and issues would occur. The first patch fix the sas events lost, and the second one introudce wait-complete to fix the hotplug order issues. Yijing Wang (2): libsas: Don't process sas events in static works libsas: Enhance libsas hotplug drivers/scsi/libsas/sas_discover.c | 58 +++++++++++++++++------- drivers/scsi/libsas/sas_event.c | 90 ++++++++++++++++++++++++++------------ drivers/scsi/libsas/sas_expander.c | 9 +++- drivers/scsi/libsas/sas_init.c | 37 +++++++++++++--- drivers/scsi/libsas/sas_internal.h | 53 ++++++++++++++++++++++ drivers/scsi/libsas/sas_phy.c | 45 ++++--------------- drivers/scsi/libsas/sas_port.c | 22 +++++----- include/scsi/libsas.h | 21 +++++---- 8 files changed, 230 insertions(+), 105 deletions(-) -- 2.5.0
next reply other threads:[~2017-05-20 6:36 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-05-20 6:39 Yijing Wang [this message] 2017-05-20 6:39 ` [PATCH 0/2] Enhance libsas hotplug feature Yijing Wang 2017-05-20 6:39 ` [PATCH 1/2] libsas: Don't process sas events in static works Yijing Wang 2017-05-20 6:39 ` Yijing Wang 2017-05-21 3:44 ` Dan Williams 2017-05-22 5:54 ` wangyijing 2017-05-22 5:54 ` wangyijing 2017-05-22 9:28 ` John Garry 2017-05-22 9:28 ` John Garry 2017-05-23 6:39 ` wangyijing 2017-05-23 6:39 ` wangyijing 2017-05-20 6:39 ` [PATCH 2/2] libsas: Enhance libsas hotplug Yijing Wang 2017-05-20 6:39 ` Yijing Wang 2017-05-25 9:04 ` John Garry 2017-05-25 9:04 ` John Garry 2017-05-25 12:31 ` wangyijing 2017-05-25 12:31 ` wangyijing
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1495262360-40135-1-git-send-email-wangyijing@huawei.com \ --to=wangyijing@huawei.com \ --cc=chenqilin2@huawei.com \ --cc=chenxiang66@hisilicon.com \ --cc=dan.j.williams@intel.com \ --cc=dingtianhong@huawei.com \ --cc=fangwei1@huawei.com \ --cc=guohanjun@huawei.com \ --cc=hare@suse.com \ --cc=hch@lst.de \ --cc=huangdaode@hisilicon.com \ --cc=jejb@linux.vnet.ibm.com \ --cc=john.garry@huawei.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-scsi@vger.kernel.org \ --cc=martin.petersen@oracle.com \ --cc=wangkefeng.wang@huawei.com \ --cc=yanaijie@huawei.com \ --cc=zhaohongjiang@huawei.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.