linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
To: Segher Boessenkool <segher@kernel.crashing.org>,
	Nicholas Piggin <npiggin@gmail.com>
Cc: syzkaller@googlegroups.com, linuxppc-dev@lists.ozlabs.org,
	dvyukov@google.com
Subject: Re: [PATCH 1/2] powerpc/64s: Work around spurious warning on old gccs with -fsanitize-coverage
Date: Fri, 8 Feb 2019 11:34:59 +1100	[thread overview]
Message-ID: <e1e1fc85-6ab6-ba91-c91f-21c3f51ee6ee@au1.ibm.com> (raw)
In-Reply-To: <20190207074947.GT14180@gate.crashing.org>

(+ Nick)

On 7/2/19 6:49 pm, Segher Boessenkool wrote:
> On Thu, Feb 07, 2019 at 05:59:48PM +1100, Andrew Donnellan wrote:
>> On 7/2/19 5:37 pm, Segher Boessenkool wrote:
>>> On Thu, Feb 07, 2019 at 04:33:23PM +1100, Andrew Donnellan wrote:
>>>> Some older gccs (<GCC 7), when invoked with -fsanitize-coverage=trace-pc,
>>>> cause a spurious uninitialised variable warning in dt_cpu_ftrs.c:
>>>>
>>>>    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)
>>>
>>> It seems to me the warning is correct?  If enable_unknown is false and no
>>> cpu_feature is found, it will in
>>>
>>> 	if (m->cpu_ftr_bit_mask)
>>> 		cur_cpu_spec->cpu_features |= m->cpu_ftr_bit_mask;
>>>
>>> enable random features (whatever was last in the table), or indeed access
>>> via NULL if the table is length 0?  So maybe this should be
>>>
>>> 	if (known && m->cpu_ftr_bit_mask)
>>> 		cur_cpu_spec->cpu_features |= m->cpu_ftr_bit_mask;
>>>
>>> instead?  (The code would be much clearer if all the known vs. !known
>>> codepath was fully separated here).
>>
>> The table is never length 0, it's a statically defined array.
> 
> Sure, and presumably that is why newer GCC doesn't warn.  But what about
> the other point?  Is this code ever correct?  Enabling random features
> (in cur_cpu_spec->cpu_features) when the name isn't found seems wrong.

Now that I'm replying without being 2 minutes before a meeting :)

The warning is still spurious, but the logic looks very suspicious.

I think your solution looks correct, though the whole function could be 
cleaned up a bit.

I also notice that if enable_unknown == false, then I think an unknown 
feature will still print "enabling" and return true, which seems wrong.

How does something like the following look, which I could send instead 
and will probably solve the spurious warnings issues anyway?

diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c 
b/arch/powerpc/kernel/dt_cpu_ftrs.c
index 2192b2114513..0f13048dc0dd 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -658,40 +658,31 @@ static void __init cpufeatures_setup_start(u32 isa)

  static bool __init cpufeatures_process_feature(struct dt_cpu_feature *f)
  {
-       const struct dt_cpu_feature_match *m = NULL;
-       bool known = false;
+       const struct dt_cpu_feature_match *m;
         int i;

         for (i = 0; i < ARRAY_SIZE(dt_cpu_feature_match_table); i++) {
                 m = &dt_cpu_feature_match_table[i];
                 if (!strcmp(f->name, m->name)) {
-                       known = true;
-                       if (m->enable(f))
-                               break;
-
-                       pr_info("not enabling: %s (disabled or 
unsupported by kernel)\n",
-                               f->name);
-                       return false;
-               }
-       }
-
-       if (!known && enable_unknown) {
-               if (!feat_try_enable_unknown(f)) {
-                       pr_info("not enabling: %s (unknown and 
unsupported by kernel)\n",
-                               f->name);
-                       return false;
+                       if (!m->enable(f)) {
+                               pr_info("not enabling: %s (disabled or 
unsupported by kernel)\n",
+                                       f->name);
+                               return false;
+                       }
+                       pr_debug("enabling: %s\n", f->name);
+                       cur_cpu_spec->cpu_features |= m->cpu_ftr_bit_mask;
+                       return true;
                 }
         }

-       if (m->cpu_ftr_bit_mask)
-               cur_cpu_spec->cpu_features |= m->cpu_ftr_bit_mask;
-
-       if (known)
-               pr_debug("enabling: %s\n", f->name);
-       else
+       if (enable_unknown && feat_try_enable_unknown(f)) {
                 pr_debug("enabling: %s (unknown)\n", f->name);
-
-       return true;
+               return true;
+       } else {
+               pr_info("not enabling: %s (unknown and unsupported by 
kernel)\n",
+                       f->name);
+               return false;
+       }
  }

  static __init void cpufeatures_cpu_quirks(void)


-- 
Andrew Donnellan              OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com  IBM Australia Limited


  reply	other threads:[~2019-02-08  0:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-07  5:33 [PATCH 1/2] powerpc/64s: Work around spurious warning on old gccs with -fsanitize-coverage Andrew Donnellan
2019-02-07  5:33 ` [PATCH 2/2] powerpc: Enable kcov Andrew Donnellan
2019-02-07  6:37 ` [PATCH 1/2] powerpc/64s: Work around spurious warning on old gccs with -fsanitize-coverage Segher Boessenkool
2019-02-07  6:59   ` Andrew Donnellan
2019-02-07  7:49     ` Segher Boessenkool
2019-02-08  0:34       ` Andrew Donnellan [this message]
2019-02-08  3:02         ` Michael Ellerman
2019-02-08  3:11           ` Andrew Donnellan
2019-02-08 15:41           ` Segher Boessenkool
2019-02-10  5:14             ` Andrew Donnellan

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=e1e1fc85-6ab6-ba91-c91f-21c3f51ee6ee@au1.ibm.com \
    --to=andrew.donnellan@au1.ibm.com \
    --cc=dvyukov@google.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=npiggin@gmail.com \
    --cc=segher@kernel.crashing.org \
    --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).