Most error branches following the call to hisi_sas_shost_alloc contain
a call to kfree. This patch add these calls where they are
missing.
This issue was found with Hector.
Signed-off-by: Quentin Lambert <[email protected]>
---
drivers/scsi/hisi_sas/hisi_sas_main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -1503,8 +1503,10 @@ int hisi_sas_probe(struct platform_devic
arr_phy = devm_kcalloc(dev, phy_nr, sizeof(void *), GFP_KERNEL);
arr_port = devm_kcalloc(dev, port_nr, sizeof(void *), GFP_KERNEL);
- if (!arr_phy || !arr_port)
- return -ENOMEM;
+ if (!arr_phy || !arr_port) {
+ rc = -ENOMEM;
+ goto err_out_ha;
+ }
sha->sas_phy = arr_phy;
sha->sas_port = arr_port;
On 19/11/2016 17:42, Quentin Lambert wrote:
> Most error branches following the call to hisi_sas_shost_alloc contain
> a call to kfree. This patch add these calls where they are
> missing.
>
> This issue was found with Hector.
I think that this patch is fine. However I have noticed that we should
do a call to hisi_sas_free() for this failure, and later failures in the
probe.
I can generate a patch for this.
Cheers,
John
>
> Signed-off-by: Quentin Lambert <[email protected]>
>
> ---
> drivers/scsi/hisi_sas/hisi_sas_main.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> --- a/drivers/scsi/hisi_sas/hisi_sas_main.c
> +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
> @@ -1503,8 +1503,10 @@ int hisi_sas_probe(struct platform_devic
>
> arr_phy = devm_kcalloc(dev, phy_nr, sizeof(void *), GFP_KERNEL);
> arr_port = devm_kcalloc(dev, port_nr, sizeof(void *), GFP_KERNEL);
> - if (!arr_phy || !arr_port)
> - return -ENOMEM;
> + if (!arr_phy || !arr_port) {
> + rc = -ENOMEM;
> + goto err_out_ha;
> + }
>
> sha->sas_phy = arr_phy;
> sha->sas_port = arr_port;
>
> .
>
On 11/21/2016 01:53 PM, John Garry wrote:
> However I have noticed that we should do a call to hisi_sas_free() for
> this failure, and later failures in the probe.
I don't understand why, and would welcome the opportunity to learn
something.
Quentin
On 21/11/2016 13:20, Quentin Lambert wrote:
>
>
> On 11/21/2016 01:53 PM, John Garry wrote:
>> However I have noticed that we should do a call to hisi_sas_free() for
>> this failure, and later failures in the probe.
> I don't understand why, and would welcome the opportunity to learn
> something.
>
We call hisi_sas_alloc() from hisi_sas_shost_alloc(); if we fail after
this in hisi_sas_probe(), then we should free the memmories and
workqueue got in hisi_sas_alloc(), which we don't.
Thanks,
John
> Quentin
>
>
>
On 11/21/2016 03:16 PM, John Garry wrote:
> On 21/11/2016 13:20, Quentin Lambert wrote:
>>
>>
>> On 11/21/2016 01:53 PM, John Garry wrote:
>>> However I have noticed that we should do a call to hisi_sas_free() for
>>> this failure, and later failures in the probe.
>> I don't understand why, and would welcome the opportunity to learn
>> something.
>>
>
> We call hisi_sas_alloc() from hisi_sas_shost_alloc(); if we fail after
> this in hisi_sas_probe(), then we should free the memmories and
> workqueue got in hisi_sas_alloc(), which we don't.
Thanks.
Are you writing the patch or do you want me to do it?
Quentin
On 21/11/2016 14:25, Quentin Lambert wrote:
>
> On 11/21/2016 03:16 PM, John Garry wrote:
>> On 21/11/2016 13:20, Quentin Lambert wrote:
>>>
>>>
>>> On 11/21/2016 01:53 PM, John Garry wrote:
>>>> However I have noticed that we should do a call to hisi_sas_free() for
>>>> this failure, and later failures in the probe.
>>> I don't understand why, and would welcome the opportunity to learn
>>> something.
>>>
>>
>> We call hisi_sas_alloc() from hisi_sas_shost_alloc(); if we fail after
>> this in hisi_sas_probe(), then we should free the memmories and
>> workqueue got in hisi_sas_alloc(), which we don't.
> Thanks.
> Are you writing the patch or do you want me to do it?
>
We can do it, thanks.
> Quentin
>
>