Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752935AbeABLGb (ORCPT + 1 other); Tue, 2 Jan 2018 06:06:31 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:3257 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751602AbeABLGa (ORCPT ); Tue, 2 Jan 2018 06:06:30 -0500 Subject: Re: [PATCH v5 0/7] Enhance libsas hotplug feature To: , References: <20171208094210.24887-1-yanaijie@huawei.com> CC: Jason Yan , , , , , , , , , , , From: John Garry Message-ID: <8f6e3763-2b04-23e8-f1ec-8ed3c58f55d3@huawei.com> Date: Tue, 2 Jan 2018 11:06:00 +0000 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: <20171208094210.24887-1-yanaijie@huawei.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.227.238] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 08/12/2017 09:42, Jason Yan wrote: > 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 > Hi Martin, James, At this point we feel that we have a decent solution to the long-standing libsas hotplug issues. Hannes has kindly reviewed the series. Can you let us know what else you require for acceptance? More independent review or testing? Thanks, John > 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. > > v4->v5: -process only one expander's revalidation in sas_ex_revalidate_domain() > -notify event PORTE_BROADCAST_RCVD in sas_enable_revalidation() > v3->v4: -use dynamic alloced work and support shutting down the phy if active event reached the threshold > -use flush_workqueue instead of wait-completion to process discover events synchronously > -direct call probe and destruct function > v2->v3: some code improvements suggested by Johannes and John, > split v2 patch 2 into several small pathes. > v1->v2: some code improvements suggested by John Garry > > Jason Yan (7): > scsi: libsas: Use dynamic alloced work to avoid sas event lost > scsi: libsas: shut down the PHY if events reached the threshold > scsi: libsas: make the event threshold configurable > scsi: libsas: Use new workqueue to run sas event and disco event > scsi: libsas: use flush_workqueue to process disco events > synchronously > scsi: libsas: direct call probe and destruct > scsi: libsas: notify event PORTE_BROADCAST_RCVD in > sas_enable_revalidation() > > drivers/scsi/hisi_sas/hisi_sas_main.c | 6 ++ > drivers/scsi/libsas/sas_ata.c | 1 - > drivers/scsi/libsas/sas_discover.c | 34 ++++++----- > drivers/scsi/libsas/sas_event.c | 86 ++++++++++++++++++++------- > drivers/scsi/libsas/sas_expander.c | 8 +-- > drivers/scsi/libsas/sas_init.c | 107 +++++++++++++++++++++++++++++++++- > drivers/scsi/libsas/sas_internal.h | 7 +++ > drivers/scsi/libsas/sas_phy.c | 69 +++++++++++----------- > drivers/scsi/libsas/sas_port.c | 25 ++++---- > include/scsi/libsas.h | 30 +++++++--- > include/scsi/scsi_transport_sas.h | 1 + > 11 files changed, 277 insertions(+), 97 deletions(-) >