[PATCH v3 0/3] Three small fixes for libsas

[PATCH v3 0/3] Three small fixes for libsas

[Jason Yan]

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

V3:
	- Add "Reviewed-by" tag.
	- Code improvement suggested by Christoph Hellwig.

V2:
	- Add "Fixes" tag.

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 v3 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.

Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver")
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>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 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 v3 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.

Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver")
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>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 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 v3 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);
 
  skip:
 	if (new_phy)
-- 
2.9.5

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

[Christoph Hellwig]

Looks good,

Reviewed-by: Christoph Hellwig <hch@lst.de>

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

[Hannes Reinecke]

On 01/04/2018 02:04 PM, Jason Yan wrote:
> 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.
> 
> Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver")
> 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>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> ---
>  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;
>  
> 
Reviewed-by: Hannes Reinecke <hare@suse.com>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		               zSeries & Storage
hare@suse.com			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

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

[Hannes Reinecke]

On 01/04/2018 02:04 PM, 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.
> 
> Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver")
> 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>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> ---
>  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]);
> 
Reviewed-by: Hannes Reinecke <hare@suse.com>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		               zSeries & Storage
hare@suse.com			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

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

[Hannes Reinecke]

On 01/04/2018 02:04 PM, Jason Yan wrote:
> 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);
>  
>   skip:
>  	if (new_phy)
> 
Reviewed-by: Hannes Reinecke <hare@suse.com>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		               zSeries & Storage
hare@suse.com			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

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

[Martin K. Petersen]

Jason,

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

Applied patches 1-3 to 4.16/scsi-queue. Thanks!

-- 
Martin K. Petersen	Oracle Linux Engineering