linux-kernel - [RFC PATCH] cgroup: Return error when attempting to migrate a zombie process

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-next>] [day] [month] [year] [list]

Message-Id: <20230503125359.14789-1-mkoutny@suse.com>
Date:   Wed,  3 May 2023 14:53:59 +0200
From:   Michal Koutný <mkoutny@...e.com>
To:     cgroups@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     Tejun Heo <tj@...nel.org>, Zefan Li <lizefan.x@...edance.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Benjamin Berg <benjamin@...solutions.net>
Subject: [RFC PATCH] cgroup: Return error when attempting to migrate a zombie process

Zombies aren't migrated. However, return value of a migration write may
suggest a zombie process was migrated and causing confusion about lack
of cgroup.events:populated between origin and target cgroups (e.g.
target cgroup rmdir).

Notify the users about no effect of their action by a return value.
(update_dfl_csses migration of zombies still silently passes since it is
not meant to be user-visible migration anyway.)

Suggested-by: Benjamin Berg <benjamin@...solutions.net>
Signed-off-by: Michal Koutný <mkoutny@...e.com>
---
 kernel/cgroup/cgroup.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Reasons for RFC:
1) Some users may notice the change,
2) EINVAL vs ESCHR,
3) add a selftest?

diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 625d7483951c..306547dd7b76 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -2968,7 +2968,8 @@ struct task_struct *cgroup_procs_write_start(char *buf, bool threadgroup,
 	 * become trapped in a cpuset, or RT kthread may be born in a
 	 * cgroup with no rt_runtime allocated.  Just say no.
 	 */
-	if (tsk->no_cgroup_migration || (tsk->flags & PF_NO_SETAFFINITY)) {
+	if (tsk->no_cgroup_migration || (tsk->flags & PF_NO_SETAFFINITY) ||
+	    !atomic_read(&tsk->signal->live)) {
 		tsk = ERR_PTR(-EINVAL);
 		goto out_unlock_threadgroup;
 	}
-- 
2.40.1