2013-01-25 14:15:21

by Arnd Bergmann

Subject: [PATCH 16/19] mac80211: avoid a build warning

gcc cannot prove that the value of sdata->vif.type does not
change between the switch() statement and the second
comparison to NL80211_IFTYPE_AP, causing a harmless
warning.
Slightly reordering the code makes the warning go away
with no functional change.

Without this patch, building ARM at91sam9g45_defconfig with
gcc-4.6 results in:

net/mac80211/tx.c: In function 'ieee80211_subif_start_xmit':
net/mac80211/tx.c:1797:22: warning: 'chanctx_conf' may be used uninitialized in this function [-Wuninitialized]

Signed-off-by: Arnd Bergmann <[email protected]>
Cc: Johannes Berg <[email protected]>
Cc: "John W. Linville" <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: [email protected]
Cc: [email protected]
---
net/mac80211/tx.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index e9eadc4..df589bf 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1784,16 +1784,16 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
break;
/* fall through */
case NL80211_IFTYPE_AP:
+ if (sdata->vif.type == NL80211_IFTYPE_AP)
+ chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
+ if (!chanctx_conf)
+ goto fail_rcu;
fc |= cpu_to_le16(IEEE80211_FCTL_FROMDS);
/* DA BSSID SA */
memcpy(hdr.addr1, skb->data, ETH_ALEN);
memcpy(hdr.addr2, sdata->vif.addr, ETH_ALEN);
memcpy(hdr.addr3, skb->data + ETH_ALEN, ETH_ALEN);
hdrlen = 24;
- if (sdata->vif.type == NL80211_IFTYPE_AP)
- chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
- if (!chanctx_conf)
- goto fail_rcu;
band = chanctx_conf->def.chan->band;
break;
case NL80211_IFTYPE_WDS:
--
1.8.0

2013-01-25 14:17:42

by Johannes Berg

Subject: Re: [PATCH 16/19] mac80211: avoid a build warning

On Fri, 2013-01-25 at 14:14 +0000, Arnd Bergmann wrote:
> gcc cannot prove that the value of sdata->vif.type does not
> change between the switch() statement and the second
> comparison to NL80211_IFTYPE_AP, causing a harmless
> warning.
> Slightly reordering the code makes the warning go away
> with no functional change.

Thanks!

Applied.

johannes