common clk: fix clk_register_fixed_rate() under memory pressure

common clk: fix clk_register_fixed_rate() under memory pressure

[Domenico Andreoli]

From: Domenico Andreoli <cavokz@gmail.com>

Under memory pressure clk_register_fixed_rate() fails to manage
allocation errors and prepares land for a later WARN_ON at best.

This fix leaves parent_names correctly initialized or NULL, intermediate
half initialized states are cleaned up and not propagated to the clock
framework.

Signed-off-by: Domenico Andreoli <cavokz@gmail.com>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Arnd Bergman <arnd.bergmann@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Andrew Lunn <andrew@lunn.ch>

---
 drivers/clk/clk-fixed-rate.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

Index: b/drivers/clk/clk-fixed-rate.c
===================================================================
--- a/drivers/clk/clk-fixed-rate.c
+++ b/drivers/clk/clk-fixed-rate.c
@@ -67,8 +67,11 @@ struct clk *clk_register_fixed_rate(stru
 
 		parent_names[0] = kmalloc(len, GFP_KERNEL);
 
-		if (!parent_names[0])
+		if (!parent_names[0]) {
+			kfree(parent_names);
+			parent_names = NULL;
 			goto out;
+		}
 
 		strncpy(parent_names[0], parent_name, len);
 	}
@@ -77,6 +80,6 @@ out:
 	return clk_register(dev, name,
 			&clk_fixed_rate_ops, &fixed->hw,
 			parent_names,
-			(parent_name ? 1 : 0),
+			(parent_names ? 1 : 0),
 			flags);
 }

common clk: fix clk_register_fixed_rate() under memory pressure

[Turquette, Mike]

On Thu, Apr 5, 2012 at 1:48 AM, Domenico Andreoli <cavokz@gmail.com> wrote:
> From: Domenico Andreoli <cavokz@gmail.com>
>
> Under memory pressure clk_register_fixed_rate() fails to manage
> allocation errors and prepares land for a later WARN_ON at best.
>
> This fix leaves parent_names correctly initialized or NULL, intermediate
> half initialized states are cleaned up and not propagated to the clock
> framework.
>
> Signed-off-by: Domenico Andreoli <cavokz@gmail.com>

Thanks for the patch Domenico.  I did a big cleanup of the
registration code for all of the basic clock types and a fix for this
has already been rolled in to that branch, so I won't be taking this
patch.  I'll Cc you on the fixes when I send them to the list
(probably tomorrow).

Regards,
Mike

> Cc: Mike Turquette <mturquette@linaro.org>
> Cc: Arnd Bergman <arnd.bergmann@linaro.org>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Andrew Lunn <andrew@lunn.ch>
>
> ---
> ?drivers/clk/clk-fixed-rate.c | ? ?7 +++++--
> ?1 file changed, 5 insertions(+), 2 deletions(-)
>
> Index: b/drivers/clk/clk-fixed-rate.c
> ===================================================================
> --- a/drivers/clk/clk-fixed-rate.c
> +++ b/drivers/clk/clk-fixed-rate.c
> @@ -67,8 +67,11 @@ struct clk *clk_register_fixed_rate(stru
>
> ? ? ? ? ? ? ? ?parent_names[0] = kmalloc(len, GFP_KERNEL);
>
> - ? ? ? ? ? ? ? if (!parent_names[0])
> + ? ? ? ? ? ? ? if (!parent_names[0]) {
> + ? ? ? ? ? ? ? ? ? ? ? kfree(parent_names);
> + ? ? ? ? ? ? ? ? ? ? ? parent_names = NULL;
> ? ? ? ? ? ? ? ? ? ? ? ?goto out;
> + ? ? ? ? ? ? ? }
>
> ? ? ? ? ? ? ? ?strncpy(parent_names[0], parent_name, len);
> ? ? ? ?}
> @@ -77,6 +80,6 @@ out:
> ? ? ? ?return clk_register(dev, name,
> ? ? ? ? ? ? ? ? ? ? ? ?&clk_fixed_rate_ops, &fixed->hw,
> ? ? ? ? ? ? ? ? ? ? ? ?parent_names,
> - ? ? ? ? ? ? ? ? ? ? ? (parent_name ? 1 : 0),
> + ? ? ? ? ? ? ? ? ? ? ? (parent_names ? 1 : 0),
> ? ? ? ? ? ? ? ? ? ? ? ?flags);
> ?}
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

common clk: fix clk_register_fixed_rate() under memory pressure

[Mark Brown]

On Mon, Apr 09, 2012 at 02:52:15PM -0700, Turquette, Mike wrote:

> Thanks for the patch Domenico.  I did a big cleanup of the
> registration code for all of the basic clock types and a fix for this
> has already been rolled in to that branch, so I won't be taking this
> patch.  I'll Cc you on the fixes when I send them to the list
> (probably tomorrow).

Would it be possible for you to keep a tree in -next?  There's been
several people sending patches like this which have been superceeded by
your work and this might help avoid such duplicated work.