The Linux Kernel Mailing List
 help / color / mirror / Atom feed
* [PATCH] mm: nommu: add sysctl_max_map_count() check for do_mmap()
@ 2026-07-02  1:28 Hajime Tazaki
  2026-07-05 22:10 ` Andrew Morton
  2026-07-05 22:15 ` Andrew Morton
  0 siblings, 2 replies; 6+ messages in thread
From: Hajime Tazaki @ 2026-07-02  1:28 UTC (permalink / raw)
  To: akpm, liam, ljs, vbabka, jannh, pfalcato, linux-mm
  Cc: linux-kernel, Hajime Tazaki

The sysctl variable vm.max_map_count (sysctl_max_map_count) is not
expose under !MMU case but used it wit the default vaule
DEFAULT_MAX_MAP_COUNT as a limit of count.  This is currently used when
a vma entry is split into two chunks (split_vma()) but not used when
allocated (do_mmap()).  As a result, even if users request a large
number of allocate memory, it will keep allocating until OOM happens.

This commit introduces a check at the begining of do_mmap in nommu.c to
prevent this situation.

This is detected with a LTP (Linux Test Project) test, which linked
below.

Link:
https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/munmap/munmap04.c
Signed-off-by: Hajime Tazaki <thehajime@gmail.com>
---
 mm/nommu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/nommu.c b/mm/nommu.c
index 5d461ddc3405..815ebefddfae 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1035,6 +1035,9 @@ unsigned long do_mmap(struct file *file,
 	if (ret < 0)
 		return ret;
 
+	if (current->mm->map_count >= get_sysctl_max_map_count())
+		return -ENOMEM;
+
 	/* we ignore the address hint */
 	addr = 0;
 	len = PAGE_ALIGN(len);
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] mm: nommu: add sysctl_max_map_count() check for do_mmap()
  2026-07-02  1:28 [PATCH] mm: nommu: add sysctl_max_map_count() check for do_mmap() Hajime Tazaki
@ 2026-07-05 22:10 ` Andrew Morton
  2026-07-05 22:15 ` Andrew Morton
  1 sibling, 0 replies; 6+ messages in thread
From: Andrew Morton @ 2026-07-05 22:10 UTC (permalink / raw)
  To: Hajime Tazaki; +Cc: liam, ljs, vbabka, jannh, pfalcato, linux-mm, linux-kernel

On Thu,  2 Jul 2026 10:28:30 +0900 Hajime Tazaki <thehajime@gmail.com> wrote:

> The sysctl variable vm.max_map_count (sysctl_max_map_count) is not
> expose under !MMU case but used it wit the default vaule
> DEFAULT_MAX_MAP_COUNT as a limit of count.

This sounds like an oversight.  I see no reason why nommu users cannot
alter max_map_count.

