Re: wireless locking simplifications

[Johannes Berg <johannes@sipsolutions.net>]

On Fri, 2023-05-05 at 11:51 -1000, Tejun Heo wrote:
> Hello, Johannes.
> 
> On Fri, May 05, 2023 at 11:05:45PM +0200, Johannes Berg wrote:
> ...
> > The implementation of (2) is a bit ... awkward, @Tejun, @Lai, there's no
> > way to "pause" an ordered workqueue, is there? I came up with the below
> > patch, but it's a bit ugly and requires a lot of context switches. Just
> > flushing isn't enough since then some work might start and hang on
> > acquiring the lock.
> 
> There isn't currently but workqueue already does something similar for
> freezing by temporarily setting max_active to zero,
> 

Ah, nice. I had thought about it but a lot of places didn't like 0 so
wasn't sure whether or not it was allowed :)

> [snip]

> and then do set_max_active(wq, 0) followed by flush_workqueue(), it should
> be paused until max_active is restored to 1. It probably would be better to
> add a separate pause / resume interface which sets a per-wq flag which is
> read by pwq_adjust_max_active() tho. Anyways, it's not difficult to
> implement at all.

Ok cool, I'll take a look at it at some point. I think it would greatly
simplify the locking etc. in wifi because then we don't need to worry
about the cancel_work_sync() or flush_work() or flush_workqueue()
deadlocks.

Thanks!

johannes