[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8806e9cb-4200-8154-7914-6735805dfbe0@users.sourceforge.net>
Date: Tue, 19 Jul 2016 16:56:35 +0200
From: SF Markus Elfring <elfring@...rs.sourceforge.net>
To: Jürgen Groß <jgross@...e.com>
Cc: xen-devel@...ts.xenproject.org, linux-scsi@...r.kernel.org,
David Vrabel <david.vrabel@...rix.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
LKML <linux-kernel@...r.kernel.org>,
kernel-janitors@...r.kernel.org,
Julia Lawall <julia.lawall@...6.fr>
Subject: Re: [PATCH 2/3] xen-scsiback: One function call less in
scsiback_device_action() after error detection
>> @@ -606,7 +606,7 @@ static void scsiback_device_action(struct vscsibk_pend *pending_req,
>> tmr = kzalloc(sizeof(struct scsiback_tmr), GFP_KERNEL);
>> if (!tmr) {
>> target_put_sess_cmd(se_cmd);
>> - goto err;
>> + goto do_resp;
>> }
>
> Hmm, I'm not convinced this is an improvement.
>
> I'd rather rename the new error label to "put_cmd" and get rid of the
> braces in above if statement:
>
> - if (!tmr) {
> - target_put_sess_cmd(se_cmd);
> - goto err;
> - }
> + if (!tmr)
> + goto put_cmd;
>
> and then in the error path:
>
> -err:
> +put_cmd:
> + target_put_sess_cmd(se_cmd);
I am unsure on the relevance of this function on such a source position.
Would it make sense to move it further down at the end?
> +free_tmr:
> kfree(tmr);
How do you think about to skip this function call after a memory
allocation failure?
Regards,
Markus
Powered by blists - more mailing lists