From: Valentin Schneider <vschneid@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: linux-kernel@vger.kernel.org,
Lai Jiangshan <jiangshanlai@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Frederic Weisbecker <frederic@kernel.org>,
Juri Lelli <juri.lelli@redhat.com>, Phil Auld <pauld@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PATCH v7 4/4] workqueue: Unbind kworkers before sending them to exit()
Date: Wed, 11 Jan 2023 17:18:13 +0000 [thread overview]
Message-ID: <xhsmhpmblc7my.mognet@vschneid.remote.csb> (raw)
In-Reply-To: <Y77qEu1fQHMWr6F1@slm.duckdns.org>
On 11/01/23 06:55, Tejun Heo wrote:
> On Wed, Jan 11, 2023 at 12:49:49PM +0000, Valentin Schneider wrote:
>> While we're here, for my own education I was trying to figure out in what
>> scenarios we can hit this manager-already-active condition. When sending
>> out v6 I had convinced myself it could happen during failed
>> initialization of a new unbound pool, but having another look at it now I'm
>> not so sure anymore.
>>
>> The only scenario I can think of now is around maybe_create_worker()'s
>> release of pool->lock, as that implies another worker can drain the
>> pool->worklist and thus let pool->refcnt reach 0 while another worker is
>> being the pool manager. Am I looking at the right thing?
>
> To be frank, I'm not sure and can't remember why the code is like that off
> the top of my head. It could well be that I was just habitually thinking
> that MANAGER can be contended while in practice the scenario can never
> happen in this particular case. I'll need to look harder at it but maybe we
> can leave that to another day?
>
For sure :-)
> Thanks.
>
> --
> tejun
prev parent reply other threads:[~2023-01-11 17:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-09 13:33 [PATCH v7 0/4] workqueue: destroy_worker() vs isolated CPUs Valentin Schneider
2023-01-09 13:33 ` [PATCH v7 1/4] workqueue: Protects wq_unbound_cpumask with wq_pool_attach_mutex Valentin Schneider
2023-01-09 13:33 ` [PATCH v7 2/4] workqueue: Factorize unbind/rebind_workers() logic Valentin Schneider
2023-01-09 13:33 ` [PATCH v7 3/4] workqueue: Convert the idle_timer to a timer + work_struct Valentin Schneider
2023-01-09 13:33 ` [PATCH v7 4/4] workqueue: Unbind kworkers before sending them to exit() Valentin Schneider
2023-01-10 20:28 ` Tejun Heo
2023-01-11 12:49 ` Valentin Schneider
2023-01-11 16:55 ` Tejun Heo
2023-01-11 17:18 ` Valentin Schneider [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xhsmhpmblc7my.mognet@vschneid.remote.csb \
--to=vschneid@redhat.com \
--cc=frederic@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=pauld@redhat.com \
--cc=peterz@infradead.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®