[Linux-kernel-mentees] checkpatch.pl investigation: NO_AUTHOR_SIGN_OFF issues

Lukas Bulwahn lukas.bulwahn at gmail.com
Mon Sep 28 14:09:18 UTC 2020



On Mon, 28 Sep 2020, Dwaipayan Ray wrote:

> Hi,
> I am continuing this thread, but am writing about another issue
> separate from author sign off. While checking checkpatch
> output, I was checking the commits with the warnings:
>

How about just starting a new thread instead?

I will answer on the new thread.

Lukas
 
> WARNING:UNNECESSARY_ELSE: else is not generally
>  useful after a break or return
> 
> Looking into the referenced section, I found some
> sections with a redundant else.
> 
> For example: (revision 196273fffc1c),
> arch/powerpc/kernel/security.c , line 360:
> 
> static int ssb_prctl_get(struct task_struct *task)
> {
> if (stf_enabled_flush_types == STF_BARRIER_NONE)
> /*
> * We don't have an explicit signal from firmware that we're
> * vulnerable or not, we only have certain CPU revisions that
> * are known to be vulnerable.
> *
> * We assume that if we're on another CPU, where the barrier is
> * NONE, then we are not vulnerable.
> */
> return PR_SPEC_NOT_AFFECTED;
> else
> /*
> * If we do have a barrier type then we are vulnerable. The
> * barrier is not a global or per-process mitigation, so the
> * only value we can report here is PR_SPEC_ENABLE, which
> * appears as "vulnerable" in /proc.
> */
> return PR_SPEC_ENABLE;
> 
> return -EINVAL;
> }
> 
> The else is pretty much redundant and the control flow
> never reaches to return -EINVAL.
> 
> Is it possible to clean up all these redundant code?
> 
> Thanks,
> Dwaipayan.
> 


More information about the Linux-kernel-mentees mailing list