Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <3fc1b7605f6a5e66184cb02781b3eba3e82e9ae9.camel@sipsolutions.net>
Subject: Re: wireless locking simplifications
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Tejun Heo <tj@kernel.org>
Cc:     linux-wireless@vger.kernel.org,
        Lai Jiangshan <jiangshanlai@gmail.com>,
        Benjamin Berg <benjamin@sipsolutions.net>
Date:   Wed, 10 May 2023 13:11:54 +0200
In-Reply-To: <12d77a1427cb4c0888783d8544772e3c2d1a8908.camel@sipsolutions.net>
References: <f3471853cd7063a4bd2d783caa14706ee9115748.camel@sipsolutions.net>
         <ZFV6fTH_7umEa5H0@slm.duckdns.org>
         <12d77a1427cb4c0888783d8544772e3c2d1a8908.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) 
MIME-Version: 1.0
Precedence: bulk

On Wed, 2023-05-10 at 12:58 +0200, Johannes Berg wrote:
> Hi Tejun,
>=20
> > There isn't currently but workqueue already does something similar for
> > freezing by temporarily setting max_active to zero, so if you apply a p=
atch
> > like the following
>=20
> Thanks for that! I came up with a bit of a different patch, see below.
>=20

But ... this raises another interesting thing.

Now I have to call workqueue_resume() somewhere. But that means I need
two versions of wiphy_unlock(), one that does the resume and one that
doesn't, which is interesting. I can track it I think though.

This is probably a stretch ;-) But what would you think about a
workqueue variant that gets a mutex pointer to hold for all work
structs? Then we'd not really have to worry about that in each of them.
But it's not great to implement, I just tried a bit.

johannes