linux-kernel - Re: cgroup2 freezer and kvm_vm_worker

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zy0M9yv7xIiKB_Xi@slm.duckdns.org>
Date: Thu, 7 Nov 2024 08:54:47 -1000
From: Tejun Heo <tj@...nel.org>
To: Michal Koutný <mkoutny@...e.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, Luca Boccassi <bluca@...ian.org>,
	Roman Gushchin <roman.gushchin@...ux.dev>, kvm@...r.kernel.org,
	cgroups@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: cgroup2 freezer and kvm_vm_worker_thread()

Hello,

On Thu, Nov 07, 2024 at 07:05:46PM +0100, Michal Koutný wrote:
...
> I'd first ask why the kvm_vm_worker_thread needs to be in the KVM task's
> cgroup (and copy its priority at creation time but no later adjustments)?
> 
> If it can remain inside root cgroup (like any other good kthread) its
> job may be even chunked into periodic/deferred workqueue pieces with no
> kthread per KVM at all.

That'd be better but I suppose kvm wants them in the same cgroup for a
reason.

> If there are resource control/charging concerns, I was thinking about
> the approach of cloning from the KVM task and never returning to
> userspace, which I see you already discussed with PF_USER_WORKER (based
> on #1). All context would be regularly inherited and no migration would
> be needed.
> 
> (I remember issues with the kvm_vm_worker_thread surviving lifespan of
> KVM task and preventing removal of the cgroup. Not sure if that was only
> a race or there's real need for doing some cleanups on an exited task.)
> 
> As for #2, I'm not sure there's a good criterion for what to ignore.
> Here it could possibly be PF_KTHREAD or PF_NOFREEZE (I get the latter
> has purpose for system-wide (or v1) freezer). Generally, we can't tell
> what's the effect of thread's liveliness so it seems better to
> conservatively treat the cgroup as unfrozen.

It'd have to be a separate flag which explicitly says that the task is
exempt from cgroup2 freezer, so yeah, it'd be best if we can avoid this
option.

Thanks.

-- 
tejun