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

[John Garry]

On 21/05/2026 10:04, yangxingui wrote:
> > Can this be reused (to lose and find the device with updated info)? Or 
> > why not good enough?
> >
> > I don't know why you need full revalidation.
>
> 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?


 we
> cannot reuse this synchronous pattern because:
> sas_unregister_devs_sas_addr() only marks the device as gone (sets 
> SAS_DEV_GONE) and adds it to port->destroy_list. The actual sysfs 
> cleanup (sas_rphy_delete) happens later in sas_destruct_devices() called 
> at the end of sas_revalidate_domain() in sas_discover.c.
> I did try the approach you suggested (unregister + sas_discover_new), 
> but it produces sysfs duplicate directory errors:
> Workqueue: 0000:74:02.0_disco_q sas_revalidate_domain
> Call trace:
>   dump_backtrace+0x0/0x18c
>   show_stack+0x14/0x1c
>   dump_stack+0x88/0xac
>   sysfs_warn_dup+0x64/0x7c
>   sysfs_create_dir_ns+0x90/0xa0
>   kobject_add_internal+0xa0/0x284
>   kobject_add+0xb8/0x11c
>   device_add+0xe8/0x598
>   sas_port_add+0x24/0x50
>   sas_ex_discover_devices+0xb10/0xc30
>
> The async pattern with DISCE_REVALIDATE_DOMAIN ensures proper ordering:
> 1. Old device added to destroy_list
> 2. Current revalidate work completes → sas_destruct_devices() truly 
> deletes old device's sysfs
> 3. New DISCE_REVALIDATE_DOMAIN event triggers → discovery starts with 
> clean sysfs state
> This follows libsas's async design pattern similar to sas_resume_devices 
> in sas_port.c.