[PATCH 0/3] Three small fixes for libsas

[PATCH 0/3] Three small fixes for libsas

[Jason Yan]

We've found three small bugs. Please consider including them for 4.15.

Jason Yan (2):
  scsi: libsas: fix memory leak in sas_smp_get_phy_events()
  scsi: libsas: fix error when getting phy events

chenxiang (1):
  scsi: libsas: initialize sas_phy status according to response of
    DISCOVER

 drivers/scsi/libsas/sas_expander.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

-- 
2.9.5

[PATCH 1/3] scsi: libsas: fix memory leak in sas_smp_get_phy_events()

[Jason Yan]

We've got a memory leak with the following producer:

while true;
do cat /sys/class/sas_phy/phy-1:0:12/invalid_dword_count >/dev/null;
done

The buffer req is allocated and not freed after we return. Fix it.

Signed-off-by: Jason Yan <yanaijie@huawei.com>
CC: John Garry <john.garry@huawei.com>
CC: chenqilin <chenqilin2@huawei.com>
CC: chenxiang <chenxiang66@hisilicon.com>
---
 drivers/scsi/libsas/sas_expander.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c
index 3183d63..4b0c67f 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -695,6 +695,7 @@ int sas_smp_get_phy_events(struct sas_phy *phy)
 	phy->phy_reset_problem_count = scsi_to_u32(&resp[24]);
 
  out:
+	kfree(req);
 	kfree(resp);
 	return res;
 
-- 
2.9.5

[PATCH 2/3] scsi: libsas: fix error when getting phy events

[Jason Yan]

The intend purpose here was to goto out if smp_execute_task() returned
error. Obviously something got screwed up. We will never get these link
error statistics below:

~:/sys/class/sas_phy/phy-1:0:12 # cat invalid_dword_count
0
~:/sys/class/sas_phy/phy-1:0:12 # cat running_disparity_error_count
0
~:/sys/class/sas_phy/phy-1:0:12 # cat loss_of_dword_sync_count
0
~:/sys/class/sas_phy/phy-1:0:12 # cat phy_reset_problem_count
0

Obviously we should goto error handler if smp_execute_task() returns
non-zero.

Signed-off-by: Jason Yan <yanaijie@huawei.com>
CC: John Garry <john.garry@huawei.com>
CC: chenqilin <chenqilin2@huawei.com>
CC: chenxiang <chenxiang66@hisilicon.com>
---
 drivers/scsi/libsas/sas_expander.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c
index 4b0c67f..6eab487 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -686,7 +686,7 @@ int sas_smp_get_phy_events(struct sas_phy *phy)
 	res = smp_execute_task(dev, req, RPEL_REQ_SIZE,
 			            resp, RPEL_RESP_SIZE);
 
-	if (!res)
+	if (res)
 		goto out;
 
 	phy->invalid_dword_count = scsi_to_u32(&resp[12]);
-- 
2.9.5

[PATCH 3/3] scsi: libsas: initialize sas_phy status according to response of DISCOVER

[Jason Yan]

From: chenxiang <chenxiang66@hisilicon.com>

The status of SAS PHY is in sas_phy->enabled. There is an issue that the
status of a remote SAS PHY may be initialized incorrectly: if disable remote
SAS PHY through sysfs interface (such as echo 0 > /sys/class/sas_phy/phy-1:0:0/enable),
then reboot the system, and we will find the status of remote SAS PHY which is
disabled before is 1 (cat /sys/class/sas_phy/phy-1:0:0/enable). But actually
the status of remote SAS PHY is disabled and the device attached is not found.

In SAS protocol, NEGOTIATED LOGICAL LINK RATE field of DISCOVER response is 0x1
when remote SAS PHY is disabled. So initialize sas_phy->enabled according to
the value of NEGOTIATED LOGICAL LINK RATE field.

Signed-off-by: chenxiang <chenxiang66@hisilicon.com>
Reviewed-by: John Garry <john.garry@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
---
 drivers/scsi/libsas/sas_expander.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c
index 6eab487..c79cfd1 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -293,6 +293,7 @@ static void sas_set_ex_phy(struct domain_device *dev, int phy_id, void *rsp)
 	phy->phy->minimum_linkrate = dr->pmin_linkrate;
 	phy->phy->maximum_linkrate = dr->pmax_linkrate;
 	phy->phy->negotiated_linkrate = phy->linkrate;
+	phy->phy->enabled = (phy->linkrate == SAS_PHY_DISABLED) ? 0:1;
 
  skip:
 	if (new_phy)
-- 
2.9.5

Re: [PATCH 2/3] scsi: libsas: fix error when getting phy events

