ret is assigned first, so it does not need to initialize the assignment.
Signed-off-by: Li zeming <[email protected]>
---
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
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 <[email protected]>
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
>
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 <[email protected]>
>
> 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
--
Kees Cook
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 <[email protected]>
> >
> > 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