Re: [PATCH v3 2/2] scsi: libsas: Add linkrate and sas_addr change detection in rediscover
From: John Garry
Date: Wed May 27 2026 - 05:48:29 EST
On 25/05/2026 03:25, yangxingui wrote:
Hi, John
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?
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.