linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@c-s.fr>
To: Nathan Chancellor <natechancellor@gmail.com>
Cc: Tyrel Datwyler <tyreld@linux.ibm.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	clang-built-linux@googlegroups.com,
	Paul Mackerras <paulus@samba.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] PCI: rpaphp: Avoid a sometimes-uninitialized warning
Date: Tue, 04 Jun 2019 08:24:39 +0200	[thread overview]
Message-ID: <20190604082439.Horde.tWsSNlWiTjwbZIMIFhnFcQ5@messagerie.c-s.fr> (raw)
In-Reply-To: <20190603174323.48251-1-natechancellor@gmail.com>


Quoting Nathan Chancellor <natechancellor@gmail.com>:

> When building with -Wsometimes-uninitialized, clang warns:
>
> drivers/pci/hotplug/rpaphp_core.c:243:14: warning: variable 'fndit' is
> used uninitialized whenever 'for' loop exits because its condition is
> false [-Wsometimes-uninitialized]
>         for (j = 0; j < entries; j++) {
>                     ^~~~~~~~~~~
> drivers/pci/hotplug/rpaphp_core.c:256:6: note: uninitialized use occurs
> here
>         if (fndit)
>             ^~~~~
> drivers/pci/hotplug/rpaphp_core.c:243:14: note: remove the condition if
> it is always true
>         for (j = 0; j < entries; j++) {
>                     ^~~~~~~~~~~
> drivers/pci/hotplug/rpaphp_core.c:233:14: note: initialize the variable
> 'fndit' to silence this warning
>         int j, fndit;
>                     ^
>                      = 0
>
> Looking at the loop in a vacuum as clang would, fndit could be
> uninitialized if entries was ever zero or the if statement was
> always true within the loop. Regardless of whether or not this
> warning is a problem in practice, "found" variables should always
> be initialized to false so that there is no possibility of
> undefined behavior.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/504
> Fixes: 2fcf3ae508c2 ("hotplug/drc-info: Add code to search  
> ibm,drc-info property")
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
>  drivers/pci/hotplug/rpaphp_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/hotplug/rpaphp_core.c  
> b/drivers/pci/hotplug/rpaphp_core.c
> index bcd5d357ca23..07b56bf2886f 100644
> --- a/drivers/pci/hotplug/rpaphp_core.c
> +++ b/drivers/pci/hotplug/rpaphp_core.c
> @@ -230,7 +230,7 @@ static int rpaphp_check_drc_props_v2(struct  
> device_node *dn, char *drc_name,
>  	struct of_drc_info drc;
>  	const __be32 *value;
>  	char cell_drc_name[MAX_DRC_NAME_LEN];
> -	int j, fndit;
> +	int j, fndit = 0;

Not sure fndit is needed at all. Looking into the full function code,  
fndit only serves as doing a single action. That action could be done  
in the loop directly, see below

And while you are at it, I guess you should also handle the  
initialisation of cell_drc_name.
In the current code, it looks like content of cell_drc_name is  
undefined when doing the strcmp when fndit is not 1.

>
>  	info = of_find_property(dn->parent, "ibm,drc-info", NULL);
>  	if (info == NULL)
> --
> 2.22.0.rc2

diff --git a/drivers/pci/hotplug/rpaphp_core.c  
b/drivers/pci/hotplug/rpaphp_core.c
index bcd5d357ca23..87113419a44f 100644
--- a/drivers/pci/hotplug/rpaphp_core.c
+++ b/drivers/pci/hotplug/rpaphp_core.c
@@ -230,7 +230,7 @@ static int rpaphp_check_drc_props_v2(struct  
device_node *dn, char *drc_name,
  	struct of_drc_info drc;
  	const __be32 *value;
  	char cell_drc_name[MAX_DRC_NAME_LEN];
-	int j, fndit;
+	int j;

  	info = of_find_property(dn->parent, "ibm,drc-info", NULL);
  	if (info == NULL)
@@ -248,14 +248,10 @@ static int rpaphp_check_drc_props_v2(struct  
device_node *dn, char *drc_name,
  		if (my_index > drc.last_drc_index)
  			continue;

-		fndit = 1;
+		/* Found it */
+		sprintf(cell_drc_name, "%s%d", drc.drc_name_prefix, my_index);
  		break;
  	}
-	/* Found it */
-
-	if (fndit)
-		sprintf(cell_drc_name, "%s%d", drc.drc_name_prefix,
-			my_index);

  	if (((drc_name == NULL) ||
  	     (drc_name && !strcmp(drc_name, cell_drc_name))) &&

Christophe

      parent reply	other threads:[~2019-06-04  6:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-03 17:43 [PATCH] PCI: rpaphp: Avoid a sometimes-uninitialized warning Nathan Chancellor
2019-06-03 21:07 ` Nick Desaulniers
2019-06-03 21:51   ` Nathan Chancellor
2019-06-03 22:11 ` [PATCH v2] " Nathan Chancellor
2019-06-04  0:03   ` Tyrel Datwyler
2019-06-27 19:18   ` Nathan Chancellor
2019-06-28  2:57   ` Joel Savitz
2019-07-22  2:43   ` Nathan Chancellor
2019-07-22  4:05     ` Michael Ellerman
2019-08-02  0:11       ` Bjorn Helgaas
2019-08-02 12:24         ` Michael Ellerman
2019-08-10 10:20   ` Michael Ellerman
2019-06-04  6:24 ` Christophe Leroy [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=20190604082439.Horde.tWsSNlWiTjwbZIMIFhnFcQ5@messagerie.c-s.fr \
    --to=christophe.leroy@c-s.fr \
    --cc=bhelgaas@google.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=natechancellor@gmail.com \
    --cc=paulus@samba.org \
    --cc=tyreld@linux.ibm.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).