From: Johannes Berg <johannes@sipsolutions.net>
To: Ben Greear <greearb@candelatech.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
Eliad Peller <eliad@wizery.com>
Subject: Re: Add a new work-queue for destructing stations?
Date: Thu, 13 Dec 2012 19:36:19 +0100 [thread overview]
Message-ID: <1355423779.9463.13.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <1355423271.9463.11.camel@jlt4.sipsolutions.net> (sfid-20121213_192745_389892_F9637F1C)
On Thu, 2012-12-13 at 19:27 +0100, Johannes Berg wrote:
> On Thu, 2012-12-13 at 19:24 +0100, Johannes Berg wrote:
> > On Thu, 2012-12-13 at 10:19 -0800, Ben Greear wrote:
> >
> > > > I don't think that's easy, but you're welcome to try. The
> > > > free_sta_work() function references the sdata so it absolutely must run
> > > > at this point.
> >
> > > So, cancel_work_sync(&sdata->work) would appear to remove
> > > all pending sdata->work items from the work-queue. As long as
> > > there are no other different work items that reference
> > > sdata (and maybe there are..I haven't looked at all of them),
> > > then we should be safe to execute the free_sta_work()
> > > on a different work-queue safely, I think....
> >
> > Sorry, I don't get it. free_sta_work() *itself* has to be executed
> > before the sdata is destroyed. cancel_work_sync(&sdata->work) has
> > nothing to do with free_sta_work.
>
> In fact, this is already buggy now, and I should probably revert
> b22cfcfca, because the work item might run after the AP is stopped and
> then we call into the driver anyway, and on teardown things are probably
> messed up. I'll poke at it tomorrow.
Oh I know an easy way to fix this: we just add the stations to a
(per-sdata?) "cleanup" list in the rcu callback and run a single work
item that cleans up this list. Then we can clean this list in the right
places (stop_ap, etc.)
johannes
next prev parent reply other threads:[~2012-12-13 18:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-13 17:46 Add a new work-queue for destructing stations? Ben Greear
2012-12-13 17:59 ` Johannes Berg
2012-12-13 18:19 ` Ben Greear
2012-12-13 18:24 ` Johannes Berg
2012-12-13 18:27 ` Johannes Berg
2012-12-13 18:36 ` Johannes Berg [this message]
2012-12-13 18:30 ` Ben Greear
2012-12-13 18:37 ` Johannes Berg
2012-12-13 18:39 ` Ben Greear
2012-12-13 18:41 ` Johannes Berg
2012-12-13 18:47 ` Ben Greear
2012-12-13 18:49 ` Johannes Berg
2012-12-13 18:53 ` Johannes Berg
2012-12-13 19:00 ` Ben Greear
2012-12-13 19:11 ` Johannes Berg
2012-12-13 19:17 ` Ben Greear
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=1355423779.9463.13.camel@jlt4.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=eliad@wizery.com \
--cc=greearb@candelatech.com \
--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 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.