All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jing Xiangfeng <jingxiangfeng@huawei.com>
To: "Ewan D. Milne" <emilne@redhat.com>, <hare@suse.de>,
	<jejb@linux.ibm.com>, <martin.petersen@oracle.com>,
	<robert.w.love@intel.com>, <Neerav.Parikh@intel.com>,
	<Markus.Elfring@web.de>
Cc: <linux-scsi@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] scsi: fcoe: add missed kfree() in an error path
Date: Thu, 16 Jul 2020 16:13:45 +0800	[thread overview]
Message-ID: <5F100C39.5070503@huawei.com> (raw)
In-Reply-To: <d1fa9e60b559b6bf3a37ef5a6aef2bd7bd6e1681.camel@redhat.com>



On 2020/7/14 1:53, Ewan D. Milne wrote:
> See below.
>
> On Thu, 2020-07-09 at 20:05 +0800, Jing Xiangfeng wrote:
>> fcoe_fdmi_info() misses to call kfree() in an error path.
>> Add a label 'free_fdmi' and jump to it.
>>
>> Fixes: f07d46bbc9ba ("fcoe: Fix smatch warning in fcoe_fdmi_info
>> function")
>> Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
>> ---
>>   drivers/scsi/fcoe/fcoe.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
>> index 25dae9f0b205..a63057a03772 100644
>> --- a/drivers/scsi/fcoe/fcoe.c
>> +++ b/drivers/scsi/fcoe/fcoe.c
>> @@ -830,7 +830,7 @@ static void fcoe_fdmi_info(struct fc_lport
>> *lport, struct net_device *netdev)
>>   		if (rc) {
>>   			printk(KERN_INFO "fcoe: Failed to retrieve FDMI
>> "
>>   					"information from netdev.\n");
>> -			return;
>> +			goto free_fdmi;
>>   		}
>>
>>   		snprintf(fc_host_serial_number(lport->host),
>> @@ -868,6 +868,7 @@ static void fcoe_fdmi_info(struct fc_lport
>> *lport, struct net_device *netdev)
>>
>>   		/* Enable FDMI lport states */
>>   		lport->fdmi_enabled = 1;
>> +free_fdmi:
>>   		kfree(fdmi);
>>   	} else {
>>   		lport->fdmi_enabled = 0;
>
> Normally I would like to see goto labels for error paths outside
> conditionals and at the end of the function.

I agree.

  In this case it would
> seem to be cleaner to put an else { } clause in the if (rc) above
> around the snprintf() calls.

It is ok with me. v1 is also a simpler way.

+Hannes, Which is preferable?

Thanks

>
> -Ewan
>
> .
>

      reply	other threads:[~2020-07-16  8:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-09 12:05 [PATCH v2] scsi: fcoe: add missed kfree() in an error path Jing Xiangfeng
2020-07-13 17:53 ` Ewan D. Milne
2020-07-16  8:13   ` Jing Xiangfeng [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5F100C39.5070503@huawei.com \
    --to=jingxiangfeng@huawei.com \
    --cc=Markus.Elfring@web.de \
    --cc=Neerav.Parikh@intel.com \
    --cc=emilne@redhat.com \
    --cc=hare@suse.de \
    --cc=jejb@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=robert.w.love@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.