Received-SPF: pass (google.com: domain of linux-kernel+bounces-92065-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <a7eb46e3-997c-4746-b820-a09229e75581@oracle.com>
Date: Tue, 5 Mar 2024 10:15:11 +0000
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] scsi: libsas: Fix disk not being scanned in after being
 removed
To: Jason Yan <yanaijie@huawei.com>, yangxingui <yangxingui@huawei.com>,
        jejb@linux.ibm.com, martin.petersen@oracle.com,
        damien.lemoal@opensource.wdc.com
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
        linuxarm@huawei.com, prime.zeng@hisilicon.com,
        chenxiang66@hisilicon.com, kangfenglong@huawei.com
References: <20240221073159.29408-1-yangxingui@huawei.com>
 <f095aa1c-f233-40f9-ad0f-fcd8fe69a80d@oracle.com>
 <e2a725ee-98b3-fd57-6ee4-af031ffbd6bc@huawei.com>
 <80050a50-af6a-5862-8c12-ccaf91c5ff74@huawei.com>
 <7e1b554b-a675-14d2-59aa-7f37e3dd5994@huawei.com>
Content-Language: en-US
From: John Garry <john.g.garry@oracle.com>
Organization: Oracle Corporation
In-Reply-To: <7e1b554b-a675-14d2-59aa-7f37e3dd5994@huawei.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?utf-8?B?ZWtkMndVZnkyV3JMS2poSTQ0dHFpOVU3em05KzFjcDIzUlZaTitSdENUbHBi?=
 =?utf-8?B?eXlCUVU4ZXRLUWlTME11M2R3Y3NqaUdiU3RUQ1duL2RVNDhkc21QVStwQjlX?=
 =?utf-8?B?YkNFdzVxSkU5VUc5L1NGT2tmMEh1VU90NzIySjdTRHZ0UXlMT0k2ajY1MDl2?=
 =?utf-8?B?c3Z5UUVwd3FuRFVJby80djZ5SWZxckZyaVQvbHBLazRDR3BYSHlURis1SWNX?=
 =?utf-8?B?cFZsUlNJVStiY3ROWmtEMzR0bUxCUldXcUJRazZrT1Nxa1d3TmNPWTkvYmVu?=
 =?utf-8?B?UjJoVXJENUQ4SkhJSlhVTVQ0V01pY3ZCMzQwREgrUTF5VzZXbnVGajNiZlcw?=
 =?utf-8?B?NVFGV2JzV2hILzFyaEtNZHN4V3ZFV21DcWhlT1JQVUdRV0t3Y3BFQzZ3VEhU?=
 =?utf-8?B?TEJhMWhrUXpNcFRXdE9QdWdnMVhkOG9Vd2owcHMrMnhERVdsZC9Pa0lqbXBj?=
 =?utf-8?B?RS9QaWwyTHpoaUxJbnlyQVNFKzFsM084UjZyZDlxblpFMHJNbmFzU3k4WVAw?=
 =?utf-8?B?K3pJM3RhcnNUeTR5R0tuckQ1QkRxdENpMEVyREFVTXdHVlI4Z29yUm1jYnAz?=
 =?utf-8?B?QklmaVR5aTdMUGg0djFZRFk2Y1FKT3lkQUZsOVFtY2tMUkJMMkw2REswV0Zm?=
 =?utf-8?B?Nlo1UndrOWo1N3JGS1VHQTNZYUNLaDViMUpMZGtSTU9RdzlkMXpleDJyS09J?=
 =?utf-8?B?T25iM3lDVmw1NDFFbFdEQW1qbmxlWThnRnRiZ0FwbjBCYTFDLzBFWEg5MkRu?=
 =?utf-8?B?cndVQUNSUHNtaXVWUFBpWC82VkdJV29lOXo2WmtpOHBwR0FKUzRNNWNML204?=
 =?utf-8?B?cmVOZjgxM1M2d0RvK0pMdG9IOEkyMjQ1NkdncG5EUVVKbVpmak1tNXhaeDk1?=
 =?utf-8?B?MlFqR2RKWExCOFN4TkRORlA2WTJHZlJnQkZOdW95U0FienVYVXhwNFd2RHB5?=
 =?utf-8?B?Tk5kMUtTV2x0S2puU1crRWwzV1J1NWF3MjhRVjVENkhWUVJFWjZpUVQzL0Ir?=
 =?utf-8?B?NmdFTk5sTmlYcDBkdmlMK2ZLTlBqNnBxS1AzYW9GSTBxTTA4a0UyODZXTHA3?=
 =?utf-8?B?akxsUzIvbFcyb0Q2ZzRXZmNWcG9QOHlmSDJGVzJxMzNBOU1DNVV0cXdZZW5F?=
 =?utf-8?B?OFNMNlZVWlpnN1N2ZWZhRHl5Z2lJU0ZadFdOZnI3ajk4RUhJZ0gwR0NRQmxE?=
 =?utf-8?B?ZXlqcHVSMURaNmY4UTk4Zkg5dEh3N1I0YXRwOGJkUEwyU0xJdkVubktLS2Fv?=
 =?utf-8?B?YVc3ZE5CcUQwZXVQeHZhZ3lZZXRkeVQ5QjZaYVNBSlVxb0swbGZyWTRkWHph?=
 =?utf-8?B?cFZCSHdJVm9Jblg4NmxxMm5ubWhrUk9OZ0wrNnAzdmJtbTNDMHZ3TUtVQXpE?=
 =?utf-8?B?RnRjU3pBTVR4NGUxeGw4K25zRVd0RjVwYWRpSFR0YmJWYStRd2x6SlRZSVZB?=
 =?utf-8?B?OXV0Y0FtYXJubDExWHVUd0dEMzkvYkFnR3kranVnaXI2OG84ZlZDRlJuSmpZ?=
 =?utf-8?B?bnd3Y2cyM21VSlhmREVmdmJKWkZuMHBtak9kQlBpVUJyeGY5aWVBanptTk5a?=
 =?utf-8?B?WGdnMVMrL0g1Z3dqNDRjdUZKNk1DWEZTMVM0NnJlS2UzN0xXdklQc0pyaUpN?=
 =?utf-8?B?VUJHMEJLeHh2V1I2d3JMaTRWcGtJQzRqV3lSMlZRaXBMbS9nTzQzODNKclB0?=
 =?utf-8?B?T0JMT2JKOExucS9pU0ZTSFFMenAvTU56L3NTWTFqYXIrQ3dyblZQN2hVV3hI?=
 =?utf-8?B?dUZqZWVPaGFLZS9NdVZ2YWtkakFLMUN3bWl2ZUxyMTl2TmF0d3F3dm9HaFQ4?=
 =?utf-8?B?NUFYalllS2tOb3VmQjh5TWhlMEJTTTNzMFRtQnpoZm1MZHA4YWlyRWE0UkNZ?=
 =?utf-8?B?VnhKanhySW9vVHFXU0tPR0dkN0FLVHF6M3dRZ1FEYzlFOWRCOE15djBVdmxW?=
 =?utf-8?B?Y1ZBVVB6UWMyUksyeFJzTEYzSzlpRk9qeXVQeWhNNlBaMGlNQndCcUZSYkxQ?=
 =?utf-8?B?NHJ6eXFYcmh6Y3ZUU2ZyMmF0TysydTJ4endtUmtZWHpZbUhCMWxjaXdnMFRB?=
 =?utf-8?B?bnFOSzJWT0VMVERNcXRjM2RTMDl0VG1SdWp1Y3pBTUlSb3FiT3RtbUVHaUJn?=
 =?utf-8?B?bXpYTkU5bGczd002dk5mVHIxdGtBMllKeGdHK0l3ZnJVMDVMZkhLaVBoaUFM?=
 =?utf-8?B?SEE9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	FDhHr/uo+pDtXjT54MAfHYcx/CSBwNxecWQdPf5lQY3QlkM38xt2yBgsFGjKT4gE+1PUZZhS/YfbFPZVG46GhBOajAAQMwh3cdFOn9hYuVm1jmT6Wcv7H12v9in/VqIjyhVwprWVklS7GpNEuamXkmM7aVIQWB1WPae1qgYSOwY7UUdBSIySN0EQSZk+iTebPx1OLmrnib4+7dcVuu081oibru8ibQApkoIK/HHZPlnkCWU5UoB+9/PwutA+HIOcRWJri7YKudTfFhnMlkyq43R+IfpJ9liLPGMYCMKcs8LBSiSYsuuBuZ9dBFvb6LeZZjwlUM//2rWo9Ddn9II0CRq8zlKU7GOzctja6aIC2dY9XYlBzexgIv4PRMspMX4OPu9ib4depRgWTM9GtZR7IAeHVik0CXBjjBYd/mapYbegR84WRCxGZnuNWzsDBmB6sBd2dZemM8cK4PENoeUbyvqhlool29rikopUJ85Ens3vVKnw3CYRkaTOykF5iwXQfp6YqCHU5S8yk+6W+VZbgtxC0QudZ6rtq1HJdmo5eqgqoAKbch2Q36UOy5J3rtGbrBexuZHxiiP4ZOGGaZ5KcmGFyjkjJGLxXYoxXBr4SnA=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7f873a0a-48c3-456c-02f9-08dc3cfd2707
