[PATCH v2] mm/page_alloc: Report 1 as zone_batchsize for !CONFIG_MMU

[PATCH v2] mm/page_alloc: Report 1 as zone_batchsize for !CONFIG_MMU

[Joshua Hahn]

Commit 2783088ef24e ("mm/page_alloc: prevent reporting pcp->batch = 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 = 0")
Reported-by: Daniel Palmer <daniel@thingy.jp>
Closes: https://lore.kernel.org/linux-mm/CAFr9PX=_HaM3_xPtTiBn5Gw5-0xcRpawpJ02NStfdr0khF2k7g@mail.gmail.com/
Reported-by: Guenter Roeck <linux@roeck-us.net>
Closes: https://lore.kernel.org/all/42143500-c380-41fe-815c-696c17241506@roeck-us.net/
Signed-off-by: Joshua Hahn <joshua.hahnjy@gmail.com>
---
v1 --> v2:
- Instead of restoring  max(1, zone_batchsize(zone)), just return 1 for NOMMU
  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
 }
 

base-commit: 40fbbd64bba6c6e7a72885d2f59b6a3be9991eeb
-- 
2.47.3

Re: [PATCH v2] mm/page_alloc: Report 1 as zone_batchsize for !CONFIG_MMU

[Vlastimil Babka]

On 12/18/25 09:31, Joshua Hahn wrote:
> Commit 2783088ef24e ("mm/page_alloc: prevent reporting pcp->batch = 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 = 0")
> Reported-by: Daniel Palmer <daniel@thingy.jp>
> Closes: https://lore.kernel.org/linux-mm/CAFr9PX=_HaM3_xPtTiBn5Gw5-0xcRpawpJ02NStfdr0khF2k7g@mail.gmail.com/
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Closes: https://lore.kernel.org/all/42143500-c380-41fe-815c-696c17241506@roeck-us.net/
> Signed-off-by: Joshua Hahn <joshua.hahnjy@gmail.com>

Reviewed-by: Vlastimil Babka <vbabka@suse.cz>

> ---
> v1 --> v2:
> - Instead of restoring  max(1, zone_batchsize(zone)), just return 1 for NOMMU
>   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
>  }
>  
> 
> base-commit: 40fbbd64bba6c6e7a72885d2f59b6a3be9991eeb

Re: [PATCH v2] mm/page_alloc: Report 1 as zone_batchsize for !CONFIG_MMU

[Daniel Palmer]

Hi Joshua,

