From: Johannes Berg <johannes@sipsolutions.net>
To: Christian Lamparter <chunkeey@googlemail.com>
Cc: linux-wireless@vger.kernel.org, linville@tuxdriver.com,
Ben Greear <greearb@candelatech.com>,
Ming Lei <tom.leiming@gmail.com>
Subject: Re: [PATCH] mac80211: hoist sta->lock from reorder release timer
Date: Wed, 06 Oct 2010 12:41:45 +0200 [thread overview]
Message-ID: <1286361705.3655.121.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <201010061220.50800.chunkeey@googlemail.com>
On Wed, 2010-10-06 at 12:20 +0200, Christian Lamparter wrote:
> On Wednesday 06 October 2010 12:10:26 Johannes Berg wrote:
> > On Wed, 2010-10-06 at 12:00 +0200, Christian Lamparter wrote:
> >
> > > The timer itself is part of the station's private struct.
> > > The clean-up routine will deactivate the timer as soon as
> > > the station is removed. Therefore the extra sta->lock
> > > protection should not be necessary.
> >
> > > rcu_read_lock();
> > > - spin_lock(&sta->lock);
> > > ieee80211_release_reorder_timeout(sta, *ptid);
> > > - spin_unlock(&sta->lock);
> > > rcu_read_unlock();
> >
> > There's a comment on ieee80211_release_reorder_timeout() saying that the
> > lock must be held -- which is probably not true? We don't generally hold
> > that lock on the RX path...?
>
> That comment is more or less a 1:1 copy from the comment about
> struct tid_ampdu_rx (in sta_info.h).
Kinda.
> > * This structure is protected by RCU and the per-station
> > * spinlock. Assignments to the array holding it must hold
> > * the spinlock, only the RX path can access it under RCU
> > * lock-free.
>
> thing is: we now have the reorder_lock which protects the
> reorder buffer against "destructive access". So, is it "ok"
> to trim the comments a bit?
Well, so if this patch is OK, it would be, but looking at
tid_agg_rx->head_seq_num and buf_size for example, they're not always
protected by the reorder lock (though they could easily be).
In fact, there are more races, like for example
ieee80211_release_reorder_frames not being invoked with the reorder lock
held from ieee80211_rx_h_ctrl, which could lead to issues?
Basically the thing is that until your patch, the data in the struct
didn't actually need locking because it was accessed by the RX path only
which is not concurrent.
So now we have to carefully analyse what we can do. The comment about
the sta->lock has probably never been really correct...
johannes
next prev parent reply other threads:[~2010-10-06 10:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-06 10:00 [PATCH] mac80211: hoist sta->lock from reorder release timer Christian Lamparter
2010-10-06 10:10 ` Johannes Berg
2010-10-06 10:20 ` Christian Lamparter
2010-10-06 10:41 ` Johannes Berg [this message]
2010-10-06 11:43 ` Christian Lamparter
2010-10-06 11:46 ` Johannes Berg
2010-10-06 20:21 ` John W. Linville
2010-10-07 21:03 ` Johannes Berg
2010-10-08 16:42 ` Christian Lamparter
2010-10-08 16:53 ` Johannes Berg
2010-10-08 18:12 ` Christian Lamparter
2010-10-08 18:45 ` 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=1286361705.3655.121.camel@jlt3.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=chunkeey@googlemail.com \
--cc=greearb@candelatech.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=tom.leiming@gmail.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;
as well as URLs for NNTP newsgroup(s).