From nobody Sun Feb 8 17:04:50 2026 Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) (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 AA5CC2147FB for ; Thu, 18 Dec 2025 08:32:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.170 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766046725; cv=none; b=RArcF90a6GYhTy1QhzXt4PNClPDj1NGMZV7gpKgjp+DPHmEpHju2WqpJMnGuV3NXKTdNSg3OTPEYBIBvmotljVC56nJwut36F27k1bT5EmzheDzU8e2ae9MSire3nOWZD3ws828MjPLuy1eeLvRxsH+AtKNQFl+O1UvnMLynm5I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766046725; c=relaxed/simple; bh=i0m6WgHnok+MeeRl+DyzqWNJjsRPYAi25dFzv39Lcmo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=kdx3/CUXumeA7gpg6GD8jGdARpc68vb7QMk2Kgi5tlvsB8jGm1jwa78M562QH9OHrOXYog6/Z9bM/NUW3o/4dXgujZ1g6WIhuvSY6pdV8cKpCZS9NWjfdbVufWzOoQiyltc2e8Yw9mxrd37M3BdjssRvRI8qabv4egFJ24g5m04= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=bBsC1nlQ; arc=none smtp.client-ip=209.85.128.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="bBsC1nlQ" Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-78c4d112cd8so2849327b3.2 for ; Thu, 18 Dec 2025 00:32:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766046722; x=1766651522; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=BD9Vhiz0c2yEOsE49k+C0PVRmnQZoN1zMYvcjJNrras=; b=bBsC1nlQ82ArFdb/AN72Tk6GxOX2blkn078pF45bw9gzSCdoTMDguv/jloAyEEYn1f VjYYS+qp+KrsJgrNuxFa5aBRjSTmOD+Wogn/VaKCNp3Fr+cPidprMiQc+ejC+Q/Nudfo k2uG8vjVk3Nb6R9j1gRkB/bHjCkM79Tm4jtEMSV68fK5fCt0NO8F44JwuuOOdq1tQCUr JoZdXsi5xZs2fW40ceIKuX6vkh1ptkF5b7CtimSWVDrO1rsyH+slkM7PXCtuzxaLSfzj 5dBdD87ah5WRDhT0+ECPcHrRFPFPtKP9NYajsbmS6k50GXUUGfvxl3NUDnhjDr4gbu4i KzBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766046722; x=1766651522; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=BD9Vhiz0c2yEOsE49k+C0PVRmnQZoN1zMYvcjJNrras=; b=Q8JsIzuRHqUPl2TSFaoynOJqJMEEgoyBJGgGtBti858J9RRi07iI1m4MV3/raoZSff rlTNPSyW7Awv0L0FZA/piPDZ4ms3LBW+3bqd5i+2FllxaLOGPPJMOTZKbxeg/gPgRuYN iMFStWQPrFpmQtI4Uz6klpCAu5VsXRe6By3p7rd2rpvVStGnkrJS5qr/QEmjjxyKSKTa 9ucDKLN5CNglBhYy/1jBrjCztZpFzBmUkFbW3rNqWu+qFL9AJDLwMbAblZC/ZbY8DuUF z3d2PA44Pc3HXyU9RWCCj429BHQCWxmfGw1wxuRJFTI3KCd7OfFnkZj6K9d0CBDMUdr+ lJCQ== X-Forwarded-Encrypted: i=1; AJvYcCWlp1e+M41+B3dhk6xh2IplOpc/dxmsKC8cWjkj9uMnp+gZ30ujDW6Gr01KpgzYoJ+Vkedof2Iz+pdNJeY=@vger.kernel.org X-Gm-Message-State: AOJu0YwKkjPWwyapjapHGCZHWbJeZLKMTAKMEAv0K0JuJU/7qAD69qPF Bcqr7WYC+Me5bmLEjefAsm4SVjXE8kGn0AxLWsESd01Enh0ufqW1qye+ X-Gm-Gg: AY/fxX6RtB+CeAJ7CTy/BK6IgODHPNwnB2TKdRIo6w5uld6eAaE+F+SpzHVK36erHSd 6jivA0C1jM9hFqJTaIj8OSVlWekX+dlCe7mI+7foy0Q6bFuEsw6pl5Y7HrRDCay+rK7rodfXxGa 3/iPxq18ZXnK2BeW5dKO6UMKDGLf7/N9QQBdJKs+tBnj12h06EJcAa4tAAj1PIGwyqGDpjEdkr2 f6sbt+HWgTy6/40tSoS4ehGCaChJo7OQvxk/h6EPl7BVZdZLZ7LgzFeeZqrUOOXdIzqZKk8CEEq EP/y2QqafxctFni1ZZ4o14dzJsxpvci1KSP06kIhhKzhrbH7YFBTs2S+mM7icjyepmLK00sbHT9 PxgNSvLhiDzHJcgibrfSAGGNVGKeFMlbW/0ApiGIRCUpYRXULg+KpY/OkFQskmBwxYI5LP9QdeB 1ovgUjcSUhM9P02ecpmvvNcA== X-Google-Smtp-Source: AGHT+IGzrwYlmJqo5DfyQ+cUmhBCqgSSMbdNMu2jt9PuzmpP+TQ7xxkRZxozhfM/43jSjbqC1bzRoQ== X-Received: by 2002:a05:690c:4442:b0:786:62bb:f6f5 with SMTP id 00721157ae682-78e66cd74cbmr316793337b3.17.1766046722375; Thu, 18 Dec 2025 00:32:02 -0800 (PST) Received: from localhost ([2a03:2880:25ff:71::]) by smtp.gmail.com with ESMTPSA id 00721157ae682-78fa6f51fa9sm5851527b3.17.2025.12.18.00.32.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Dec 2025 00:32:01 -0800 (PST) From: Joshua Hahn To: Andrew Morton Cc: Daniel Palmer , Guenter Roeck , Brendan Jackman , Johannes Weiner , Michal Hocko , Suren Baghdasaryan , Vlastimil Babka , Zi Yan , linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel-team@meta.com Subject: [PATCH v2] mm/page_alloc: Report 1 as zone_batchsize for !CONFIG_MMU Date: Thu, 18 Dec 2025 00:31:59 -0800 Message-ID: <20251218083200.2435789-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Commit 2783088ef24e ("mm/page_alloc: prevent reporting pcp->batch =3D 0") moved the error handling (0-handling) of zone_batchsize from its callers to inside the function. However, the commit left out the error handling for the NOMMU case, leading to deadlocks on NOMMU systems. For NOMMU systems, return 1 instead of 0 for zone_batchsize, which restores the previous deadlock-free behavior. There is no functional difference expected with this patch before commit 2783088ef24e, other than the pr_debug in zone_pcp_init now printing out 1 instead of 0 for zones in NOMMU systems. Not only is this a pr_debug, the difference is purely semantic anyways. Fixes: 2783088ef24e ("mm/page_alloc: prevent reporting pcp->batch =3D 0") Reported-by: Daniel Palmer Closes: https://lore.kernel.org/linux-mm/CAFr9PX=3D_HaM3_xPtTiBn5Gw5-0xcRpa= wpJ02NStfdr0khF2k7g@mail.gmail.com/ Reported-by: Guenter Roeck Closes: https://lore.kernel.org/all/42143500-c380-41fe-815c-696c17241506@ro= eck-us.net/ Signed-off-by: Joshua Hahn Acked-by: SeongJae Park Reviewed-by: Vlastimil Babka Tested-by: Daniel Palmer Tested-by: Guenter Roeck Tested-by: Hajime Tazaki --- v1 --> v2: - Instead of restoring max(1, zone_batchsize(zone)), just return 1 for NOM= MU systems since this is simpler and only affects a single pr_debug. mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 822e05f1a964..977cbf20777d 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5924,7 +5924,7 @@ static int zone_batchsize(struct zone *zone) * recycled, this leads to the once large chunks of space being * fragmented and becoming unavailable for high-order allocations. */ - return 0; + return 1; #endif } =20 base-commit: 40fbbd64bba6c6e7a72885d2f59b6a3be9991eeb --=20 2.47.3