Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v2 4/7] scsi: libsas: split the replacement of sas disks
 in two steps
To:     Jason Yan <yanaijie@huawei.com>, <martin.petersen@oracle.com>,
        <jejb@linux.vnet.ibm.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>
 <5C53A7D1.5090700@huawei.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 <emilne@redhat.com>, Tomas Henzl <thenzl@redhat.com>
From:   John Garry <john.garry@huawei.com>
Message-ID: <8175f026-3b4e-27f9-2cfb-4efecbb5fe93@huawei.com>
Date:   Fri, 1 Feb 2019 09:34:19 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <5C53A7D1.5090700@huawei.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 01/02/2019 01:58, Jason Yan wrote:
>
>
> 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.

ok, fine, it's just for one expander; but we still do clear that one 
expanders events fully.

However we would have to be careful here to ensure that we don't have a 
situation where we still have PHY events pending but no broadcast events 
to trigger the revalidation and subsequent processing.

>
>> 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?

It would solve the problem of having to fixup the expanders events = -1, 
which I mentioned was not so nice.

As for fixing the main problem, I was not against the idea of the other 
change in sas_rediscover_dev() to not call sas_discover_new() when the 
SAS address has changed.

> 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
>>
>
>
>
> .
>