[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yehg4doAwoUTBHLX@slm.duckdns.org>
Date: Wed, 19 Jan 2022 09:05:05 -1000
From: Tejun Heo <tj@...nel.org>
To: Vipin Sharma <vipinsh@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>,
Michal Koutný <mkoutny@...e.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 10:49:57AM -0800, Vipin Sharma wrote:
> Sean suggested that we can use the real_parent of the kthread task
> which will always be kthreadd_task, this will also not require any
> changes in the cgroup API. I like that approach, I will give it a try.
> This will avoid changes in cgroup APIs completely.
Yeah, that's better than the original but still not great in that it's still
a workaround and just pushes up the problem. You can get the same race if
the cgroups are nested. e.g. if you have a kvm instance under a/b and when
kvm exits, the management software removes b and then realizes that a is
empty too and then tries to delete that too.
It'd be great if we can make kthread_stop actually wait for what most others
consider thread exit but if we're just gonna work around them, just doing it
in userspace might be better - e.g. after kvm exits, wait for !populated
event (this is a pollable event) on the cgroup and then clean up.
Thanks.
--
tejun
Powered by blists - more mailing lists