[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJhGHyAVbCm6i7pTRDDXgdwS25d5O3uMCvKzyOcafRAdN-S7JQ@mail.gmail.com>
Date: Tue, 6 Dec 2022 14:23:39 +0800
From: Lai Jiangshan <jiangshanlai@...il.com>
To: richard clark <richard.xnu.clark@...il.com>
Cc: tj@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: work item still be scheduled to execute after destroy_workqueue?
On Tue, Dec 6, 2022 at 12:35 PM richard clark
<richard.xnu.clark@...il.com> wrote:
> >
> A WARN is definitely reasonable and has its benefits. Can I try to
> submit the patch and you're nice to review as maintainer?
>
> Thanks,
> Richard
> >
Sure, go ahead.
What's in my mind is that the following code is wrapped in a new function:
mutex_lock(&wq->mutex);
if (!wq->nr_drainers++)
wq->flags |= __WQ_DRAINING;
mutex_unlock(&wq->mutex);
and the new function replaces the open code drain_workqueue() and
is also called in destroy_workqueue() (before calling drain_workqueue()).
__WQ_DRAINING will cause the needed WARN on illegally queuing items on
destroyed workqueue.
Thanks
Lai
Powered by blists - more mailing lists