I guess we should just ask Tejun :-)
Tejun, the problem was a report that a WQ_MEM_RECLAIM workqueue is
flushing another that isn't, and it turns out that lots of wireless
drivers are using WQ_MEM_RECLAIM for some reason.
Arend said:
> > > > Maybe a hint in the documentation, that a work item on a WQ_MEM_RECLAIM
> > > > queue must not call flush of an !WQ_MEM_RECLAIM queue would be nice.
> > > > Maybe it's kind of obvious, but there is also a reminder not to forget
> > > > that flag, if a queue may have work items that reclaim memory
> > >
> > > Yeah, honestly, I'm not really sure either. Clearly we can't set it,
> > > but other drivers also set it...
> >
> > That triggered something in my memory. So indeed we use it in brcmfmac
> > as well. We used create_singlethread_workqueue(), but I wanted to avoid
> > snprintf and specify the name format so switched to using
> > alloc_ordered_workqueue() keeping WQ_MEM_RECLAIM as per the macro
> > definition.
>
> #define create_singlethread_workqueue(name) \
> alloc_ordered_workqueue("%s", __WQ_LEGACY | WQ_MEM_RECLAIM, name)
>
> > Don't recall why I dropped the __WQ_LEGACY flag though.
johannes
