From: Johannes Berg <johannes@sipsolutions.net>
To: Thomas Pedersen <thomas@cozybit.com>
Cc: linux-wireless@vger.kernel.org, devel@lists.open80211s.org
Subject: Re: [PATCH 2/3] mac80211: cache mesh beacon
Date: Mon, 11 Feb 2013 22:34:11 +0100 [thread overview]
Message-ID: <1360618451.8738.46.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <CAG6hwVN5vSxo5Cx0KypF4zQgy+rBudTgrDZ2z2dm8gsL-wRxgw@mail.gmail.com> (sfid-20130211_222455_883194_0E2B5F1F)
On Mon, 2013-02-11 at 13:24 -0800, Thomas Pedersen wrote:
> >> + sdata = container_of(ifmsh, struct ieee80211_sub_if_data, u.mesh);
> >> + rcu_read_lock();
> >
> > This is weird since you already did it outside the function?
>
> Yes, but we shouldn't rely on the caller creating an RCU read section?
I don't really see a problem with that, but the other locking issue
means that you need this anyway.
> >> +static int
> >> +ieee80211_mesh_rebuild_beacon(struct ieee80211_if_mesh *ifmsh)
> >> +{
> >> + struct ieee80211_sub_if_data *sdata;
> >> + struct beacon_data *old_bcn;
> >> + int ret;
> >> + sdata = container_of(ifmsh, struct ieee80211_sub_if_data, u.mesh);
> >> +
> >> + rcu_read_lock();
> >> + old_bcn = rcu_dereference(ifmsh->beacon);
> >> + ret = ieee80211_mesh_build_beacon(ifmsh);
> >
> > This looks totally wrong. You must protect the assignment to
> > ifmsg->beacon by some lock, so then you don't need the rcu_read_lock()
> > here since you're under that lock, so this should be
> > rcu_dereference_protected(..., lockdep_is_held(whatever_lock));
>
> OK, I guess we better protect assignment by some lock then :)
I'm sure there's some lock already? Otherwise doing mesh operations from
userspace and the workqueue would probably be quite racy?
> >> + if (sdata->vif.bss_conf.enable_beacon &&
> >> + (changed & (BSS_CHANGED_BEACON |
> >> + BSS_CHANGED_HT |
> >> + BSS_CHANGED_BASIC_RATES |
> >> + BSS_CHANGED_BEACON_INT)))
> >> + if (ieee80211_mesh_rebuild_beacon(&sdata->u.mesh))
> >> + return;
> >
> > Does that return make any sense?
>
> The alternative is to keep notifying the driver. I just wanted to stop
> everything since we're out of memory, but we can keep calling
> bss_info_change_notify() is you think that makes more sense.
Either way is fine to me.
> >> @@ -694,6 +833,7 @@ void ieee80211_stop_mesh(struct ieee80211_sub_if_data *sdata)
> >> sdata->vif.bss_conf.enable_beacon = false;
> >> clear_bit(SDATA_STATE_OFFCHANNEL_BEACON_STOPPED, &sdata->state);
> >> ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON_ENABLED);
> >> + kfree_rcu(ifmsh->beacon, rcu_head);
> >
> > I think you should set it to NULL first, just so it's clearer.
>
> For who? It seems there is no need in this path, but OK.
You don't have any synchronize_rcu() here so how can you be sure there's
not someone, say in a tasklet, using ifmsh->beacon at this point?
> >> @@ -883,6 +1023,7 @@ void ieee80211_mesh_init_sdata(struct ieee80211_sub_if_data *sdata)
> >> skb_queue_head_init(&ifmsh->ps.bc_buf);
> >> spin_lock_init(&ifmsh->mesh_preq_queue_lock);
> >> spin_lock_init(&ifmsh->sync_offset_lock);
> >> + RCU_INIT_POINTER(ifmsh->beacon, NULL);
> >
> > Isn't everything initialized to 0/null?
>
> Yep, I wanted any needed RCU magic to happen here though.
I don't think there's any RCU magic, particularly not with
RCU_INIT_POINTER, but I don't mind the assignment much :)
johannes
next prev parent reply other threads:[~2013-02-11 21:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-11 21:07 [PATCH 1/3] mac80211: consolidate MBSS change notification Thomas Pedersen
2013-02-11 21:07 ` [PATCH 2/3] mac80211: cache mesh beacon Thomas Pedersen
2013-02-11 21:17 ` Johannes Berg
2013-02-11 21:24 ` Thomas Pedersen
2013-02-11 21:34 ` Johannes Berg [this message]
2013-02-11 21:07 ` [PATCH 3/3] mac80211: generate mesh probe responses Thomas Pedersen
2013-02-11 21:20 ` Johannes Berg
2013-02-11 22:11 ` Thomas Pedersen
2013-02-12 17:56 ` [PATCH 1/3] mac80211: consolidate MBSS change notification Marco Porsch
2013-02-12 18:23 ` Thomas Pedersen
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=1360618451.8738.46.camel@jlt4.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=devel@lists.open80211s.org \
--cc=linux-wireless@vger.kernel.org \
--cc=thomas@cozybit.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 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.