From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 431C7C3DA78 for ; Mon, 16 Jan 2023 03:01:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5D20D6B0071; Sun, 15 Jan 2023 22:01:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 580C56B0072; Sun, 15 Jan 2023 22:01:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 421926B0073; Sun, 15 Jan 2023 22:01:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 335866B0071 for ; Sun, 15 Jan 2023 22:01:33 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E4E5F401FC for ; Mon, 16 Jan 2023 03:01:32 +0000 (UTC) X-FDA: 80359161624.05.765EA89 Received: from hyperium.qtmlabs.xyz (hyperium.qtmlabs.xyz [194.163.182.183]) by imf14.hostedemail.com (Postfix) with ESMTP id 0BA0D100015 for ; Mon, 16 Jan 2023 03:01:30 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=qtmlabs.xyz header.s=syka header.b=KSnOIsDr; spf=pass (imf14.hostedemail.com: domain of msizanoen@qtmlabs.xyz designates 194.163.182.183 as permitted sender) smtp.mailfrom=msizanoen@qtmlabs.xyz; dmarc=pass (policy=reject) header.from=qtmlabs.xyz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673838091; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=nJYHac5AChke1DkAzu8cXLP62bYEgDJ3tC5JwbRm06c=; b=semwVS62YsinWPwKwnOSwKq2R961xKitt/PTeDWSwOSyR5By1TzJpxkeNus9N9tHh+bV0O KBL6deJ6mXGrZYqfdIMpQpCI7u37D6vjaLjIg+4r44XOvQCUhyjCXsQ4UyIDlL/bnaEDEi lnMVDA+JKyWyCEMMdSdwS0t/vOlEsq8= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=qtmlabs.xyz header.s=syka header.b=KSnOIsDr; spf=pass (imf14.hostedemail.com: domain of msizanoen@qtmlabs.xyz designates 194.163.182.183 as permitted sender) smtp.mailfrom=msizanoen@qtmlabs.xyz; dmarc=pass (policy=reject) header.from=qtmlabs.xyz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673838091; a=rsa-sha256; cv=none; b=jDv/bHktYMqq52eHq84xkca7KDQeOKjSq3Tknc/6fscu/8ftTZkKDUQcCvbUeRyKB/kiP2 6h+D8lncFphqNZZoIgpZk5JrbjLsoC5fGMNkQLIew3b5pa3nMXL73Xczan49odOOhSq/4s NS+eQrdfd5RE6DFg8K89PAamtNBcojU= Received: from dong.kernal.eu (unknown [14.231.159.199]) by hyperium.qtmlabs.xyz (Postfix) with ESMTPSA id CEA1C820055; Mon, 16 Jan 2023 04:01:28 +0100 (CET) Received: from [172.20.10.3] (unknown [27.68.139.212]) by dong.kernal.eu (Postfix) with ESMTPSA id 3374444496AC; Mon, 16 Jan 2023 10:01:23 +0700 (+07) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qtmlabs.xyz; s=syka; t=1673838083; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nJYHac5AChke1DkAzu8cXLP62bYEgDJ3tC5JwbRm06c=; b=KSnOIsDrOro5wSid/Rt33wKhfEbQ5raXLhJ6M2msG0BT7cmhxKXgiThqorrGBnz3zhYQQa LzUPj087bWcwqRUgkUpvnTTy52oIj/1+8Yyz9oLX8eKMYKQhpUYt6N/HPAcfd4sS+BrVeR YFCJ5EGRCjMtA+fmVyw1pf9FrbiD9ZzOEU51YY7kJvXC8vpqHqR28bSbon9za739MGT9E1 6GN2OYSTjyOic4TZmlOR1MkKfXgnvyL444WX0sWyQLzdcByq2GxJ2egVg4vBBVKuqsqrqn nCnJtgdRoBUJIYHz0PRPcDl+nYq77bNY2CO/HYH2i7B6SimHp+0VZ5B1caeFyw== Message-ID: <03a081aa-2e6a-2a28-0444-eecf50364bc0@qtmlabs.xyz> Date: Mon, 16 Jan 2023 10:01:17 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH v2] mm: do not try to migrate lru_gen if it's not associated with a memcg Content-Language: en-US To: Yu Zhao Cc: Andrew Morton , stable@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20230115133330.28420-1-msizanoen@qtmlabs.xyz> <20230115134651.30028-1-msizanoen@qtmlabs.xyz> From: msizanoen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 0BA0D100015 X-Stat-Signature: yzkfprmdimh7kkbtsp6r8qqid3i7rw19 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1673838090-761709 X-HE-Meta: U2FsdGVkX19KROdfpBu2slmn3leR9Q4P5utF6bHyQ2nMNnrocQkVGGbMqoHdKI7uLGnNFsT9XG/H0xBwQXI7F/mh9S0eMcl6XtPwzXE9nE0+WZHhi7TRtzSRe08T8NE5TdFEyXGfn5mvOWCtvFbT2rY073Vs6ytavEiT7U49a/DWIzjX0M5fW29ynuLfLH+LQUZvqKNt/px/QF+b6o+V/S1X5YQy8YKh1swmgerAUNTQ0CVSRowDSHneNlog4VTxRYXxIkRKGsU2FD/8oxBEW8xjfeTgJIC5tzOUWeHfVNmMo3IhDE5EKGlKvubpixFdkfNcKYb5MKkSSt4hKvGhlxdlWNse+rMjOZ3F7dSAVCclkDSKVc+7z/TWRq1lFM1M6gFGAWbORMThLY672biSjuA7qanybxQpa1Mg10XFt36eMi/IGVDfMJ4wLfmm73ITdKt4ZzXNF2QUj3/r/olnxiWjMWSDP4r0+FvFvDQm62jVy7rjJLcdkN4wdKezZb2jr7R8wgEt9G7MyOHfhzVvRIV7tHZ7L2o2qFQZLUdbhC4VZaZ8sK3AKdaqVlRkBfOc1HsFWTDD8lDWrLydreHquTvAWRpqYLodYi1D2pfictozW7/xyHh05gDr++UxPXA7mdmSIT2TN+1ZKlBHBIHyin1GbR2UCsn1FUqWukVAzhaT3QT3u05gwZBSxdvkZ7sJW6wOHKNpYCvY0iugJiaWQfU/aOIpoIDL6TcOE3CM/YJ28k6sKdC78eQaqVV6+VZ2mo3ZXaLRo5AlyGPAtbCDcJt89WSXfMP0Z2nKTWAxdqDxQPG1BbJ09D2b6WCK0DJAla6GOs1qAHegl2kKvJdimb38xDHJiNsxc+h2tVonxep6sU37vHWQem7ggIV73pKVr55AnOw2HWRaugG1hP+MZzmeAB0m9dRJ5BERd2lKeAPTzT+gQwTlzRmupqC9oU8bGoxW3R0or1vLOZzWeG3 evlfLg8n +CxV+OPUsb7B2F/jmYT3ZvedeY04nXkG6jqhESz1YL89RdOSYbxrOCIr6caZlOv3uNFYeYv6dl3Oss7XGxa/EpA7gIOKiIJnBOG95atdbqS7efJcBtx2xuayvqLaLcQENi5Jl X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 1/16/23 06:13, Yu Zhao wrote: > On Sun, Jan 15, 2023 at 6:47 AM msizanoen1 wrote: >> In some cases, memory cgroup migration can be initiated by userspace >> right after a process was created and right before `lru_gen_add_mm()` is >> called (e.g. by some program watching a cgroup and moving away any >> processes it detects[1]), which results in the following sequence of >> WARNs followed by an Oops as the kernel attempts to perform a >> `lru_gen_add_mm()` twice on the same `mm`: > ... > >> Fix this by simply leaving the lru_gen alone if it has not been >> associated with a memcg yet, as it should eventually be assigned to the >> right cgroup anyway. >> >> [1]: https://gitlab.freedesktop.org/benzea/uresourced/-/blob/master/cgroupify/cgroupify.c >> >> v2: >> Added stable cc tags >> >> Signed-off-by: N/A (patch should not be copyrightable) >> Cc: stable@vger.kernel.org > Thanks for the fix. Cc'ing stable is the right thing to do. The > commit message and the comment styles could be easily adjusted to > align with the guidelines. > > I don't think the N/A is acceptible though. I fully respect it if you > wish to remain anonymous -- I can send a similar fix crediting you > as the "anonymous user " who reported this bug. Sure, just add my email in the `Reported-by: ` and `Tested-by: ` lines and git-send-email should automatically add me to the Cc list. > > A bit of background on how I broke it: an old version I have on 4.15 > calls lru_gen_add_mm() before cgroup_post_fork(), which excludes > cgroup migrations by cgroup_threadgroup_rwsem. When I rebased it, I > made lru_gen_add_mm() depend on task_lock for the synchronization with > cgroup migrations -- the decoupling seemed (still seems) to make it > less complicated -- but this is not safe unless we have the check below. > > > > >> --- >> mm/vmscan.c | 8 +++++++- >> 1 file changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/mm/vmscan.c b/mm/vmscan.c >> index bd6637fcd8f9..0cac40e7484c 100644 >> --- a/mm/vmscan.c >> +++ b/mm/vmscan.c >> @@ -3323,13 +3323,19 @@ void lru_gen_migrate_mm(struct mm_struct *mm) >> if (mem_cgroup_disabled()) >> return; >> >> + /* This could happen if cgroup migration is invoked before the process >> + * lru_gen is associated with a memcg (e.g. during process creation). >> + * Simply ignore it in this case as the lru_gen will get assigned the >> + * right cgroup later. */ >> + if (!mm->lru_gen.memcg) >> + return; >> + >> rcu_read_lock(); >> memcg = mem_cgroup_from_task(task); >> rcu_read_unlock(); >> if (memcg == mm->lru_gen.memcg) >> return; >> >> - VM_WARN_ON_ONCE(!mm->lru_gen.memcg); >> VM_WARN_ON_ONCE(list_empty(&mm->lru_gen.list)); >> >> lru_gen_del_mm(mm);