Received-SPF: pass (google.com: domain of linux-kernel+bounces-108729-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
From: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
To: Johannes Weiner <hannes@cmpxchg.org>,
	Michal Hocko <mhocko@kernel.org>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Muchun Song <muchun.song@linux.dev>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>,
	cgroups@vger.kernel.org,
	linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	kernel@openvz.org,
	Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Subject: [PATCH] mm/memcontrol: stop resize loop if limit was changed again
Date: Wed, 20 Mar 2024 18:03:30 +0800
Message-ID: <20240320100556.463266-1-ptikhomirov@virtuozzo.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?n/rWpzhq1P7lwp0l2jO9wZUbgqpZTvQvFjkB4op+TaDREEyplinexw8PyAB7?=
 =?us-ascii?Q?HmefpM0/aQ4CQv0KKIKMCwZM+LaLDIRZ5FtV7ok6+M7PeIlkKgog65sznnm2?=
 =?us-ascii?Q?1hDaoxVRWoXJE8fzeFGfv6yFRBwA8HS1YoNPT2UOXotrvBeGTiSjZwV08jan?=
 =?us-ascii?Q?98Nr+GZQT7NSoQIERxIEMkhGfR7PsAbrPAxLSAOeLBOUlmdZKT5ojk5m54st?=
 =?us-ascii?Q?sv7yesviwD2CFY5P5MvmxtuRHc4Ijnd4ikGhj4XdpOFklrfXKu9GzmHSPQvZ?=
 =?us-ascii?Q?6o4jG3wZuHZ1KD6c28T2Zc2VuLSELdx0iJs0NzWttRAq53BPajaUgGaC1uhW?=
 =?us-ascii?Q?zjz2r4YRk7YjSo6YRQRk67HAOjSNwA3GhBBI2xrbDRnjvAD/+jR7jQhBzOn/?=
 =?us-ascii?Q?yOpBhawKoXieU05RyQUStXceiYCosg6jAXXtHpoO8656WS04Cm6zjNh0H6i8?=
 =?us-ascii?Q?WpyxF965xDwQEb2I4ElUACI419Htpn6n05+/Af0EvptGCdoP25gUJnQSjS/0?=
 =?us-ascii?Q?+LPRMi/VgsUrwwLiw6wyJUr28OIGJGAkew7ChZbGNLhSP6LkK7IYDqbFKrxo?=
 =?us-ascii?Q?KZEvceayfMSMyQzdbyGEqTUs+bZ3UF0A0KT6x00cE0C+aUKJuMouUEBVEmvZ?=
 =?us-ascii?Q?J8r6VhGgPrlGi/55WTt4xcCFmAMH1XgxBk/Sv0cGFXvY8GxLZzIR0zyNrR7b?=
 =?us-ascii?Q?TzbVPKOLv46GBvHU/Q72DI5rCcUa/v/sZX5pCxJavtKbV1F7+QjcduHVd/vo?=
 =?us-ascii?Q?CIMsPzIQzPJmuwlnA9Cx15o6spP9G5onxXvmDVixeq3TQxClfMDoFkAL8KlI?=
 =?us-ascii?Q?5yrPR8FTe7ihFyuw1OY4c1ScZzKmmJvVfemRHGu94sQnU1uBDZvcC4i6yAn6?=
 =?us-ascii?Q?fgM8QUWRCd2JKggSS+cyk6+ulfklGFfgACX5W8+fJdxo+zG7YriuzW0n7ce1?=
 =?us-ascii?Q?c0NfMhoZodyGTS19xRaI323NeGs6PogcuJeKxcfRkhfZailorux0iDHqD1dN?=
 =?us-ascii?Q?EPBZu4i4eKN6gZfspD5BHL6gXIIUqT3lFLLz/lyXIhf8rMThpDqZrJGfn69T?=
 =?us-ascii?Q?i8WRDT9JunkNkAHzmok2m6bMjJ8EN+ToIDLvsnnHDi76Tg57P/CvHfpR8O6U?=
 =?us-ascii?Q?caxqe8r6ER92zfyZf8vHL/8+0FQ7Q/mxE1Doitdo/Ti7oTzwrgXNAcKh0U9s?=
 =?us-ascii?Q?aS69o2vafVT6K4c6cV9dkJMfn9gppeSpAJgJYnTAGnnihWVIIr+JK6khdCC3?=
 =?us-ascii?Q?PYmi9dR3G9gh2howExyStBCRwAvd3ntN7CdI/BM3hpRMtol84N9ihR/JpqOc?=
 =?us-ascii?Q?BnPf9ibgL6RtJUyA4+yKz3CZazZrwLHAlyck0dFyxq8dtCzb8CcfMYx2mrL1?=
 =?us-ascii?Q?05QKOx9TInhwvcw4E7WtBueUNNF/wZ3wjgcobU07ApHOGD4mT5ANTkZW0KEg?=
 =?us-ascii?Q?rZRd4zMX4ngamfvkzyjyp7k7IqK4XP6LmbwDPcfjb8ZqT2+9tCmUXmQCUCQW?=
 =?us-ascii?Q?vE/TmsfbcsZjSCk1b7LueLTzb5qD4ItXQ/D+GU4KgqDdZhn7+zgtHenOVLVR?=
 =?us-ascii?Q?9qRXBBEND31/eNFKKLrE674QkoQrfOVTXP/pjyW/TrVH3OoLSlHHFFBZ+vjY?=
 =?us-ascii?Q?uXYUIT5vUeY6su4M/Mz3f8IoUMlYHV3PxjvVTXFCSqcD6+ZGqzTD5EYkWOGo?=
 =?us-ascii?Q?Bd9IEA=3D=3D?=
X-OriginatorOrg: virtuozzo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 12da4412-e651-46c5-9ebc-08dc48c56032
X-MS-Exchange-CrossTenant-AuthSource: DU0PR08MB9003.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2024 10:06:14.6384
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: XZp4bIb1N0CvFpvwNg/tjfXMBiw6m3GL54BiAM/RxjfQL3WlEzcS1t28jZguZHwRAup0ee//k9FCuBsMvBmzEQxSZPVygMHEg/UvpZ81I14=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB7435

In memory_max_write() we first set memcg->memory.max and only then
try to enforce it in loop. What if while we are in loop someone else
have changed memcg->memory.max but we are still trying to enforce
the old value? I believe this can lead to nasty consequence like getting
an oom on perfectly fine cgroup within it's limits or excess reclaim.

We also have exactly the same thing in memory_high_write().

So let's stop enforcing old limits if we already have a new ones.

Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
---
 mm/memcontrol.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 61932c9215e7..81b303728491 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6769,6 +6769,9 @@ static ssize_t memory_high_write(struct kernfs_open_file *of,
 		unsigned long nr_pages = page_counter_read(&memcg->memory);
 		unsigned long reclaimed;
 
+		if (memcg->memory.high != high)
+			break;
+
 		if (nr_pages <= high)
 			break;
 
@@ -6817,6 +6820,9 @@ static ssize_t memory_max_write(struct kernfs_open_file *of,
 	for (;;) {
 		unsigned long nr_pages = page_counter_read(&memcg->memory);
 
+		if (memcg->memory.max != max)
+			break;
+
 		if (nr_pages <= max)
 			break;
 
-- 
2.43.0