linux-kernel - Re: [External] : Re: [PATCH] scsi: libsas: Check and update the link rate during discovery

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: <6971d59e-2a72-2812-d289-53e61121f35a@oracle.com>
Date:   Mon, 7 Nov 2022 12:44:20 +0000
From:   John Garry <john.g.garry@...cle.com>
To:     Yihang Li <liyihang9@...wei.com>, jejb@...ux.ibm.com,
        martin.petersen@...cle.com
Cc:     bvanassche@....org, chenxiang66@...ilicon.com,
        daejun7.park@...sung.com, damien.lemoal@...nsource.wdc.com,
        yanaijie@...wei.com, duoming@....edu.cn,
        linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
        prime.zeng@...ilicon.com, yangxingui@...wei.com,
        linuxarm@...wei.com
Subject: Re: [External] : Re: [PATCH] scsi: libsas: Check and update the link
 rate during discovery


>>>
>>> SATA disk which connected to expander PHY maybe reject IO request due to
>>> the connection setup error (OPEN_REJECT-CONNECTION RATE NOT SUPPORTED).
>>> The log as follows:
>>>
>>> [175712.419423] hisi_sas_v3_hw 0000:74:02.0: erroneous completion iptt=2985 task=00000000268357f1 dev id=10 exp 0x500e004aaaaaaa1f phy9 addr=500e004aaaaaaa09 CQ hdr: 0x102b 0xa0ba9 0x1000 0x20000 Error info: 0x200 0x0 0x0 0x0
>>>
>>> After analysis, it is concluded that: when one of the physical links
>>> connected on the wide port is re-established, the link rate of the port
>>> and expander device and the expander SATA PHY are not updated. As a
>>> result, the expander PHY attached to a SATA PHY is using link rate
>>> (6.0 Gbit) greater than the physical PHY link rate (3.0 Gbit).
>>
>> Please mention the SAS spec section in which min pathway is described.
> 
> Do you mean the original text of the SAS spec section needs to be added here?
> 

I mean to at least mention the spec version and section number and title 
(in that spec version).

> Like this:
> 
> According to Serial Attached SCSI:
> If an STP initiator port discovers a SATA device behind an STP/SATA bridge with a physical link rate greater
> than the maximum connection rate supported by the pathway from the STP initiator port, the STP initiator port
> should use the SMP PHY CONTROL function (see 10.4.3.10) to set the MAXIMUM PHYSICAL LINK RATE field of
> the expander phy attached to the SATA device to the maximum connection rate supported by the pathway.

I think that this condition in the spec is a flaw. Or at least annoying.

> 
>>
>>>
>>> Therefore, add function sas_check_port_linkrate() to check whether the
>>> link rate of physical PHY which is connected to the wide port changes
>>> after the phy up occur, if the link rate of the newly established
>>> physical phy is lower than the link rate of the port, a smaller link rate
>>> value is transmitted to port->linkrate.
>>>
>>> Use the sas_update_linkrate_root_expander() function to update the root
>>> expander link rate. Traverse all expanders connected to the port, check
>>> and update expander PHYs that need to be updated and triggers revalidation.
>>
>> So are you saying that you want to lower the linkrate on all pathways to the SATA disk? In your example, that would be 3Gbps. If so, won't that affect the end-to-end linkrate of all other devices attached (and lower throughput drastically)?
> 
> Yes, this will lower performance drastically, but I consider the following two things:
> 
> a. Ensure that all disks work properly when the issue we discussed occurs.
> 
> b. When the user limits the linkrate to a lower level through the sysfs interface, the linkrate on all pathways to the SATA disk should be reduced.
> 
> [root@...alhost phy-5:0]# lsscsi
> [5:0:0:0]    disk    HUAWEI   HWE32SS3008M001N 2774  /dev/sda
> [5:0:1:0]    disk    ATA      ST4000NM0035-1V4 TN03  /dev/sdb
> [5:0:12:0]   enclosu HUAWEI   Expander 12Gx16  131   -
> [root@...alhost phy-5:0]# cat maximum_linkrate
> 12.0 Gbit
> [root@...alhost phy-5:0]# cat minimum_linkrate
> 1.5 Gbit
> [root@...alhost phy-5:0]# echo 1.5 Gbit > maximum_linkrate
> [root@...alhost phy-5:0]# cat negotiated_linkrate
> 1.5 Gbit
> [root@...alhost phy-5:0]# lsscsi
> [5:0:0:0]    disk    HUAWEI   HWE32SS3008M001N 2774  /dev/sda
> [5:0:12:0]   enclosu HUAWEI   Expander 12Gx16  131   -
> [5:0:13:0]   disk    ATA      ST4000NM0035-1V4 TN03  /dev/sdb
> [root@...alhost phy-5:0]# cd ../phy-5\:0:1
> [root@...alhost phy-5:0:1]# cat negotiated_linkrate

So do we reset the linkrate of the SATA-attached phy, right? Could that 
cause the disk to be lost and found again? If so, doesn't seem useful if 
that disk had a filesystem mounted...

> 1.5 Gbit
> 
> 

I just wonder if it is better to disable that phy altogether rather than 
drag every other pathway down to this lower linkrate:

a. that would be simpler than trying to maintain this min pathway
b. the condition that gives rise to issue is very rare (so don't need to 
burden libsas with supporting it according to the spec).

Thanks,
John