[John Garry]

On 02/01/2018 12:15, Jason Yan wrote:
> The intend purpose here was to goto out if smp_execute_task() returned
> error. Obviously something got screwed up. We will never get these link
> error statistics below:
>
> ~:/sys/class/sas_phy/phy-1:0:12 # cat invalid_dword_count
> 0
> ~:/sys/class/sas_phy/phy-1:0:12 # cat running_disparity_error_count
> 0
> ~:/sys/class/sas_phy/phy-1:0:12 # cat loss_of_dword_sync_count
> 0
> ~:/sys/class/sas_phy/phy-1:0:12 # cat phy_reset_problem_count
> 0
>
> Obviously we should goto error handler if smp_execute_task() returns
> non-zero.
>
> Signed-off-by: Jason Yan <yanaijie@huawei.com>
> CC: John Garry <john.garry@huawei.com>
> CC: chenqilin <chenqilin2@huawei.com>
> CC: chenxiang <chenxiang66@hisilicon.com>
> ---
>  drivers/scsi/libsas/sas_expander.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c
> index 4b0c67f..6eab487 100644
> --- a/drivers/scsi/libsas/sas_expander.c
> +++ b/drivers/scsi/libsas/sas_expander.c
> @@ -686,7 +686,7 @@ int sas_smp_get_phy_events(struct sas_phy *phy)
>  	res = smp_execute_task(dev, req, RPEL_REQ_SIZE,
>  			            resp, RPEL_RESP_SIZE);
>
> -	if (!res)
> +	if (res)
>  		goto out;

This seems to have been broken for some time.

Could you inject some errors on the link to verify that this function 
actually works properly with this change, i.e. non-zero reading?

Thanks,
John

>
>  	phy->invalid_dword_count = scsi_to_u32(&resp[12]);
>

Re: [PATCH 2/3] scsi: libsas: fix error when getting phy events

[Jason Yan]

On 2018/1/2 21:50, John Garry wrote:
> On 02/01/2018 12:15, Jason Yan wrote:
>> The intend purpose here was to goto out if smp_execute_task() returned
>> error. Obviously something got screwed up. We will never get these link
>> error statistics below:
>>
>> ~:/sys/class/sas_phy/phy-1:0:12 # cat invalid_dword_count
>> 0
>> ~:/sys/class/sas_phy/phy-1:0:12 # cat running_disparity_error_count
>> 0
>> ~:/sys/class/sas_phy/phy-1:0:12 # cat loss_of_dword_sync_count
>> 0
>> ~:/sys/class/sas_phy/phy-1:0:12 # cat phy_reset_problem_count
>> 0
>>
>> Obviously we should goto error handler if smp_execute_task() returns
>> non-zero.
>>
>> Signed-off-by: Jason Yan <yanaijie@huawei.com>
>> CC: John Garry <john.garry@huawei.com>
>> CC: chenqilin <chenqilin2@huawei.com>
>> CC: chenxiang <chenxiang66@hisilicon.com>
>> ---
>>  drivers/scsi/libsas/sas_expander.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/scsi/libsas/sas_expander.c
>> b/drivers/scsi/libsas/sas_expander.c
>> index 4b0c67f..6eab487 100644
>> --- a/drivers/scsi/libsas/sas_expander.c
>> +++ b/drivers/scsi/libsas/sas_expander.c
>> @@ -686,7 +686,7 @@ int sas_smp_get_phy_events(struct sas_phy *phy)
>>      res = smp_execute_task(dev, req, RPEL_REQ_SIZE,
>>                          resp, RPEL_RESP_SIZE);
>>
>> -    if (!res)
>> +    if (res)
>>          goto out;
>
> This seems to have been broken for some time.
>
> Could you inject some errors on the link to verify that this function
> actually works properly with this change, i.e. non-zero reading?
>
> Thanks,
> John
>

Yes, I have tested it. Before we fix, they are all zero. After we fix
it and do some test:

localhost:/sys/class/sas_phy/phy-1:0:1 #
localhost:/sys/class/sas_phy/phy-1:0:1 # cat invalid_dword_count
22
localhost:/sys/class/sas_phy/phy-1:0:1 # cat phy_reset_problem_count
1
localhost:/sys/class/sas_phy/phy-1:0:1 # cat running_disparity_error_count
23
localhost:/sys/class/sas_phy/phy-1:0:1 # cat loss_of_dword_sync_count
1
localhost:/sys/class/sas_phy/phy-1:0:1 #


>>
>>      phy->invalid_dword_count = scsi_to_u32(&resp[12]);
>>
>
>
>
> .
>