From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2A9D23B8BBF for ; Mon, 11 May 2026 13:00:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778504418; cv=none; b=hKwH4EVmuJh0xY0//WRHKKmmAttyselDsZypc5fR3UMP5jFUgPB9Mq3VX3x87xJGEzvo1VmMSWOgqhOulYn7pI98wDNXHSmQMTFe9RApyueMzjKF0h2m0Gv78AEeGN2cdw9TO6TQifVtVTP9l6ar6PMaU8Ilcfo21Imve9x8nBQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778504418; c=relaxed/simple; bh=8zf0regd0lBv7+VbRRgsez6EV/cxTeqBVYP1AQXpQWQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MDQ1mJCO5btrymnJWt3XF7BBd9gEJ0G/uVmibD7hsM4G5z3zHjqamGXauCQYoeEmww0M9CHR+0UgPVJr1rWlt9r6JzFWPK0QCe11myY6Zzeod/otOGaBi5JL4V86vbFgl6ZooLGWIMrE7jVIp2TkDl5pAERdvsJhWp/lYlEOrjE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=VjkEIEX9; arc=none smtp.client-ip=209.85.128.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="VjkEIEX9" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-48896199cbaso39304725e9.1 for ; Mon, 11 May 2026 06:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1778504415; x=1779109215; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=4+cQok72EendiQ4RsZOuA4dvDrR9/HbVMIOnFjvkKag=; b=VjkEIEX96Hj6rYmQ7BIyvb/OZ8HPvRSw+Cl902git6Docv7ICNk/a6hGKxB4qq2ur8 iX68TJ4KR0SlQ5g3rYMQnhxX0E/x3kshZQg1gOn1rXjDQ8zZO4Z+0uAPKClJ/idHTTik ds7qUTKq2gpFi6xj62iLE4/9T4ksFd52dJhpIFoLGjQMgLeCwnn1KICXbEeDBdxZbNho 7zwO2eWnCATvJJYCbJa9AG/LiTKeXmVyGqcZWAO0Fd3vhnAcTNNR2A9pwFUUo32vvxuw wnVNCJ+2PX4E0zYeR6E6k4d3cLRJDhqoHvvzfO7CXNugi/oJQQF5orRFNCmCL+AeGw+i S/QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778504415; x=1779109215; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4+cQok72EendiQ4RsZOuA4dvDrR9/HbVMIOnFjvkKag=; b=OgpOJ79SLVKmYSjvLGctJE7cCq7hxA8Pso2m8V0BDMjEHz4ULk5oVXayRaGnZ7quXi LWUXDxKfC2ADuNji+4PobgVzs9RtCwW3+FF37Ze69muoozcFN5k1z+x5dWq/rRe1WN96 zno9tHF11YTh+gYYyissPb3vXnyqbkuul3pOS67kfjZnlBPmsgAcp3NNZcewwfq0rwCw Qz2iba6KQELo8h+zCMgk6sYEU7YoRtD0ZW14R8Qn1EA6Zw8k/IeuTUbIlxqZWmJSWX55 T6MY655XKuRKUeCQqzqJAZmnx6YFX8cP3KO5XJ097xw5PXWEpWwYIgJYb6IK90JM61vB AM4w== X-Forwarded-Encrypted: i=1; AFNElJ+gS8Qfrab9xIUn8X2Puqg2xTFHbL1tMIVKJMSOR6upl86ioGE2KIYvPVLcqArojLiRXOuz1VEc8PXV+78=@vger.kernel.org X-Gm-Message-State: AOJu0YyXr/yZfN/14CmNW0EKFwngUWTIxSxBbtNIGCOLHAA0XVUWjG/Q l9bONIqOMV1OQVxhoqUidFJZeVpqHxU1iaGMPngcT/1qnxoY1W4HiYnrWbLTltyYEfk= X-Gm-Gg: Acq92OFxkhVPpPFJyS+LoC2ymP5xLsXJfCnKCbvQFS52/g8Ji6OKhU1XWdRS4Rb2+Sa eXzEFGZAHKV3Dbo/FQAa8/1b+d9i2VUFUrbX2t527zWQ+8p25A5AM1ZQpBeTE7rfeFAIn/DqyTh swY02+0KEDOG3wqbufLynkXnxuxEeFqdEBAIHf56IBNvZ+1+vEo03WF78bPPtM8EoYXKHWHCz+3 ySL0+Z025qt2P07EFOuQZxvjYHMUTx5RfBHHsXBoQ6DcJe61b+N8G57ox+YkjUueMteqhLQLdlH DAiWZhD7+bCvinDkl5NOizekeNAherryxlOC/RDn4nHvOXER3iyF6vRAejwO4tpsH46b3kSmxWz cTUt23ylmF+WZq1XUTrAz3Wp8zU6c0ULhwgGSez0m2M/pIIyLwfDKiDtFvvDK+czWQHWuRUrzYF 4pX1E3kmht+qYIQZegDzDICnx90fx/h2/uGgo+ X-Received: by 2002:a05:600c:34cd:b0:48e:707f:cdfd with SMTP id 5b1f17b1804b1-48e707fce07mr163903985e9.2.1778504413543; Mon, 11 May 2026 06:00:13 -0700 (PDT) Received: from localhost (109-81-87-110.rct.o2.cz. [109.81.87.110]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48e6db01122sm87807305e9.6.2026.05.11.06.00.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 May 2026 06:00:13 -0700 (PDT) Date: Mon, 11 May 2026 15:00:11 +0200 From: Michal Hocko To: Muchun Song Cc: Muchun Song , Andrew Morton , Vlastimil Babka , linux-mm@kvack.org, Suren Baghdasaryan , Brendan Jackman , Johannes Weiner , Zi Yan , zihan zhou <15645113830zzh@gmail.com>, yaowenchao , linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/page_alloc: Fix zone reserve update serialization Message-ID: References: <53EC8695-885F-4C47-A9E9-89CCF963F0F3@linux.dev> 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 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <53EC8695-885F-4C47-A9E9-89CCF963F0F3@linux.dev> On Mon 11-05-26 20:53:56, Muchun Song wrote: > > > > On May 11, 2026, at 20:33, Michal Hocko wrote: > > > > On Mon 11-05-26 20:04:09, Muchun Song wrote: > >> Serialize lowmem reserve and watermark updates with the same lock so > >> calculate_totalreserve_pages() cannot observe partially updated zone > >> reserve state. > > > > Could you describe the problem you are facing? > > To be more precise, commit 9726891fe753 moved > the call to setup_per_zone_lowmem_reserve into > adjust_managed_page_count. Since adjust_managed_page_count > can be executed concurrently across multiple CPUs > (especially during memory hotplug or parallel initialization), > I am concerned that this might lead to inconsistent updates for > the following counters: > > zone->lowmem_reserve > pgdat->totalreserve_pages > The global totalreserve_pages > > If these updates are not atomic or properly synchronized, > the resulting values could be inaccurate. This inconsistency > might cause issues for other kernel subsystems that rely on > these reserve counts for memory allocation and reclamation > decisions. > > Just to clarify, I noticed this potential issue while reviewing > the source code; it is not a bug I have encountered in a production > environment yet. This is important part that should be part of the changelog. Theoretical issue observed when reading the code. While it is really trivial to see that there is a race condition. It is much less obvious whether the race condition actually matters and worth fixing by introducing a new lock. So this needs much more explanation. I am not against the patch but the changelog is quite underdocumented. -- Michal Hocko SUSE Labs