linux-kernel - Re: [PATCH v3 1/3] scsi: hisi_sas: Enable force phy when SATA disk directly connected

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]

Message-ID: <5a4384dc-4edb-9e29-d1dd-190d69b9e313@huawei.com>
Date: Fri, 21 Feb 2025 09:59:27 +0800
From: yangxingui <yangxingui@...wei.com>
To: John Garry <john.g.garry@...cle.com>, <liyihang9@...wei.com>,
	<yanaijie@...wei.com>
CC: <jejb@...ux.ibm.com>, <martin.petersen@...cle.com>,
	<linux-scsi@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linuxarm@...wei.com>, <prime.zeng@...wei.com>, <liuyonglong@...wei.com>,
	<kangfenglong@...wei.com>, <liyangyang20@...wei.com>,
	<f.fangjian@...wei.com>, <xiabing14@...artners.com>
Subject: Re: [PATCH v3 1/3] scsi: hisi_sas: Enable force phy when SATA disk
 directly connected

Hi, John

On 2025/2/21 1:35, John Garry wrote:
> On 20/02/2025 13:05, Xingui Yang wrote:
> 
> -john.garry@...wei.com (this has not worked in over 2 years ...)
Sorry, I used the wrong one.
> 
>> the SAS controller determines the disk to which I/Os are delivered based
>> on the port id in the DQ entry when SATA disk directly connected.
>>
>> When many phys were disconnected immediately and connected again during
>> I/O sending and port id of phys were changed and used by other link, I/O
>> may be sent to incorrect disk and data inconsistency on the SATA disk may
> 
> 
> So is the disk reported gone (from libsas point-of-view) after you 
> unplug? If not, why not?

The problem may occur in a scenario where multiple SATA disks are 
inserted almost at the same time. When phy reset is executed in error 
processing, other phys are also up, which may cause the hw port id 
corresponding to the phy to change. The log is as follows:

[ 4588.608924] hisi_sas_v3_hw 0000:b4:02.0: phyup: phy2 link_rate=10(sata)
[ 4588.609039] sas: phy-8:2 added to port-8:4, phy_mask:0x4 
(5000000000000802)
[ 4588.609267] sas: DOING DISCOVERY on port 4, pid:69294
[ 4588.609276] hisi_sas_v3_hw 0000:b4:02.0: dev[13:5] found
[ 4588.671362] sas: ata40: end_device-8:4: dev error handler
[ 4588.846387] hisi_sas_v3_hw 0000:b4:02.0: phydown: phy2 phy_state=0xc3 
// phy2's hw port id assign by chip is released
[ 4588.846393] hisi_sas_v3_hw 0000:b4:02.0: ignore flutter phy2 down
[ 4588.919837] hisi_sas_v3_hw 0000:b4:02.0: phyup: phy3 
link_rate=10(sata) // phy3 is assigned the hw port id previously used by 
phy2
[ 4589.029656] hisi_sas_v3_hw 0000:b4:02.0: phyup: phy2 
link_rate=10(sata) // phy2's hw port id is assigned a new one
[ 4589.220662] ata40.00: ATA-9: HUH721010ALE600, T3C0, max UDMA/133
[ 4589.220666] ata40.00: 19532873728 sectors, multi 0: LBA48 NCQ (depth 
32), AA
[ 4589.233022] ata40.00: configured for UDMA/133

In view of the situation corresponding to the above log, the 
hisi_sas_port.id corresponding to phy2 has not been updated, and the old 
port id is still used, which will cause the IO delivered to phy2 to be 
abnormally delivered to the disk of phy3.

After force phy, the chip will check whether the phy information matches 
the port id and intercept this abnormal IO.

Thanks.
Xingui