X-MS-Exchange-CrossTenant-AuthSource: DM6PR10MB4313.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2024 10:15:16.1414
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: iZM2JWTdBokjoKPC6OH6gK4t9XRNhITzT+MW3DLjmaohf+buPDKOfqZGHmQNeHot3R/nzuOph0peH/5uuUEgEw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR10MB4364
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-03-05_07,2024-03-04_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 bulkscore=0 mlxscore=0
 spamscore=0 phishscore=0 suspectscore=0 malwarescore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000
 definitions=main-2403050081
X-Proofpoint-GUID: s-3nTvYxnaJLxhSE1Mtzv4CGPqdn0pvQ
X-Proofpoint-ORIG-GUID: s-3nTvYxnaJLxhSE1Mtzv4CGPqdn0pvQ

On 05/03/2024 02:56, Jason Yan wrote:
> On 2024/3/4 20:50, yangxingui wrote:
>> Hi Jason,
>>
>> On 2024/3/1 9:55, Jason Yan wrote:
>>> On 2024/2/29 2:13, John Garry wrote:
>>>> On 21/02/2024 07:31, Xingui Yang wrote:
>>>>> As of commit d8649fc1c5e4 ("scsi: libsas: Do discovery on empty PHY to
>>>>> update PHY info"), do discovery will send a new SMP_DISCOVER and 
>>>>> update
>>>>> phy->phy_change_count. We found that if the disk is reconnected and 
>>>>> phy
>>>>> change_count changes at this time, the disk scanning process will 
>>>>> not be
>>>>> triggered.
>>>>>
>>>>> So update the PHY info with the last query results.
>>>>>
>>>>> Fixes: d8649fc1c5e4 ("scsi: libsas: Do discovery on empty PHY to 
>>>>> update PHY info")
>>>>> Signed-off-by: Xingui Yang <yangxingui@huawei.com>
>>>>> ---
>>>>>   drivers/scsi/libsas/sas_expander.c | 9 ++++-----
>>>>>   1 file changed, 4 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/drivers/scsi/libsas/sas_expander.c 
>>>>> b/drivers/scsi/libsas/sas_expander.c
>>>>> index a2204674b680..9563f5589948 100644
>>>>> --- a/drivers/scsi/libsas/sas_expander.c
>>>>> +++ b/drivers/scsi/libsas/sas_expander.c
>>>>> @@ -1681,6 +1681,10 @@ int sas_get_phy_attached_dev(struct 
>>>>> domain_device *dev, int phy_id,
>>>>>           if (*type == 0)
>>>>>               memset(sas_addr, 0, SAS_ADDR_SIZE);
>>>>>       }
>>>>> +
>>>>> +    if ((SAS_ADDR(sas_addr) == 0) || (res == -ECOMM))
>>>>
>>>> It's odd to call sas_set_ex_phy() if we got res == -ECOMM. I mean, 
>>>> in this this case disc_resp is not filled in as the command did not 
>>>> execute, right? I know that is what the current code does, but it is 
>>>> strange.
>>>
>>> The current code actually re-send the SMP command and update the PHY 
>>> status only when the the SMP command is responded correctly.
>>>
>>> Xinggui, can you please fix this and send v3?
>> The current location cannot directly update the phy information. The 
>> previous phy information will be used later, and the previous sas 
>> address will be compared with the currently queried sas address. At 
>> present, v2 is more suitable after many days of testing.

I don't understand this. Where is the previous SAS address compared to 
the current SAS address?

Could this work:

diff --git a/drivers/scsi/libsas/sas_expander.c 
b/drivers/scsi/libsas/sas_expander.c
index a2204674b680..e190038ba7bd 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -1675,11 +1675,13 @@ int sas_get_phy_attached_dev(struct 
domain_device *dev, int phy_id,

         res = sas_get_phy_discover(dev, phy_id, disc_resp);
         if (res == 0) {
-               memcpy(sas_addr, disc_resp->disc.attached_sas_addr,
-                      SAS_ADDR_SIZE);
                 *type = to_dev_type(&disc_resp->disc);
-               if (*type == 0)
+               if (*type == SAS_PHY_UNUSED)
                         memset(sas_addr, 0, SAS_ADDR_SIZE);
+               else
+                       memcpy(sas_addr, disc_resp->disc.attached_sas_addr,
+                      SAS_ADDR_SIZE);
+               sas_set_ex_phy(dev, phy_id, disc_resp);
         }
         kfree(disc_resp);
         return res;
lines 1-21/21 (END)

It's like the change in this patch.


> 
> OK, so let me have a closer look at v2.

I have to say that v2 is quite complicated...