> This is currently used when
> a vma entry is split into two chunks (split_vma()) but not used when
> allocated (do_mmap()).  As a result, even if users request a large
> number of allocate memory, it will keep allocating until OOM happens.
> 
> This commit introduces a check at the begining of do_mmap in nommu.c to
> prevent this situation.
> 
> ...
>
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -1035,6 +1035,9 @@ unsigned long do_mmap(struct file *file,
>  	if (ret < 0)
>  		return ret;
>  
> +	if (current->mm->map_count >= get_sysctl_max_map_count())
> +		return -ENOMEM;
> +
>  	/* we ignore the address hint */
>  	addr = 0;
>  	len = PAGE_ALIGN(len);

Seems sensible, thanks.  That's what the !NOMMU code does.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] mm: nommu: add sysctl_max_map_count() check for do_mmap()
  2026-07-02  1:28 [PATCH] mm: nommu: add sysctl_max_map_count() check for do_mmap() Hajime Tazaki
  2026-07-05 22:10 ` Andrew Morton
@ 2026-07-05 22:15 ` Andrew Morton
  2026-07-06  0:19   ` Hajime Tazaki
  1 sibling, 1 reply; 6+ messages in thread
From: Andrew Morton @ 2026-07-05 22:15 UTC (permalink / raw)
  To: Hajime Tazaki; +Cc: liam, ljs, vbabka, jannh, pfalcato, linux-mm, linux-kernel

On Thu,  2 Jul 2026 10:28:30 +0900 Hajime Tazaki <thehajime@gmail.com> wrote:

> The sysctl variable vm.max_map_count (sysctl_max_map_count) is not
> expose under !MMU case but used it wit the default vaule
> DEFAULT_MAX_MAP_COUNT as a limit of count.  This is currently used when
> a vma entry is split into two chunks (split_vma()) but not used when
> allocated (do_mmap()).  As a result, even if users request a large
> number of allocate memory, it will keep allocating until OOM happens.
> 
> This commit introduces a check at the begining of do_mmap in nommu.c to
> prevent this situation.
> 
> This is detected with a LTP (Linux Test Project) test, which linked
> below.

AI review flagged a couple of issues in the current code, one quite
serious:

https://sashiko.dev/#/patchset/20260702012830.667205-1-thehajime@gmail.com

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] mm: nommu: add sysctl_max_map_count() check for do_mmap()
  2026-07-05 22:15 ` Andrew Morton
@ 2026-07-06  0:19   ` Hajime Tazaki
  2026-07-06  0:44     ` Andrew Morton
  0 siblings, 1 reply; 6+ messages in thread
From: Hajime Tazaki @ 2026-07-06  0:19 UTC (permalink / raw)
  To: akpm; +Cc: liam, ljs, vbabka, jannh, pfalcato, linux-mm, linux-kernel


On Mon, 06 Jul 2026 07:15:12 +0900,
Andrew Morton wrote:
> 
> On Thu,  2 Jul 2026 10:28:30 +0900 Hajime Tazaki <thehajime@gmail.com> wrote:
> 
> > The sysctl variable vm.max_map_count (sysctl_max_map_count) is not
> > expose under !MMU case but used it wit the default vaule
> > DEFAULT_MAX_MAP_COUNT as a limit of count.  This is currently used when
> > a vma entry is split into two chunks (split_vma()) but not used when
> > allocated (do_mmap()).  As a result, even if users request a large
> > number of allocate memory, it will keep allocating until OOM happens.
> > 
> > This commit introduces a check at the begining of do_mmap in nommu.c to
> > prevent this situation.
> > 
> > This is detected with a LTP (Linux Test Project) test, which linked
> > below.
> 
> AI review flagged a couple of issues in the current code, one quite
> serious:
> 
> https://sashiko.dev/#/patchset/20260702012830.667205-1-thehajime@gmail.com

I will follow up with another patch for the issue detected here.

btw, I found (and sashiko also detected) several typos for this
particular patch.  Can I send v2 patch with the additional fix, or do
you prefer that I'll only send the additional patch ?

anyway, thanks for your time to look at this.

-- Hajime


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] mm: nommu: add sysctl_max_map_count() check for do_mmap()
  2026-07-06  0:19   ` Hajime Tazaki
@ 2026-07-06  0:44     ` Andrew Morton
  2026-07-06  2:03       ` Hajime Tazaki
  0 siblings, 1 reply; 6+ messages in thread
From: Andrew Morton @ 2026-07-06  0:44 UTC (permalink / raw)
  To: Hajime Tazaki; +Cc: liam, ljs, vbabka, jannh, pfalcato, linux-mm, linux-kernel

On Mon, 06 Jul 2026 09:19:02 +0900 Hajime Tazaki <thehajime@gmail.com> wrote:

> 
> On Mon, 06 Jul 2026 07:15:12 +0900,
> Andrew Morton wrote:
> > 
> > On Thu,  2 Jul 2026 10:28:30 +0900 Hajime Tazaki <thehajime@gmail.com> wrote:
> > 
> > > The sysctl variable vm.max_map_count (sysctl_max_map_count) is not
> > > expose under !MMU case but used it wit the default vaule
> > > DEFAULT_MAX_MAP_COUNT as a limit of count.  This is currently used when
> > > a vma entry is split into two chunks (split_vma()) but not used when
> > > allocated (do_mmap()).  As a result, even if users request a large
> > > number of allocate memory, it will keep allocating until OOM happens.
> > > 
> > > This commit introduces a check at the begining of do_mmap in nommu.c to
> > > prevent this situation.
> > > 
> > > This is detected with a LTP (Linux Test Project) test, which linked
> > > below.
> > 
> > AI review flagged a couple of issues in the current code, one quite
> > serious:
> > 
> > https://sashiko.dev/#/patchset/20260702012830.667205-1-thehajime@gmail.com
> 
> I will follow up with another patch for the issue detected here.

Great, thanks.

> btw, I found (and sashiko also detected) several typos for this
> particular patch.  Can I send v2 patch with the additional fix, or do
> you prefer that I'll only send the additional patch ?

Ah.  Well.  Confession.  I actually quietly fed your changelog through
Gemini to fix up a few things, resulting in

: The sysctl variable vm.max_map_count (sysctl_max_map_count) is not exposed
: under !MMU configurations, but its default value (DEFAULT_MAX_MAP_COUNT)
: is still used as a allocation limit.  Currently, this limit is enforced
: when a VMA entry is split into two chunks (split_vma()), but it is not
: checked during initial allocation (do_mmap()).  As a result, if a user
: requests a large number of memory allocations, the system will continue
: allocating until it hits an Out-Of-Memory (OOM) condition.
: 
: This commit introduces a check at the beginning of do_mmap() in nommu.c to
: prevent this situation.
: 
: This issue was detected using the Linux Test Project (LTP) test linked
: below.

I did this "quietly" because it feels a bit rude telling people that
their English isn't great ;)

Lots of non-English speakers appear to be using LLMs on their
changelogs nowadays and as long as they double-check the result, I
think it's working very well!


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] mm: nommu: add sysctl_max_map_count() check for do_mmap()
  2026-07-06  0:44     ` Andrew Morton
