From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E24C73E9597 for ; Tue, 10 Mar 2026 20:29:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773174543; cv=none; b=DDknHEyptQ4gLEujuXCpoZP045a/LdyukmRhbAuSM59vxsu1s5hLu7ix/66FI4NWTdRfwNoBNNPxi1bfk6r4F5FgOCAWzShmrcwnEZMO8oLbYk8kMqkDOk6g7uT1LawNYMw/IGk5YFkJG7RG7IXwd0QQxgYDRrRMCYRxlItSMYw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773174543; c=relaxed/simple; bh=o4A35Cs+YBk2a4/kiNaOoEhOapMtVwqgpAPnVtyjuf0=; h=Date:Message-ID:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=E9JHjdNOqeAHgFaf8nXZ7phGzrtpIo1rbyOBQd+9D2ThaaY3BSCLwL8laoPigU++fUYVhgYgg+OCIYWS5X5Y8r/+1IREeX6u6b7CEKCwP48qHrJUjIOXrdNqbnCWk/80BAb4sWRkf/BSubFpWG2lFUbmvzpYo3ntBRGwveo17OI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aQgYAmHr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aQgYAmHr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E6C1DC19423; Tue, 10 Mar 2026 20:29:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773174542; bh=o4A35Cs+YBk2a4/kiNaOoEhOapMtVwqgpAPnVtyjuf0=; h=Date:From:To:Cc:Subject:References:From; b=aQgYAmHrsFTWn5hdDaCOnt41W3b1lypltI6s49P4j/1IPu/SZ7rjwIGAIUv+I1BbJ z8jeUhxZWZAA85tBWdKDh5PqmaHFfSBLK+cFqzSLtAiDkhVZe/Qlte9NKcpxHCueae bZ9wDUEF4gYfjYTPIheMfuYk+fqkhPBNC82SwbFYZ+tHU9mJXcmN80IBG0KKXejbJO wAoOD3o6PdwS0X0lspofZLENfKzqGHWEqjbbp49YthX0ojrYJr+AZ+t861sN3vHILF L62Q6OEzkQt8LxjuC2GVAabFND65xKVU8Z47qRH6qMNVaxgbGmnkgfb7thFYu7DiC1 FFwBt2tOtLViQ== Date: Tue, 10 Mar 2026 21:28:58 +0100 Message-ID: <20260310202526.048657665@kernel.org> User-Agent: quilt/0.68 From: Thomas Gleixner To: LKML Cc: Peter Zijlstra , Mathieu Desnoyers , Matthieu Baerts , Jiri Slaby Subject: [patch 2/4] sched/mmcid: Handle vfork()/CLONE_VM correctly References: <20260310201009.257617049@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Matthieu and Jiri reported stalls where a task endlessly loops in mm_get_cid() when scheduling in. It turned out that the logic which handles vfork()'ed tasks is broken. It is invoked when the number of tasks associated to a process is smaller than the number of MMCID users. It then walks the task list to find the vfork()'ed task, but accounts all the already processed tasks as well. If that double processing brings the number of to be handled tasks to 0, the walk stops and the vfork()'ed task's CID is not fixed up. As a consequence a subsequent schedule in fails to acquire a (transitional) CID and the machine stalls. Cure this by removing the accounting condition and make the fixup always walk the full task list if it could not find the exact number of users in the process' thread list. Fixes: fbd0e71dc370 ("sched/mmcid: Provide CID ownership mode fixup functions") Reported-by: Matthieu Baerts Reported-by: Jiri Slaby Signed-off-by: Thomas Gleixner Closes: https://lore.kernel.org/b24ffcb3-09d5-4e48-9070-0b69bc654281@kernel.org --- kernel/sched/core.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -10671,10 +10671,7 @@ static void mm_cid_do_fixup_tasks_to_cpu for_each_process_thread(p, t) { if (t == current || t->mm != mm) continue; - if (mm_cid_fixup_task_to_cpu(t, mm)) { - if (--users == 0) - return; - } + mm_cid_fixup_task_to_cpu(t, mm); } }