From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Yan Subject: Re: [PATCH v2 4/7] scsi: libsas: split the replacement of sas disks in two steps Date: Fri, 1 Feb 2019 09:58:41 +0800 Message-ID: <5C53A7D1.5090700@huawei.com> References: <20190130082412.9357-1-yanaijie@huawei.com> <20190130082412.9357-5-yanaijie@huawei.com> <17908564-35f2-4c5d-e9e4-4fe109fae4cc@huawei.com> <5C5257AC.3040303@huawei.com> <7ad77303-9960-5b8c-f26e-fc825ac57621@huawei.com> <55b43797-4504-76dc-e5bf-c588623d0866@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55b43797-4504-76dc-e5bf-c588623d0866@huawei.com> Sender: linux-kernel-owner@vger.kernel.org To: John Garry , martin.petersen@oracle.com, jejb@linux.vnet.ibm.com Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, zhaohongjiang@huawei.com, hare@suse.com, dan.j.williams@intel.com, jthumshirn@suse.de, hch@lst.de, huangdaode@hisilicon.com, chenxiang66@hisilicon.com, xiexiuqi@huawei.com, tj@kernel.org, miaoxie@huawei.com, Ewan Milne , Tomas Henzl List-Id: linux-scsi@vger.kernel.org On 2019/2/1 0:38, John Garry wrote: > On 31/01/2019 10:29, John Garry wrote: >> On 31/01/2019 02:04, Jason Yan wrote: >>> >>> >>> On 2019/1/31 1:22, John Garry wrote: >>>> On 30/01/2019 08:24, Jason Yan wrote: >>>>> Now if a new device replaced a old device, the sas address will >>>>> change. >>>> >>>> Hmmm... not if it's a SATA disk, which would have some same invented >>>> SAS >>>> address. >>>> >>> >>> Yes, it's only for a SAS disk. >>> >>>>> We unregister the old device and discover the new device in one >>>>> revalidation process. But after we deferred the sas_port_delete(), the >>>>> sas port is not deleted when we registering the new port and device. >>>>> The sas port cannot be added because the name of the new port is the >>>>> same as the old. >>>>> >>>>> Fix this by doing the replacement in two steps. The first revalidation >>>>> only delete the old device and trigger a new revalidation. The second >>>>> revalidation discover the new device. To keep the event processing >>>>> synchronised to the original event, > > This change seems ok, but please see below regarding generating the > bcast events. > >>>> >>>> Did I originally suggest this? It seems to needlessly make the code >>>> more >>>> complicated. >>>> >>> >>> Yes, my first version was raise a new bcast event, and you said it's not >>> synchronised to the original event. Shall I get back to that approach? >> >> Not sure. This patch seems to fix something closely related to that in >> "scsi: libsas: fix issue of swapping two sas disks", which I will check >> further. >> > > An idea: > > So, before the libsas changes to generate dynamic events, when libsas > was processing a particular event type - like a broadcast event - extra > events generated by the LLDD were discarded by libsas. > > The revalidation process attempted to do all revalidation for the domain > is a single pass, which was ok. This really did not change. > > However, in this revalidation pass, we also clear all expander and PHY > events. > Actually we only clean one expander and it's attached PHYs events now. > Maybe this is not the right thing to do. Maybe we should just clear a > single PHY event per pass, since we're processing each broadcast event > one-by-one. > Yes, we can do this. But I don't understand how this will fix the issue? We have this issue now because we have to probe the sas port and/or delete the sas port out side of the disco_mutex. So for a specific PHY, we cannot add and delete at the same time inside the disco_mutex. > Today you will notice that if we remove a disk for example, many > broadcast events are generated, but only the first broadcast event > actually does any revalidation. > > EOM >