On 2021-11-26 03:23, Johannes Berg wrote:
On Tue, 2021-10-05 at 21:09 -0700, Aloka Dixit wrote:
+static struct sk_buff *
+ieee80211_beacon_get_ap_mbssid(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ieee80211_mutable_offsets *offs,
+ bool is_template,
+ struct beacon_data *beacon,
+ struct ieee80211_chanctx_conf *chanctx_conf,
+ int ema_index,
+ struct list_head *ema_list)
This function is called from ieee80211_beacon_get_ap(). That's called
from __ieee80211_beacon_get(), under RCU read lock.
+ for (i = 0; i < beacon->mbssid_ies->cnt; i++) {
+ struct ieee80211_ema_bcns *bcn;
+
+ bcn = kzalloc(sizeof(*bcn), GFP_KERNEL);
Therefore, you really cannot GFP_KERNEL allocate anything. But I really
only saw this because I went back to my comments on v12 where this was
still more obvious.
Okay, I understand now that it is illegal because GFP_KERNEL is
blocking.
I thought of following:
lock rcu -> get mbssid count first -> unlock rcu -> allocate memory.
But in that case, will have again: lock -> dereference to get beacon
snapshot.
Beacon can change in between so new count might be wrong. In general
sounds complicated and wrong.
I read that GFP_ATOMIC should be used sparingly, mainly for interrupt
handlers etc.
Do you think this code path warrants its use?
Or should I look for some other function split?
Will add hwsim test cases before the next version but I genuinely did
not see any issue during testing with current code.
So can you tell me which debug flags should be enabled to make such
errors become obvious to someone like me who is new to these details in
kernel programming?
Thanks!!