@ 2026-07-06  2:03       ` Hajime Tazaki
  0 siblings, 0 replies; 6+ messages in thread
From: Hajime Tazaki @ 2026-07-06  2:03 UTC (permalink / raw)
  To: akpm; +Cc: liam, ljs, vbabka, jannh, pfalcato, linux-mm, linux-kernel

On Mon, 06 Jul 2026 09:44:43 +0900,
Andrew Morton wrote:
> > 
> > I will follow up with another patch for the issue detected here.
> 
> Great, thanks.
> 
> > btw, I found (and sashiko also detected) several typos for this
> > particular patch.  Can I send v2 patch with the additional fix, or do
> > you prefer that I'll only send the additional patch ?
> 
> Ah.  Well.  Confession.  I actually quietly fed your changelog through
> Gemini to fix up a few things, resulting in
> 
> : The sysctl variable vm.max_map_count (sysctl_max_map_count) is not exposed
> : under !MMU configurations, but its default value (DEFAULT_MAX_MAP_COUNT)
> : is still used as a allocation limit.  Currently, this limit is enforced
> : when a VMA entry is split into two chunks (split_vma()), but it is not
> : checked during initial allocation (do_mmap()).  As a result, if a user
> : requests a large number of memory allocations, the system will continue
> : allocating until it hits an Out-Of-Memory (OOM) condition.
> : 
> : This commit introduces a check at the beginning of do_mmap() in nommu.c to
> : prevent this situation.
> : 
> : This issue was detected using the Linux Test Project (LTP) test linked
> : below.

thanks, this is perfect.

> I did this "quietly" because it feels a bit rude telling people that
> their English isn't great ;)
> 
> Lots of non-English speakers appear to be using LLMs on their
> changelogs nowadays and as long as they double-check the result, I
> think it's working very well!

thanks for handling this and a kind way to fix my mistakes.
yes, the AI era.

I will send a follow up patch for the additional issue.

-- Hajime


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2026-07-06  2:03 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-02  1:28 [PATCH] mm: nommu: add sysctl_max_map_count() check for do_mmap() Hajime Tazaki
2026-07-05 22:10 ` Andrew Morton
2026-07-05 22:15 ` Andrew Morton
2026-07-06  0:19   ` Hajime Tazaki
2026-07-06  0:44     ` Andrew Morton
2026-07-06  2:03       ` Hajime Tazaki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox