From: Michael Ellerman <patch-notifications@ellerman.id.au>
To: Andrew Donnellan <andrew.donnellan@au1.ibm.com>,
linuxppc-dev@lists.ozlabs.org
Cc: syzkaller@googlegroups.com, dvyukov@google.com, npiggin@gmail.com
Subject: Re: [v2, 1/2] powerpc/64s: Fix logic when handling unknown CPU features
Date: Fri, 22 Feb 2019 20:47:51 +1100 (AEDT) [thread overview]
Message-ID: <445RN8200mz9s9y@ozlabs.org> (raw)
In-Reply-To: <20190211002002.26038-1-andrew.donnellan@au1.ibm.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1599 bytes --]
On Mon, 2019-02-11 at 00:20:01 UTC, Andrew Donnellan wrote:
> From: Michael Ellerman <mpe@ellerman.id.au>
>
> In cpufeatures_process_feature(), if a provided CPU feature is unknown and
> enable_unknown is false, we erroneously print that the feature is being
> enabled and return true, even though no feature has been enabled, and
> may also set feature bits based on the last entry in the match table.
>
> Fix this so that we only set feature bits from the match table if we have
> actually enabled a feature from that table, and when failing to enable an
> unknown feature, always print the "not enabling" message and return false.
>
> Coincidentally, some older gccs (<GCC 7), when invoked with
> -fsanitize-coverage=trace-pc, cause a spurious uninitialised variable
> warning in this function:
>
> arch/powerpc/kernel/dt_cpu_ftrs.c: In function ‘cpufeatures_process_feature’:
> arch/powerpc/kernel/dt_cpu_ftrs.c:686:7: warning: ‘m’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> if (m->cpu_ftr_bit_mask)
>
> An upcoming patch will enable support for kcov, which requires this option.
> This patch avoids the warning.
>
> Fixes: 5a61ef74f269 ("powerpc/64s: Support new device tree binding for discovering CPU features")
> Reported-by: Segher Boessenkool <segher@kernel.crashing.org>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> [ajd: add commit message]
> Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/8cfaf106918a8c13abb24c641556172a
cheers
prev parent reply other threads:[~2019-02-22 10:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-11 0:20 [PATCH v2 1/2] powerpc/64s: Fix logic when handling unknown CPU features Andrew Donnellan
2019-02-11 0:20 ` [PATCH v2 2/2] powerpc: Enable kcov Andrew Donnellan
2019-02-20 4:26 ` Daniel Axtens
2019-02-20 4:47 ` Andrew Donnellan
2019-02-22 9:47 ` Michael Ellerman [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=445RN8200mz9s9y@ozlabs.org \
--to=patch-notifications@ellerman.id.au \
--cc=andrew.donnellan@au1.ibm.com \
--cc=dvyukov@google.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=npiggin@gmail.com \
--cc=syzkaller@googlegroups.com \
/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;
as well as URLs for NNTP newsgroup(s).