On Thu, 18 Dec 2025 at 17:32, Joshua Hahn <joshua.hahnjy@gmail.com> wrote:
>
> Commit 2783088ef24e ("mm/page_alloc: prevent reporting pcp->batch = 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.

Tested this on my 68000 setup, filled the memory to cause an OOM and I
got OOM instead of deadlock as expected.

Tested-by: Daniel Palmer <daniel@thingy.jp>

FWIW There was a BoF about NOMMU at LPC last week and I did mention to
the people presenting that seem to be using NOMMU in real world
applications that NOMMU was broken in mainline. I hoped they would
have chimed in on this..

Thanks!

Daniel

Re: [PATCH v2] mm/page_alloc: Report 1 as zone_batchsize for !CONFIG_MMU

[Guenter Roeck]

On 12/18/25 04:30, Daniel Palmer wrote:
> Hi Joshua,
> 
> On Thu, 18 Dec 2025 at 17:32, Joshua Hahn <joshua.hahnjy@gmail.com> wrote:
>>
>> Commit 2783088ef24e ("mm/page_alloc: prevent reporting pcp->batch = 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.
> 
> Tested this on my 68000 setup, filled the memory to cause an OOM and I
> got OOM instead of deadlock as expected.
> 
> Tested-by: Daniel Palmer <daniel@thingy.jp>
> 
> FWIW There was a BoF about NOMMU at LPC last week and I did mention to
> the people presenting that seem to be using NOMMU in real world
> applications that NOMMU was broken in mainline. I hoped they would
> have chimed in on this..
> 

Unrelated to this problem, but I gave up testing NOMMU for arm and xtensa
because it was too difficult to maintain the toolchains for it.

Guenter

Re: [PATCH v2] mm/page_alloc: Report 1 as zone_batchsize for !CONFIG_MMU

[Hajime Tazaki]

Hello Daniel,

On Thu, 18 Dec 2025 06:30:42 -0600,
Daniel Palmer wrote:
> 
> Hi Joshua,
> 
> On Thu, 18 Dec 2025 at 17:32, Joshua Hahn <joshua.hahnjy@gmail.com> wrote:
> >
> > Commit 2783088ef24e ("mm/page_alloc: prevent reporting pcp->batch = 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.
> 
> Tested this on my 68000 setup, filled the memory to cause an OOM and I
> got OOM instead of deadlock as expected.
> 
> Tested-by: Daniel Palmer <daniel@thingy.jp>
> 
> FWIW There was a BoF about NOMMU at LPC last week and I did mention to
> the people presenting that seem to be using NOMMU in real world
> applications that NOMMU was broken in mainline. I hoped they would
> have chimed in on this..

I tested with UML with nommu extension (currently out of kernel *1)
and reproduced the issue with a crafted program causing OOM.

without patch it indeed hangs up with losing console access and this
patch fixes with a proper failure message like below;

oom: page allocation failure: order:12, mode:0xcc0(GFP_KERNEL), nodemask=(null)
CPU: 0 UID: 0 PID: 32 Comm: oom Not tainted 6.18.0-12966-gc43a4f128407-dirty #223 NONE
Stack:
 60a8fb80 604a246e 603b9569 00000001
 ffffff00 604a246e 6002440d 604a1479
 60a8fbb0 6002bbb3 60556910 00000000
Call Trace:
 [<6002440d>] ? _printk+0x0/0x5b
 [<6002df89>] show_stack+0x11c/0x12b
 [<603b9569>] ? dump_stack_print_info+0x0/0x12f
 [<6002440d>] ? _printk+0x0/0x5b
 [<6002bbb3>] dump_stack_lvl+0x65/0x80
 [<6002bbec>] dump_stack+0x1e/0x20
 [<600e0c13>] warn_alloc+0x118/0x195
 [<60083ae0>] ? __mutex_trylock+0x16/0x1e
(snip)


Tested-by: Hajime Tazaki <thehajime@gmail.com>

*1 https://lore.kernel.org/all/cover.1762588860.git.thehajime@gmail.com/

-- Hajime

Re: [PATCH v2] mm/page_alloc: Report 1 as zone_batchsize for !CONFIG_MMU

[Guenter Roeck]

On Thu, Dec 18, 2025 at 12:31:59AM -0800, Joshua Hahn wrote:
> Commit 2783088ef24e ("mm/page_alloc: prevent reporting pcp->batch = 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 = 0")
> Reported-by: Daniel Palmer <daniel@thingy.jp>
> Closes: https://lore.kernel.org/linux-mm/CAFr9PX=_HaM3_xPtTiBn5Gw5-0xcRpawpJ02NStfdr0khF2k7g@mail.gmail.com/
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Closes: https://lore.kernel.org/all/42143500-c380-41fe-815c-696c17241506@roeck-us.net/
> Signed-off-by: Joshua Hahn <joshua.hahnjy@gmail.com>

Tested-by: Guenter Roeck <linux@roeck-us.net>

Guenter

Re: [PATCH v2] mm/page_alloc: Report 1 as zone_batchsize for !CONFIG_MMU

[SeongJae Park]

On Thu, 18 Dec 2025 00:31:59 -0800 Joshua Hahn <joshua.hahnjy@gmail.com> wrote:

> Commit 2783088ef24e ("mm/page_alloc: prevent reporting pcp->batch = 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 = 0")
> Reported-by: Daniel Palmer <daniel@thingy.jp>
> Closes: https://lore.kernel.org/linux-mm/CAFr9PX=_HaM3_xPtTiBn5Gw5-0xcRpawpJ02NStfdr0khF2k7g@mail.gmail.com/
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Closes: https://lore.kernel.org/all/42143500-c380-41fe-815c-696c17241506@roeck-us.net/
> Signed-off-by: Joshua Hahn <joshua.hahnjy@gmail.com>

Acked-by: SeongJae Park <sj@kernel.org>


Thanks,
SJ

[...]