[PATCH] clk: stm32f4: avoid uninitialized variable access

[PATCH] clk: stm32f4: avoid uninitialized variable access

[Arnd Bergmann]

The failure path in the newly added function tries to free an
uninitialized pointer:

drivers/clk/clk-stm32f4.c: In function 'stm32f4_rcc_init':
drivers/clk/clk-stm32f4.c:1106:4: error: 'gate' may be used uninitialized in this function [-Werror=maybe-uninitialized]

I'm adding an initialization to NULL here to make the kfree()
succeed, and I'm also rearranging the cleanup so that the
same kfree() is used for any error path, making the function
slightly more robust against newly introduced bugs in the
error handling.

Fixes: daf2d117cbca ("clk: stm32f4: Add lcd-tft clock")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/clk/clk-stm32f4.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
index 42f8534996de..4a3bb6e63525 100644
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -1080,7 +1080,7 @@ static struct clk_hw *stm32_register_aux_clk(const char *name,
 		unsigned long flags, spinlock_t *lock)
 {
 	struct clk_hw *hw;
-	struct clk_gate *gate;
+	struct clk_gate *gate = NULL;
 	struct clk_mux *mux = NULL;
 	struct clk_hw *mux_hw = NULL, *gate_hw = NULL;
 	const struct clk_ops *mux_ops = NULL, *gate_ops = NULL;
@@ -1103,7 +1103,6 @@ static struct clk_hw *stm32_register_aux_clk(const char *name,
 	if (offset_mux != NO_MUX) {
 		mux = kzalloc(sizeof(*mux), GFP_KERNEL);
 		if (!mux) {
-			kfree(gate);
 			hw = ERR_PTR(-EINVAL);
 			goto fail;
 		}
@@ -1116,8 +1115,10 @@ static struct clk_hw *stm32_register_aux_clk(const char *name,
 		mux_ops = &clk_mux_ops;
 	}
 
-	if (mux_hw == NULL && gate_hw == NULL)
-		return ERR_PTR(-EINVAL);
+	if (mux_hw == NULL && gate_hw == NULL) {
+		hw = ERR_PTR(-EINVAL);
+		goto fail;
+	}
 
 	hw = clk_hw_register_composite(NULL, name, parent_names, num_parents,
 			mux_hw, mux_ops,
@@ -1125,11 +1126,12 @@ static struct clk_hw *stm32_register_aux_clk(const char *name,
 			gate_hw, gate_ops,
 			flags);
 
+fail:
 	if (IS_ERR(hw)) {
 		kfree(gate);
 		kfree(mux);
 	}
-fail:
+
 	return hw;
 }
 
-- 
2.9.0

[PATCH] clk: stm32f4: avoid uninitialized variable access

[Arnd Bergmann]

The failure path in the newly added function tries to free an
uninitialized pointer:

drivers/clk/clk-stm32f4.c: In function 'stm32f4_rcc_init':
drivers/clk/clk-stm32f4.c:1106:4: error: 'gate' may be used uninitialized in this function [-Werror=maybe-uninitialized]

I'm adding an initialization to NULL here to make the kfree()
succeed, and I'm also rearranging the cleanup so that the
same kfree() is used for any error path, making the function
slightly more robust against newly introduced bugs in the
error handling.

Fixes: daf2d117cbca ("clk: stm32f4: Add lcd-tft clock")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/clk/clk-stm32f4.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
index 42f8534996de..4a3bb6e63525 100644
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -1080,7 +1080,7 @@ static struct clk_hw *stm32_register_aux_clk(const char *name,
 		unsigned long flags, spinlock_t *lock)
 {
 	struct clk_hw *hw;
-	struct clk_gate *gate;
+	struct clk_gate *gate = NULL;
 	struct clk_mux *mux = NULL;
 	struct clk_hw *mux_hw = NULL, *gate_hw = NULL;
 	const struct clk_ops *mux_ops = NULL, *gate_ops = NULL;
@@ -1103,7 +1103,6 @@ static struct clk_hw *stm32_register_aux_clk(const char *name,
 	if (offset_mux != NO_MUX) {
 		mux = kzalloc(sizeof(*mux), GFP_KERNEL);
 		if (!mux) {
-			kfree(gate);
 			hw = ERR_PTR(-EINVAL);
 			goto fail;
 		}
@@ -1116,8 +1115,10 @@ static struct clk_hw *stm32_register_aux_clk(const char *name,
 		mux_ops = &clk_mux_ops;
 	}
 
-	if (mux_hw == NULL && gate_hw == NULL)
-		return ERR_PTR(-EINVAL);
+	if (mux_hw == NULL && gate_hw == NULL) {
+		hw = ERR_PTR(-EINVAL);
+		goto fail;
+	}
 
 	hw = clk_hw_register_composite(NULL, name, parent_names, num_parents,
 			mux_hw, mux_ops,
@@ -1125,11 +1126,12 @@ static struct clk_hw *stm32_register_aux_clk(const char *name,
 			gate_hw, gate_ops,
 			flags);
 
+fail:
 	if (IS_ERR(hw)) {
 		kfree(gate);
 		kfree(mux);
 	}
-fail:
+
 	return hw;
 }
 
-- 
2.9.0

Re: [PATCH] clk: stm32f4: avoid uninitialized variable access

[Gabriel Fernandez]

On 01/11/2017 02:40 PM, Arnd Bergmann wrote:
> The failure path in the newly added function tries to free an
> uninitialized pointer:
>
> drivers/clk/clk-stm32f4.c: In function 'stm32f4_rcc_init':
> drivers/clk/clk-stm32f4.c:1106:4: error: 'gate' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> I'm adding an initialization to NULL here to make the kfree()
> succeed, and I'm also rearranging the cleanup so that the
> same kfree() is used for any error path, making the function
> slightly more robust against newly introduced bugs in the
> error handling.
>
> Fixes: daf2d117cbca ("clk: stm32f4: Add lcd-tft clock")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>   drivers/clk/clk-stm32f4.c | 12 +++++++-----
>   1 file changed, 7 insertions(+), 5 deletions(-)
>
>
Acked-by: Gabriel Fernandez <gabriel.fernandez@st.com>

[PATCH] clk: stm32f4: avoid uninitialized variable access

[Gabriel Fernandez]

On 01/11/2017 02:40 PM, Arnd Bergmann wrote:
> The failure path in the newly added function tries to free an
> uninitialized pointer:
>
> drivers/clk/clk-stm32f4.c: In function 'stm32f4_rcc_init':
> drivers/clk/clk-stm32f4.c:1106:4: error: 'gate' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> I'm adding an initialization to NULL here to make the kfree()
> succeed, and I'm also rearranging the cleanup so that the
> same kfree() is used for any error path, making the function
> slightly more robust against newly introduced bugs in the
> error handling.
>
> Fixes: daf2d117cbca ("clk: stm32f4: Add lcd-tft clock")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>   drivers/clk/clk-stm32f4.c | 12 +++++++-----
>   1 file changed, 7 insertions(+), 5 deletions(-)
>
>
Acked-by: Gabriel Fernandez <gabriel.fernandez@st.com>

Re: [PATCH] clk: stm32f4: avoid uninitialized variable access

[Stephen Boyd]

On 01/11, Arnd Bergmann wrote:
> The failure path in the newly added function tries to free an
> uninitialized pointer:
> 
> drivers/clk/clk-stm32f4.c: In function 'stm32f4_rcc_init':
> drivers/clk/clk-stm32f4.c:1106:4: error: 'gate' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> I'm adding an initialization to NULL here to make the kfree()
> succeed, and I'm also rearranging the cleanup so that the
> same kfree() is used for any error path, making the function
> slightly more robust against newly introduced bugs in the
> error handling.
> 
> Fixes: daf2d117cbca ("clk: stm32f4: Add lcd-tft clock")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---

Applied to clk-next. Seems I need to update my compiler to find
these warnings.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] clk: stm32f4: avoid uninitialized variable access

[Stephen Boyd]

On 01/11, Arnd Bergmann wrote:
> The failure path in the newly added function tries to free an
> uninitialized pointer:
> 
> drivers/clk/clk-stm32f4.c: In function 'stm32f4_rcc_init':
> drivers/clk/clk-stm32f4.c:1106:4: error: 'gate' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> I'm adding an initialization to NULL here to make the kfree()
> succeed, and I'm also rearranging the cleanup so that the
> same kfree() is used for any error path, making the function
> slightly more robust against newly introduced bugs in the
> error handling.
> 
> Fixes: daf2d117cbca ("clk: stm32f4: Add lcd-tft clock")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---

Applied to clk-next. Seems I need to update my compiler to find
these warnings.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: stm32f4: avoid uninitialized variable access

[Arnd Bergmann]

On Thu, Jan 12, 2017 at 11:06 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>
> Applied to clk-next. Seems I need to update my compiler to find
> these warnings.

I'm currently playing with gcc-7, which adds a lot of new warnings
(including many false positives). gcc-6 was supposed to have better
warnings than 5, but I didn't find the difference that noticeable. 5
or 6 is probably best at the moment, and if you have at least 4.9
there is no urgent need to upgrade.

    Arnd

[PATCH] clk: stm32f4: avoid uninitialized variable access

[Arnd Bergmann]

On Thu, Jan 12, 2017 at 11:06 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>
> Applied to clk-next. Seems I need to update my compiler to find
> these warnings.

I'm currently playing with gcc-7, which adds a lot of new warnings
(including many false positives). gcc-6 was supposed to have better
warnings than 5, but I didn't find the difference that noticeable. 5
or 6 is probably best at the moment, and if you have at least 4.9
there is no urgent need to upgrade.

    Arnd

Re: [PATCH] clk: stm32f4: avoid uninitialized variable access

[Stephen Boyd]

On 01/12/2017 02:42 PM, Arnd Bergmann wrote:
> On Thu, Jan 12, 2017 at 11:06 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> Applied to clk-next. Seems I need to update my compiler to find
>> these warnings.
> I'm currently playing with gcc-7, which adds a lot of new warnings
> (including many false positives). gcc-6 was supposed to have better
> warnings than 5, but I didn't find the difference that noticeable. 5
> or 6 is probably best at the moment, and if you have at least 4.9
> there is no urgent need to upgrade.

Thanks. I'm on gcc-4.7. It's been a long time since I upgraded my cross
compiler.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] clk: stm32f4: avoid uninitialized variable access

[Stephen Boyd]

On 01/12/2017 02:42 PM, Arnd Bergmann wrote:
> On Thu, Jan 12, 2017 at 11:06 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> Applied to clk-next. Seems I need to update my compiler to find
>> these warnings.
> I'm currently playing with gcc-7, which adds a lot of new warnings
> (including many false positives). gcc-6 was supposed to have better
> warnings than 5, but I didn't find the difference that noticeable. 5
> or 6 is probably best at the moment, and if you have at least 4.9
> there is no urgent need to upgrade.

Thanks. I'm on gcc-4.7. It's been a long time since I upgraded my cross
compiler.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project