diff mbox series

stackleak: Remove unnecessary ‘0’ values from ret

Message ID 20231017060824.10434-1-zeming@nfschina.com
State New
Headers
Series stackleak: Remove unnecessary ‘0’ values from ret |

Commit Message

Li zeming Oct. 17, 2023, 6:08 a.m. UTC 
  ret is assigned first, so it does not need to initialize the assignment.

Signed-off-by: Li zeming <zeming@nfschina.com>
---
 kernel/stackleak.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Mark Rutland Oct. 17, 2023, 10:14 a.m. UTC | #1 
On Tue, Oct 17, 2023 at 02:08:24PM +0800, Li zeming wrote:
> ret is assigned first, so it does not need to initialize the assignment.
> 
> Signed-off-by: Li zeming <zeming@nfschina.com>

Does this actually need to change? It's not harmful, and deleting the
assignment doesn't save any lines of code.

That said, I don't have strong feelings either way, and Kees is the
de-facto-yet-undocumented maintainer for this code, so I will leave it to him
to decide whether to apply.

Mark.

> ---
>  kernel/stackleak.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/stackleak.c b/kernel/stackleak.c
> index 34c9d81eea940..3faf863593846 100644
> --- a/kernel/stackleak.c
> +++ b/kernel/stackleak.c
> @@ -24,7 +24,7 @@ static DEFINE_STATIC_KEY_FALSE(stack_erasing_bypass);
>  static int stack_erasing_sysctl(struct ctl_table *table, int write,
>  			void __user *buffer, size_t *lenp, loff_t *ppos)
>  {
> -	int ret = 0;
> +	int ret;
>  	int state = !static_branch_unlikely(&stack_erasing_bypass);
>  	int prev_state = state;
>  
> -- 
> 2.18.2
>
Kees Cook Oct. 19, 2023, 12:39 a.m. UTC | #2 
On Tue, Oct 17, 2023 at 11:14:43AM +0100, Mark Rutland wrote:
> On Tue, Oct 17, 2023 at 02:08:24PM +0800, Li zeming wrote:
> > ret is assigned first, so it does not need to initialize the assignment.
> > 
> > Signed-off-by: Li zeming <zeming@nfschina.com>
> 
> Does this actually need to change? It's not harmful, and deleting the
> assignment doesn't save any lines of code.

I prefer explicit initialization. Any unused initialization will be
optimized away by the compiler during Dead Store Elimination, so all
removing the initialization does is make the code more fragile in the
future.

> That said, I don't have strong feelings either way, and Kees is the
> de-facto-yet-undocumented maintainer for this code, so I will leave it to him
> to decide whether to apply.

Oh, hm, good point. I will add a MAINTAINER entry for it. Thanks!

-Kees
Guenter Roeck Nov. 1, 2023, 4:03 a.m. UTC | #3 
On Wed, Oct 18, 2023 at 05:39:21PM -0700, Kees Cook wrote:
> On Tue, Oct 17, 2023 at 11:14:43AM +0100, Mark Rutland wrote:
> > On Tue, Oct 17, 2023 at 02:08:24PM +0800, Li zeming wrote:
> > > ret is assigned first, so it does not need to initialize the assignment.
> > > 
> > > Signed-off-by: Li zeming <zeming@nfschina.com>
> > 
> > Does this actually need to change? It's not harmful, and deleting the
> > assignment doesn't save any lines of code.
> 
> I prefer explicit initialization. Any unused initialization will be
> optimized away by the compiler during Dead Store Elimination, so all
> removing the initialization does is make the code more fragile in the
> future.
> 

Also, be careful with those submissions, and do not take the claim
in the commit message at face value. Several of them introduce
uninitialize variable errors. I had two submissions for the watchdog
subsystem, and both of them were wrong.

Guenter
diff mbox series

Patch

diff --git a/kernel/stackleak.c b/kernel/stackleak.c
index 34c9d81eea940..3faf863593846 100644
--- a/kernel/stackleak.c
+++ b/kernel/stackleak.c
@@ -24,7 +24,7 @@  static DEFINE_STATIC_KEY_FALSE(stack_erasing_bypass);
 static int stack_erasing_sysctl(struct ctl_table *table, int write,
 			void __user *buffer, size_t *lenp, loff_t *ppos)
 {
-	int ret = 0;
+	int ret;
 	int state = !static_branch_unlikely(&stack_erasing_bypass);
 	int prev_state = state;