From: Gavin Shan <gshan@redhat.com>
To: James Morse <james.morse@arm.com>
Cc: mark.rutland@arm.com, catalin.marinas@arm.com, will@kernel.org,
shan.gavin@gmail.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 02/14] drivers/firmware/sdei: Common block for failing path in sdei_event_create()
Date: Wed, 22 Jul 2020 12:12:31 +1000 [thread overview]
Message-ID: <81c048fa-1e04-b66c-3864-85af62f9f8de@redhat.com> (raw)
In-Reply-To: <6c9d24d6-dc7d-60b4-5059-fe45fda5f6e4@arm.com>
Hi James,
On 7/22/20 6:40 AM, James Morse wrote:
> On 06/07/2020 06:47, Gavin Shan wrote:
>> The failing path in sdei_event_create() is to free SDEI event and
>> return the corresponding error. This introduces common block of
>> code for that to avoid duplicated logics.
>
> By replacing it with slightly different duplicated logic?
> If there were some kind of state to unwind here, I'd agree a single block to return from
> is less likely to have bugs. Until then, this change is just churn.
>
The problem is there are multiple calls to kfree(event) in sdei_event_create().
It's prone to cause memory leakage when more code is added to the failing
path. To have common/single block to free @event and return errno can avoid
the situation as you mentioned. I will adjust the commit log to make it more
explicit in v2.
>
>> By the way, the function
>> scoped variables are also reordered according to their importance.
>
> Please: Never do this.
>
> The 'order' is usually to make it easier to resolve merge conflicts. If two people add an
> entry, at the same time. Its normally a 'fir' tree, and all that really matters is its
> consistent. This change is just churn.
>
>
> No Thanks,
>
Ok. I will drop this part of change in v2.
Thanks,
Gavin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-07-22 2:13 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-06 5:47 [PATCH 00/14] Refactor SDEI client driver Gavin Shan
2020-07-06 5:47 ` [PATCH 01/14] drivers/firmware/sdei: Remove sdei_is_err() Gavin Shan
2020-07-21 20:39 ` James Morse
2020-07-22 2:04 ` Gavin Shan
2020-07-06 5:47 ` [PATCH 02/14] drivers/firmware/sdei: Common block for failing path in sdei_event_create() Gavin Shan
2020-07-21 20:40 ` James Morse
2020-07-22 2:12 ` Gavin Shan [this message]
2020-07-06 5:47 ` [PATCH 03/14] drivers/firmware/sdei: Dereference SDEI event parameter directly Gavin Shan
2020-07-21 20:41 ` James Morse
2020-07-22 2:38 ` Gavin Shan
2020-07-06 5:47 ` [PATCH 04/14] drivers/firmware/sdei: Rework sdei_init() Gavin Shan
2020-07-21 20:42 ` James Morse
2020-07-22 3:34 ` Gavin Shan
2020-07-06 5:47 ` [PATCH 05/14] drivers/firmware/sdei: Remove sdei_get_conduit() Gavin Shan
2020-07-21 20:42 ` James Morse
2020-07-22 3:50 ` Gavin Shan
2020-07-06 5:47 ` [PATCH 06/14] drivers/firmware/sdei: Drop redundant error message in sdei_probe() Gavin Shan
2020-07-06 5:47 ` [PATCH 07/14] drivers/firmware/sdei: Drop unnecessary while loop Gavin Shan
2020-07-06 5:47 ` [PATCH 08/14] drivers/firmware/sdei: Cleanup on cross call functions Gavin Shan
2020-07-06 5:47 ` [PATCH 09/14] drivers/firmware/sdei: Introduce sdei_do_local_call() Gavin Shan
2020-07-06 5:47 ` [PATCH 10/14] drivers/firmware/sdei: Remove _sdei_event_register() Gavin Shan
2020-07-06 5:47 ` [PATCH 11/14] drivers/firmware/sdei: Remove _sdei_event_unregister() Gavin Shan
2020-07-06 5:47 ` [PATCH 12/14] drivers/firmware/sdei: Identify event by struct sdei_event Gavin Shan
2020-07-06 5:47 ` [PATCH 13/14] drivers/firmware/sdei: Retrieve event signaled property on creation Gavin Shan
2020-07-06 5:47 ` [PATCH 14/14] drivers/firmware/sdei: Add sdei_event_get_info() Gavin Shan
2020-07-21 9:44 ` [PATCH 00/14] Refactor SDEI client driver Gavin Shan
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=81c048fa-1e04-b66c-3864-85af62f9f8de@redhat.com \
--to=gshan@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=shan.gavin@gmail.com \
--cc=will@kernel.org \
/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.