Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1484534

Re: [PATCH 3/4] clk/Renesas-MSTP: Less function calls in cpg_mstp_clocks_init() after error detection

From SF Markus Elfring <elfring@users.sourceforge.net>
Newsgroups linux.kernel
Subject Re: [PATCH 3/4] clk/Renesas-MSTP: Less function calls in cpg_mstp_clocks_init() after error detection
Date 2016-09-15 22:50 +0200
Message-ID <shLLz-3qc-9@gated-at.bofh.it> (permalink)
References <qEuGl-43C-5@gated-at.bofh.it> <shovD-56t-17@gated-at.bofh.it> <shoFk-5qB-33@gated-at.bofh.it> <shKmu-2C4-27@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


> It's perfectly legal to call kfree() on a NULL pointer.

I know this function property well.


>> * Split a condition check for memory allocation failures so that
>>   each pointer from these function calls will be checked immediately.
>>
>>   See also background information:
>>   Topic "CWE-754: Improper check for unusual or exceptional conditions"
>>   Link: https://cwe.mitre.org/data/definitions/754.html
>>
>> * Return directly after a call of the function "kzalloc" failed
>>   at the beginning.
> 
> Both calls are already close together.

Can it be that an other software development concern is eventually
overlooked because of this "neighbourship" (or is categorised with
a lower priority)?

I suggest to reconsider this design detail if it is really acceptable
for the safe implementation of such a software module.

* How much will it matter in general that one function call was performed
  in this use case without checking its return values immediately?

* Should it usually be determined quicker if a required resource like
  memory could be acquired before trying the next allocation?


> In addition, your patch increases the LoC, IMHO without improving the code.

I find this consequence still debatable.


>> diff --git a/drivers/clk/renesas/clk-mstp.c b/drivers/clk/renesas/clk-mstp.c
>> index 1fdc44b..6c82e0e 100644
>> --- a/drivers/clk/renesas/clk-mstp.c
>> +++ b/drivers/clk/renesas/clk-mstp.c
>> @@ -167,10 +167,12 @@ static void __init cpg_mstp_clocks_init(struct device_node *np)
>>         unsigned int i;
>>
>>         group = kzalloc(sizeof(*group), GFP_KERNEL);
>> +       if (!group)
>> +               return;
>> +
>>         clks = kmalloc_array(MSTP_MAX_CLOCKS, sizeof(*clks), GFP_KERNEL);
>> -       if (group == NULL || clks == NULL) {
>> +       if (!clks) {
>>                 kfree(group);
>> -               kfree(clks);
>>                 return;
>>         }

Is this update suggestion worth for another look?

Regards,
Markus

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 0/4] clk/Renesas-MSTP: Fine-tuning for two function  implementations SF Markus Elfring <elfring@users.sourceforge.net> - 2016-09-14 22:00 +0200
  [PATCH 4/4] clk/Renesas-MSTP: Rename jump labels in  cpg_mstp_attach_dev() SF Markus Elfring <elfring@users.sourceforge.net> - 2016-09-14 22:10 +0200
    Re: [PATCH 4/4] clk/Renesas-MSTP: Rename jump labels in cpg_mstp_attach_dev() Geert Uytterhoeven <geert@linux-m68k.org> - 2016-09-15 21:20 +0200
      Re: clk/Renesas-MSTP: Rename jump labels in cpg_mstp_attach_dev() SF Markus Elfring <elfring@users.sourceforge.net> - 2016-09-16 08:10 +0200
  [PATCH 1/4] clk/Renesas-MSTP: Use kmalloc_array() in  cpg_mstp_clocks_init() SF Markus Elfring <elfring@users.sourceforge.net> - 2016-09-14 22:10 +0200
    Re: [PATCH 1/4] clk/Renesas-MSTP: Use kmalloc_array() in cpg_mstp_clocks_init() Geert Uytterhoeven <geert@linux-m68k.org> - 2016-09-15 21:20 +0200
    Re: [PATCH 1/4] clk/Renesas-MSTP: Use kmalloc_array() in  cpg_mstp_clocks_init() Stephen Boyd <sboyd@codeaurora.org> - 2016-09-17 01:20 +0200
  [PATCH 3/4] clk/Renesas-MSTP: Less function calls in  cpg_mstp_clocks_init() after error detection SF Markus Elfring <elfring@users.sourceforge.net> - 2016-09-14 22:10 +0200
    Re: [PATCH 3/4] clk/Renesas-MSTP: Less function calls in  cpg_mstp_clocks_init() after error detection Geert Uytterhoeven <geert@linux-m68k.org> - 2016-09-15 21:20 +0200
      Re: [PATCH 3/4] clk/Renesas-MSTP: Less function calls in  cpg_mstp_clocks_init() after error detection Geert Uytterhoeven <geert@linux-m68k.org> - 2016-09-15 22:50 +0200
        Re: clk/Renesas-MSTP: Less function calls in cpg_mstp_clocks_init()  after error detection SF Markus Elfring <elfring@users.sourceforge.net> - 2016-09-16 07:40 +0200
      Re: [PATCH 3/4] clk/Renesas-MSTP: Less function calls in  cpg_mstp_clocks_init() after error detection SF Markus Elfring <elfring@users.sourceforge.net> - 2016-09-15 22:50 +0200
  [PATCH 2/4] clk/Renesas-MSTP: Delete an error message for a failed  memory allocation SF Markus Elfring <elfring@users.sourceforge.net> - 2016-09-14 22:10 +0200
    Re: [PATCH 2/4] clk/Renesas-MSTP: Delete an error message for a  failed memory allocation Geert Uytterhoeven <geert@linux-m68k.org> - 2016-09-15 21:10 +0200
      Re: [PATCH 2/4] clk/Renesas-MSTP: Delete an error message for a failed memory allocation Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2016-09-15 21:20 +0200
        Re: [PATCH 2/4] clk/Renesas-MSTP: Delete an error message for a  failed memory allocation Wolfram Sang <wsa@the-dreams.de> - 2016-09-15 21:50 +0200
        Re: clk/Renesas-MSTP: Delete an error message for a failed memory  allocation SF Markus Elfring <elfring@users.sourceforge.net> - 2016-09-15 22:20 +0200
          Re: clk/Renesas-MSTP: Delete an error message for a failed memory allocation Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2016-09-16 01:00 +0200
            Re: clk/Renesas-MSTP: Delete an error message for a failed memory  allocation SF Markus Elfring <elfring@users.sourceforge.net> - 2016-09-16 07:30 +0200

csiph-web