From: Valentin Schneider <valentin.schneider@arm.com>
To: Qian Cai <cai@lca.pw>, mingo@redhat.com, peterz@infradead.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched/core: silence a warning in sched_init()
Date: Mon, 24 Jun 2019 18:24:37 +0100 [thread overview]
Message-ID: <83e9a20d-bec6-72dd-2210-e019339fdb2a@arm.com> (raw)
In-Reply-To: <1561384781-12308-1-git-send-email-cai@lca.pw>
On 24/06/2019 14:59, Qian Cai wrote:
> Compiling a kernel with both FAIR_GROUP_SCHED=n and RT_GROUP_SCHED=n
> will generate a warning using W=1,
>
> kernel/sched/core.c: In function 'sched_init':
> kernel/sched/core.c:5906:32: warning: variable 'ptr' set but not used
> [-Wunused-but-set-variable]
> unsigned long alloc_size = 0, ptr;
> ^~~
>
> It apparently the maintainers don't like the proper fix [1] which
> contains ugly idefs, so silence it by appending the __maybe_unused
> attribute for it instead.
>
As you say, ifdefs are ugly. I try to stay away from them as much as
possible (as you may have noticed with the NOHZ stuff). They just make
code harder to read (I know someone who'd say "it's free code obfuscation"),
and that is especially true in the patch you reference where it conditions
variable declaration.
So it may not have been the "proper" fix after all...
> [1] https://lore.kernel.org/lkml/1559681162-5385-1-git-send-email-cai@lca.pw/
>
> Signed-off-by: Qian Cai <cai@lca.pw>
> ---
> kernel/sched/core.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 874c427742a9..9bbad91b3f01 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5903,7 +5903,10 @@ int in_sched_functions(unsigned long addr)
> void __init sched_init(void)
> {
> int i, j;
> - unsigned long alloc_size = 0, ptr;
> + unsigned long alloc_size = 0;
> +
> + /* To silence a -Wunused-but-set-variable warning. */
> + unsigned long ptr __maybe_unused;
>
To be super nitpicky, I'd argue the __maybe_unused attribute should be
placed before the variable name - the kernel/sched/* code goes with
prefixing rather than postfixing (there is *one* exception in deadline.c),
and I personally prefer prefixing as well (it just reads better).
To be (still, but slightly less) nitpicky, I'd remove the added newline
(keep the variable declaration as a single block) and even remove the
comment - it's redundant with the attribute.
With those changes:
Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
> wait_bit_init();
>
>
prev parent reply other threads:[~2019-06-24 17:24 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-24 13:59 Qian Cai
2019-06-24 17:24 ` Valentin Schneider [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83e9a20d-bec6-72dd-2210-e019339fdb2a@arm.com \
--to=valentin.schneider@arm.com \
--cc=cai@lca.pw \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®