On Fri, 2010-11-12 at 12:07 -0800, greearb@xxxxxxxxxxxxxxx wrote: > - flush_work(&sdata->work); > + /* Cannot call flush_work here because we are holding > + * RTNL and the worker thread(s) that will be called upon to > + * do the flushing might already be running a piece of work > + * that is blocking on RTNL. That leads to deadlock and/or > + * OOM. > + */ > + cancel_work_sync(&sdata->work); I don't think that comment really belongs into the sources at all ... if we did that all the time we'd have no sources left between the comments :-) However, I also don't think it should be necessary to do this. sdata->work is always queued on local->workqueue, which is created using alloc_ordered_workqueue(), and there is no work on this workqueue that uses the RTNL. Therefore, even flushing the entire workqueue must work, unless alloc_ordered_workqueue() has no such guarantee any more -- which I would consider to be a bug in the new workqueue framework. johannes -- 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
