From: Johannes Berg <johannes@sipsolutions.net>
To: Aloka Dixit <alokad@codeaurora.org>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [v13 2/3] mac80211: MBSSID and EMA beacon handling in AP mode
Date: Fri, 14 Jan 2022 21:12:10 +0100 [thread overview]
Message-ID: <ebb1ddc51e6e0eff436de50cbbddec77d61af495.camel@sipsolutions.net> (raw)
In-Reply-To: <d2c980b72af1488282f18e8b1814b56c@codeaurora.org>
Hi!
>
> > 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.
Right.
> 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.
Indeed. You could make it work (and count changing is highly unlikely!)
by going back and checking if the count was correct in the critical
section, and then going back if necessary (i.e. if it was wrong). But if
you do this, you should do something like this pseudo-code:
rcu_read_lock();
repeat:
calculated_size = calculate_size();
rcu_read_unlock();
alloc = kzalloc(calculated_size, GFP_KERNEL);
// omitting error handling
rcu_read_lock();
calculated_size = calculate_size();
if (ksize(alloc) < calculated_size)
goto repeat;
...
i.e. note the ksize(), since allocations are rounded up. Even if the
count increased, you might not need a new allocation.
Also maybe anyway it'd make sense to allocate all of them together as an
array, rather than individual pointers for each beacon?
> I read that GFP_ATOMIC should be used sparingly, mainly for interrupt
> handlers etc.
I guess once every beacon is still fairly sparingly though :)
> 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.
Sounds great, thanks!
> 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?
Hmm. I guess you want at least CONFIG_DEBUG_ATOMIC_SLEEP for this case.
But probably best to (also) turn on lockdep (CONFIG_PROVE_LOCKING=y),
including all the RCU checks (CONFIG_PROVE_RCU=y).
With that, it really _should_ be obvious here once that code path
executes at all, regardless of whether the kzalloc(GFP_KERNEL) actually
sleeps or not.
johannes
next prev parent reply other threads:[~2022-01-14 20:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-06 4:09 [v13 0/3] MBSSID and EMA support in AP mode Aloka Dixit
2021-10-06 4:09 ` [v13 1/3] mac80211: split beacon retrieval functions Aloka Dixit
2021-10-06 20:20 ` Aloka Dixit
2021-10-06 4:09 ` [v13 2/3] mac80211: MBSSID and EMA beacon handling in AP mode Aloka Dixit
2021-11-26 11:23 ` Johannes Berg
2022-01-14 19:23 ` Aloka Dixit
2022-01-14 20:12 ` Johannes Berg [this message]
2022-01-14 20:34 ` Aloka Dixit
2022-01-14 20:50 ` Johannes Berg
2021-10-06 4:09 ` [v13 3/3] mac80211: MBSSID channel switch Aloka Dixit
2021-11-26 11:16 ` 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=ebb1ddc51e6e0eff436de50cbbddec77d61af495.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=alokad@codeaurora.org \
--cc=linux-wireless@vger.kernel.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: 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 read-only IMAP folder(s) and NNTP newsgroup(s).