Messages in this thread | | | Date | Fri, 17 Nov 2023 17:05:16 +0800 | Subject | Re: [PATCH v3] scsi: libsas: Fix set zero-address when device-type != NO_DEVICE | From | yangxingui <> |
| |
Hi John,
On 2023/11/17 0:54, John Garry wrote: > On 16/11/2023 13:45, yangxingui wrote: >>> I think that patch title can be improved, but I would need to know >>> more about the problem before suggesting an improvement. >> How about "Fix port add phy failed" ? >>> >>>> Firstly, when ex_phy is added to the parent port, ex_phy->port is >>>> not set. >>> >>> That seems correct, but why mention this now? >>> >>>> As a result, sas_port_delete_phy() won't be called in >>>> sas_unregister_devs_sas_addr(), and although ex_phy's sas_address is >>>> zero, >>>> it is not deleted from the parent port's phy_list. >>> >>> I am not sure why you mention this now either. You seem to be >>> describing how the problem occurs without actually mentioning what >>> the problem is. >>> ohn >>>> >>>> Secondly, phy->attached_sas_addr will be set to a zero-address when >>>> phy->linkrate < SAS_LINK_RATE_1_5_GBPS and device-type != NO_DEVICE >>>> during >>>> device registration, such as stp. It will create a new port and all >>>> other >>>> ex_phys whose addresses are zero will be added to the new port in >>>> sas_ex_get_linkrate(), and it may trigger BUG() as follows: >>> >>> I think that it would be better to first mention this crash, i.e. the >>> problem, how you recreate it, and then describe how and why it >>> happens, and then tell us how you will fix it >> How about follows: >> >> The following processes trigger a BUG(). A new port port-7:7:0 that >> created by a new zero-address sata device tries to add phy-7:7:19 had >> the same zero-address, but phy-7:7:19 is already part of another port. > > I would like to know how to recreate, which gives a lot more context and > helps me understand what the problem is. I have update a new version based on your suggestion.
Thanks, Xingui .
| |