[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220120150502.GC27269@blackbody.suse.cz>
Date: Thu, 20 Jan 2022 16:05:02 +0100
From: Michal Koutný <mkoutny@...e.com>
To: Tejun Heo <tj@...nel.org>
Cc: Paolo Bonzini <pbonzini@...hat.com>,
Vipin Sharma <vipinsh@...gle.com>, seanjc@...gle.com,
lizefan.x@...edance.com, hannes@...xchg.org, dmatlack@...gle.com,
jiangshanlai@...il.com, kvm@...r.kernel.org,
cgroups@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] KVM: Move VM's worker kthreads back to the original
cgroups before exiting.
On Wed, Jan 19, 2022 at 08:30:43AM -1000, Tejun Heo <tj@...nel.org> wrote:
> It'd be nicer if we can make kthread_stop() waiting more regular but I
> couldn't find a good existing place and routing the usual parent
> signaling might be too complicated. Anyone has better ideas?
The regular way is pictured in Paolo's diagram already, the
exit_notify/do_signal_parent -> wait4 path.
Actually, I can see that there exists already kernel_wait() and is used
by a UMH wrapper kthread. kthreadd issues ignore_signals() so (besides
no well defined point of signalling a kthread) the signal notification
is moot and only waking up the waiter is relevant. So kthread_stop()
could wait via kernel_wait() based on pid (extracted from task_struct).
Have I missed an obstacle?
Michal
Powered by blists - more mailing lists