public inbox for linux-wireless@vger.kernel.org
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <lrodriguez@atheros.com>
To: linville@tuxdriver.com, johannes@sipsolutions.net,
	Jouni.Malinen@atheros.com
Cc: linux-wireless@vger.kernel.org,
	"Luis R. Rodriguez" <lrodriguez@atheros.com>
Subject: Re: [RFC] mac80211: handle -EXIST on sta_info_insert()
Date: Mon, 1 Jun 2009 18:30:00 -0700	[thread overview]
Message-ID: <43e72e890906011830q2867ed1el7914846c15c8eb3e@mail.gmail.com> (raw)
In-Reply-To: <1243905828-21933-1-git-send-email-lrodriguez@atheros.com>

On Mon, Jun 1, 2009 at 6:23 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> There's a few places where we either did not rcu_read_lock()
> prior to addition of a a new sta or we allocated it before
> checking for its existance. In most places, like device open
> and close we should have at least some guarantee the stas are
> wiped but in other places this could not be the case.
>
> Lets protect against RCU in the missing places. The only
> place I see is is in ieee80211_rx_bss_info(). Not sure
> we are calling ieee80211_ibss_add_sta() twice there though.
>
> In our mac80211 cfg80211 callback for device addition we
> also can simplify the code by first checking for the STA
> before trying to add it and then checking for -EEXIST which
> we were not doing. If that actualy would happen we could
> end up potentially with a stale sta and the rate info was
> never updated. It seems cleaner to check for the sta first.
>
> Lastly, we add a WARN_ON() on the STA mlme path upon call to
> ieee80211_rx_mgmt_assoc_resp() for -EEXIST. This should not
> happen, we could just return -EIO or simply ignore it.

Hm, actually on second thought what if we simply kdoc that you should
check for the sta's existence first prior to addition. Then we can
remove the pesky -EEXIST.

  Luis

  reply	other threads:[~2009-06-02  1:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-02  1:23 [RFC] mac80211: handle -EXIST on sta_info_insert() Luis R. Rodriguez
2009-06-02  1:30 ` Luis R. Rodriguez [this message]
2009-06-02  7:28   ` 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=43e72e890906011830q2867ed1el7914846c15c8eb3e@mail.gmail.com \
    --to=lrodriguez@atheros.com \
    --cc=Jouni.Malinen@atheros.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.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