From: Yibo Zhao <yiboz@codeaurora.org> To: linux-wireless@vger.kernel.org Cc: ath10k@lists.infradead.org, Yibo Zhao <yiboz@codeaurora.org>, Zhi Chen <zhichen@codeaurora.org> Subject: [PATCH v2] mac80211: remove warning message Date: Tue, 14 May 2019 17:01:47 +0800 [thread overview] Message-ID: <1557824507-17668-1-git-send-email-yiboz@codeaurora.org> (raw) In multiple SSID cases, it takes time to prepare every AP interface to be ready in initializing phase. If a sta already knows everything it needs to join one of the APs and sends authentication to the AP which is not fully prepared at this point of time, AP's channel context could be NULL. As a result, warning message occurs. Even worse, if the AP is under attack via tools such as MDK3 and massive authentication requests are received in a very short time, console will be hung due to kernel warning messages. If this case can be hit during normal functionality, there should be no WARN_ON(). Those should be reserved to cases that are not supposed to be hit at all or some other more specific cases like indicating obsolete interface. Signed-off-by: Zhi Chen <zhichen@codeaurora.org> Signed-off-by: Yibo Zhao <yiboz@codeaurora.org> --- net/mac80211/ieee80211_i.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h index 073a823..f39c289 100644 --- a/net/mac80211/ieee80211_i.h +++ b/net/mac80211/ieee80211_i.h @@ -1435,7 +1435,7 @@ struct ieee80211_local { rcu_read_lock(); chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf); - if (WARN_ON(!chanctx_conf)) { + if (!chanctx_conf) { rcu_read_unlock(); return NULL; } -- 1.9.1
WARNING: multiple messages have this Message-ID (diff)
From: Yibo Zhao <yiboz@codeaurora.org> To: linux-wireless@vger.kernel.org Cc: Zhi Chen <zhichen@codeaurora.org>, Yibo Zhao <yiboz@codeaurora.org>, ath10k@lists.infradead.org Subject: [PATCH v2] mac80211: remove warning message Date: Tue, 14 May 2019 17:01:47 +0800 [thread overview] Message-ID: <1557824507-17668-1-git-send-email-yiboz@codeaurora.org> (raw) In multiple SSID cases, it takes time to prepare every AP interface to be ready in initializing phase. If a sta already knows everything it needs to join one of the APs and sends authentication to the AP which is not fully prepared at this point of time, AP's channel context could be NULL. As a result, warning message occurs. Even worse, if the AP is under attack via tools such as MDK3 and massive authentication requests are received in a very short time, console will be hung due to kernel warning messages. If this case can be hit during normal functionality, there should be no WARN_ON(). Those should be reserved to cases that are not supposed to be hit at all or some other more specific cases like indicating obsolete interface. Signed-off-by: Zhi Chen <zhichen@codeaurora.org> Signed-off-by: Yibo Zhao <yiboz@codeaurora.org> --- net/mac80211/ieee80211_i.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h index 073a823..f39c289 100644 --- a/net/mac80211/ieee80211_i.h +++ b/net/mac80211/ieee80211_i.h @@ -1435,7 +1435,7 @@ struct ieee80211_local { rcu_read_lock(); chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf); - if (WARN_ON(!chanctx_conf)) { + if (!chanctx_conf) { rcu_read_unlock(); return NULL; } -- 1.9.1 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
next reply other threads:[~2019-05-14 9:02 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-14 9:01 Yibo Zhao [this message] 2019-05-14 9:01 ` [PATCH v2] mac80211: remove warning message Yibo Zhao 2019-05-14 9:05 ` Johannes Berg 2019-05-14 9:05 ` Johannes Berg 2019-05-14 9:10 ` Yibo Zhao 2019-05-14 9:10 ` Yibo Zhao 2019-05-14 9:12 ` Johannes Berg 2019-05-14 9:12 ` Johannes Berg 2019-05-14 15:44 ` Joe Perches 2019-05-14 15:44 ` Joe Perches 2019-05-14 17:55 ` Ben Greear 2019-05-14 17:55 ` Ben Greear 2019-05-14 18:40 ` Johannes Berg 2019-05-14 18:40 ` Johannes Berg 2019-05-14 18:54 ` Ben Greear 2019-05-14 18:54 ` Ben Greear 2019-05-14 18:57 ` Johannes Berg 2019-05-14 18:57 ` Johannes Berg 2019-05-20 13:56 ` Yibo Zhao 2019-05-20 13:56 ` Yibo Zhao 2019-06-14 2:52 ` Yibo Zhao 2019-06-14 2:52 ` Yibo Zhao 2019-06-14 7:22 ` Johannes Berg 2019-06-14 7:22 ` Johannes Berg
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=1557824507-17668-1-git-send-email-yiboz@codeaurora.org \ --to=yiboz@codeaurora.org \ --cc=ath10k@lists.infradead.org \ --cc=linux-wireless@vger.kernel.org \ --cc=zhichen@codeaurora.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.