linux-kernel - Re: [PATCH v3] scsi: libsas: Fix set zero-address when device-type != NO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 16 Nov 2023 16:54:35 +0000
From:   John Garry <john.g.garry@...cle.com>
To:     yangxingui <yangxingui@...wei.com>, yanaijie@...wei.com,
        jejb@...ux.ibm.com, martin.petersen@...cle.com,
        damien.lemoal@...nsource.wdc.com
Cc:     linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
        linuxarm@...wei.com, prime.zeng@...ilicon.com,
        kangfenglong@...wei.com, chenxiang66@...ilicon.com
Subject: Re: [PATCH v3] scsi: libsas: Fix set zero-address when device-type !=
 NO_DEVICE

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.

Thanks,
John