From: Ben Greear <greearb@candelatech.com>
To: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] mac80211: Clean up work-queues on disassociation.
Date: Mon, 25 Feb 2013 08:55:53 -0800 [thread overview]
Message-ID: <512B9799.6000708@candelatech.com> (raw)
In-Reply-To: <20130225102020.GA1735@redhat.com>
On 02/25/2013 02:20 AM, Stanislaw Gruszka wrote:
> On Tue, Feb 19, 2013 at 06:11:07PM -0800, greearb@candelatech.com wrote:
>> From: Ben Greear <greearb@candelatech.com>
>>
>> The monitor_work and beacon_connection_loss_work items were
>> not being canceled on disassociation (and not on deletion
>> either). This leads to work-items trying to run after memory
>> has been deleted.
>>
>> I could not find a cleaner way to do this because the
>> cancel_work_sync for these items must be done outside
>> of the ifmgd->mtx.
>>
>> In addition, re-order the quiesce code so that timers are
>> always stopped before work-items are flushed. This was
>> not the problem I saw, but I think it may still be more
>> correct.
>
> I think this patch is quite complicated and simpler solution
> can be used. We stop timers on disassociate, and since
I think my second patch was closer to what you have...
> + /*
> + * We canceled timers during disassoc, but works still can be pending.
> + * Even if we they do not perform action when unassociated, we should
> + * assure we stop them, before freeing resources.
> + */
The comment is a bit misleading....as I saw in my testing, it could actually
crash the system because the entire station could be deleted by the time
the work-item tries to complete.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2013-02-25 16:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-20 2:11 [PATCH] mac80211: Clean up work-queues on disassociation greearb
2013-02-20 6:23 ` Julian Calaby
2013-02-20 14:04 ` Ben Greear
2013-02-20 22:08 ` Julian Calaby
2013-02-20 9:59 ` Johannes Berg
2013-02-20 14:09 ` Ben Greear
2013-02-20 14:13 ` Johannes Berg
2013-02-20 14:24 ` Ben Greear
2013-02-20 14:27 ` Johannes Berg
2013-02-25 10:20 ` Stanislaw Gruszka
2013-02-25 16:55 ` Ben Greear [this message]
2013-02-26 15:55 ` Stanislaw Gruszka
2013-02-26 16:51 ` 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=512B9799.6000708@candelatech.com \
--to=greearb@candelatech.com \
--cc=linux-wireless@vger.kernel.org \
--cc=sgruszka@redhat.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.