On 02/25/2013 02:20 AM, Stanislaw Gruszka wrote:
On Tue, Feb 19, 2013 at 06:11:07PM -0800, greearb@xxxxxxxxxxxxxxx wrote:
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
