Re: [PATCH v3 2/2] scsi: libsas: Add linkrate and sas_addr change detection in rediscover

[John Garry <john.g.garry@oracle.com>]

On 25/05/2026 03:25, yangxingui wrote:
>>>
>>> Hi, John
>>> As the commit log. The existing pattern (unregister + 
>>> sas_discover_new) handles the "replace" case where the SAS address 
>>> changes completely, implying a different device.
>>> For the flutter case where we detect linkrate/sas_addr changes,
>>
>> Can you please clarify this: you say that the existing pattern handles 
>> "replace" case where the SAS address changes completely, and then 
>> flutter case covers sas_addr changes.
>>
>> What is the difference in the SAS address changes between the two cases?
>>
> Hi, John
> 
> The difference is in when the SAS address change is detected:
> Replace case:
> - Detected immediately by the initial SMP DISCOVER response
> - New SAS address differs from stored phy->attached_sas_addr
> 
> Flutter case:
> - Initial SMP DISCOVER shows SAS address matching stored phy- 
>  >attached_sas_addr
> - Linkrate may change
> - After sas_ex_phy_discover() refreshes phy info, child device address 
> and linkrate may mismatched with refreshed phy info
> 
> Additional issue with Replace flow:
> The existing replace code path also suffers from the same sysfs_warn_dup 
> issue I mentioned earlier. sas_unregister_devs_sas_addr() only marks the 
> device as gone and adds it to destroy_list. The actual sysfs cleanup 
> happens later in sas_destruct_devices(). Calling sas_discover_new() 
> immediately after unregister causes sysfs duplicate directory errors.
> 

So can you actually recreate this issue? Or is it just theoretical?

About this following code:

+		if (need_rediscover) {
+			set_bit(SAS_DEV_GONE, &child_dev->state);
+			phy->phy_change_count = -1;
+			ex->ex_change_count = -1;
+			sas_unregister_devs_sas_addr(dev, phy_id, true);
+			sas_discover_event(dev->port, DISCE_REVALIDATE_DOMAIN);
+		} else {


Can we factor it out with other code? AFAICR, this can pattern can be 
seen elsewhere.

Thanks

> We need to optimize the replace process.