From: Nick Desaulniers <ndesaulniers@google.com>
To: Tom Rix <trix@redhat.com>
Cc: johannes@sipsolutions.net, davem@davemloft.net, kuba@kernel.org,
nathan@kernel.org, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] mac80211: initialize variable have_higher_than_11mbit
Date: Tue, 28 Dec 2021 10:55:55 -0800 [thread overview]
Message-ID: <CAKwvOdkUQARWd7qG_hkUJYuVcvObMYTif_HDSEmJ5mSXP6y1=A@mail.gmail.com> (raw)
In-Reply-To: <b3ef8d23-7c77-7c83-0bc8-2054b7ac1d8b@redhat.com>
On Fri, Dec 24, 2021 at 6:01 AM Tom Rix <trix@redhat.com> wrote:
>
>
> On 12/23/21 12:30 PM, Nick Desaulniers wrote:
> > On Thu, Dec 23, 2021 at 8:29 AM <trix@redhat.com> wrote:
> >> From: Tom Rix <trix@redhat.com>
> >>
> >> Clang static analysis reports this warnings
> >>
> >> mlme.c:5332:7: warning: Branch condition evaluates to a
> >> garbage value
> >> have_higher_than_11mbit)
> >> ^~~~~~~~~~~~~~~~~~~~~~~
> >>
> >> have_higher_than_11mbit is only set to true some of the time in
> >> ieee80211_get_rates() but is checked all of the time. So
> >> have_higher_than_11mbit needs to be initialized to false.
> > LGTM. There's only one caller of ieee80211_get_rates() today; if there
> > were others, they could make a similar mistake in the future. An
> > alternate approach: ieee80211_get_rates() could unconditionally write
> > false before the loop that could later write true. Then call sites
> > don't need to worry about this conditional assignment. Perhaps that
> > would be preferable? If not:
>
> The have_higher_than_11mbit variable had previously be initialized to false.
>
> The commit 5d6a1b069b7f moved the variable without initializing.
I'm not disagreeing with that.
My point is that these sometimes uninitialized warnings you're
finding+fixing with clang static analyzer are demonstrating a
recurring pattern with code.
When _not_ using the static analyzer, -Wuninitialized and
-Wsometimes-uninitialized work in Clang by building a control flow
graph, but they only analyze a function locally.
For example, consider the following code:
```
_Bool is_thursday(void);
void hello(int);
void init (int* x) {
if (is_thursday())
*x = 1;
}
void foo (void) {
int x;
init(&x);
hello(x);
}
```
(Clang+GCC today will warn on the above; x is considered to "escape"
the scope of foo as init could write the address of x to a global.
Instead clang's static analyzer will take the additional time to
analyze the callee. But here's a spooky question: what happens when
init is in another translation unit? IIRC, the static analyzer doesn't
do cross TU analysis; I could be wrong though, I haven't run it in a
while.)
My point is that you're sending patches initializing x, when I think
it might be nicer to instead have functions like init always write a
value (unconditionally, rather than conditionally). That way other
callers of init don't have to worry about sometimes initialized
variables.
>
> Tom
>
> >
> > Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> >
> >> Fixes: 5d6a1b069b7f ("mac80211: set basic rates earlier")
> >> Signed-off-by: Tom Rix <trix@redhat.com>
> >> ---
> >> net/mac80211/mlme.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> >> index 51f55c4ee3c6e..766cbbc9c3a72 100644
> >> --- a/net/mac80211/mlme.c
> >> +++ b/net/mac80211/mlme.c
> >> @@ -5279,7 +5279,7 @@ static int ieee80211_prep_connection(struct ieee80211_sub_if_data *sdata,
> >> */
> >> if (new_sta) {
> >> u32 rates = 0, basic_rates = 0;
> >> - bool have_higher_than_11mbit;
> >> + bool have_higher_than_11mbit = false;
> >> int min_rate = INT_MAX, min_rate_index = -1;
> >> const struct cfg80211_bss_ies *ies;
> >> int shift = ieee80211_vif_get_shift(&sdata->vif);
> >> --
> >> 2.26.3
> >>
> >
>
--
Thanks,
~Nick Desaulniers
next prev parent reply other threads:[~2021-12-28 18:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-23 16:28 [PATCH] mac80211: initialize variable have_higher_than_11mbit trix
2021-12-23 20:30 ` Nick Desaulniers
2021-12-24 14:01 ` Tom Rix
2021-12-28 18:55 ` Nick Desaulniers [this message]
2021-12-29 19:26 ` Tom Rix
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='CAKwvOdkUQARWd7qG_hkUJYuVcvObMYTif_HDSEmJ5mSXP6y1=A@mail.gmail.com' \
--to=ndesaulniers@google.com \
--cc=davem@davemloft.net \
--cc=johannes@sipsolutions.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=llvm@lists.linux.dev \
--cc=nathan@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=trix@redhat.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).