[LTP] [PATCH 1/1] min_free_kbytes: TCONF on errno ENOMEM, add break

[LTP] [PATCH 1/1] min_free_kbytes: TCONF on errno ENOMEM, add break

[Petr Vorel]

On machine with 16 GM RAM and ~6 GB swap fork() fails on ENOMEM.
Treat that as TCONF.

While at it, add missing break in case.

Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
I guess we cannot fix this with .min_mem_avail, because it depends also
on available swap.

Also, my investigation was triggered by random failures since this fix
was merged:
355124aea9 ("mem/tunable:min_free_kbytes: fix disabled check_monitor flag") [1]

Kind regards,
Petr

[1] https://github.com/linux-test-project/ltp/commit/355124aea99c7c7d40140c969a53ed892421dee9

 testcases/kernel/mem/tunable/min_free_kbytes.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/testcases/kernel/mem/tunable/min_free_kbytes.c b/testcases/kernel/mem/tunable/min_free_kbytes.c
index a62e4ae9d9..45a3bfc8b1 100644
--- a/testcases/kernel/mem/tunable/min_free_kbytes.c
+++ b/testcases/kernel/mem/tunable/min_free_kbytes.c
@@ -108,7 +108,8 @@ static void test_tune(unsigned long overcommit_policy)
 		fflush(stdout);
 		switch (pid[i] = fork()) {
 		case -1:
-			tst_brk(TBROK | TERRNO, "fork");
+			tst_brk((errno == ENOMEM ? TCONF : TBROK) | TERRNO, "fork");
+			break;
 		case 0:
 			ret = eatup_mem(overcommit_policy);
 			exit(ret);
-- 
2.53.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 1/1] min_free_kbytes: TCONF on errno ENOMEM, add break

[Cyril Hrubis]

Hi!
> On machine with 16 GM RAM and ~6 GB swap fork() fails on ENOMEM.
> Treat that as TCONF.
>
> While at it, add missing break in case.

This looks suspicious. If we fail with the fork here that probably means
that the memory allocated by the previous iteration wasn't reclaimed
fast enough. Was this on a second or third iteration (we do three
iterations with different overcommit values)?

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 1/1] min_free_kbytes: TCONF on errno ENOMEM, add break

[Petr Vorel]

> Hi!
> > On machine with 16 GM RAM and ~6 GB swap fork() fails on ENOMEM.
> > Treat that as TCONF.

> > While at it, add missing break in case.

> This looks suspicious. If we fail with the fork here that probably means
> that the memory allocated by the previous iteration wasn't reclaimed
> fast enough. Was this on a second or third iteration (we do three
> iterations with different overcommit values)?

This is on one of my bare metal machines, first iteration:

min_free_kbytes.c:91: TINFO: Setting /proc/sys/vm/overcommit_memory to 2
min_free_kbytes.c:95: TINFO: Setting /proc/sys/vm/min_free_kbytes to 67584
min_free_kbytes.c:111: TBROK: fork: ENOMEM (12)
tst_test.c:1933: TINFO: Killed the leftover descendant processes

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 1/1] min_free_kbytes: TCONF on errno ENOMEM, add break

[Cyril Hrubis]

Hi!
> > This looks suspicious. If we fail with the fork here that probably means
> > that the memory allocated by the previous iteration wasn't reclaimed
> > fast enough. Was this on a second or third iteration (we do three
> > iterations with different overcommit values)?
> 
> This is on one of my bare metal machines, first iteration:
> 
> min_free_kbytes.c:91: TINFO: Setting /proc/sys/vm/overcommit_memory to 2
> min_free_kbytes.c:95: TINFO: Setting /proc/sys/vm/min_free_kbytes to 67584
> min_free_kbytes.c:111: TBROK: fork: ENOMEM (12)
> tst_test.c:1933: TINFO: Killed the leftover descendant processes

With overcommit = 2 (never) this just means that memory on your machine
has been all consumed[1]. It may make sense to TCONF on overcommit=2 but
I'm not so sure the other two overcommit modes.

[1] The available memory is counted as swap + 50% of RAM

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 1/1] min_free_kbytes: TCONF on errno ENOMEM, add break

[Petr Vorel]

> Hi!
> > > This looks suspicious. If we fail with the fork here that probably means
> > > that the memory allocated by the previous iteration wasn't reclaimed
> > > fast enough. Was this on a second or third iteration (we do three
> > > iterations with different overcommit values)?

> > This is on one of my bare metal machines, first iteration:

> > min_free_kbytes.c:91: TINFO: Setting /proc/sys/vm/overcommit_memory to 2
> > min_free_kbytes.c:95: TINFO: Setting /proc/sys/vm/min_free_kbytes to 67584
> > min_free_kbytes.c:111: TBROK: fork: ENOMEM (12)
> > tst_test.c:1933: TINFO: Killed the leftover descendant processes

> With overcommit = 2 (never) this just means that memory on your machine
> has been all consumed[1]. It may make sense to TCONF on overcommit=2 but
> I'm not so sure the other two overcommit modes.

> [1] The available memory is counted as swap + 50% of RAM

Thanks for info. I set this patch as changes requested. I might send a patch
adding it only for overcommit = 2, but I consider sporadic TFAIL: MemFree <
min_free_kbytes we get as more important to fix.

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] min_free_kbytes: TCONF on errno ENOMEM, add break

[linuxtestproject.agent]

Hi Petr,

On Mon, 25 May 2026 09:39:21 +0200, Petr Vorel wrote:
> min_free_kbytes: TCONF on errno ENOMEM, add break
>
> On machine with 16 GM RAM and ~6 GB swap fork() fails on ENOMEM.

Typo: "GM" → "GB".

> -                       tst_brk(TBROK | TERRNO, "fork");
> +                       tst_brk((errno == ENOMEM ? TCONF : TBROK) | TERRNO, "fork");
> +                       break;

The TCONF handling is correct. Note that `tst_brk()` is `__attribute__((noreturn))`, so the `break` is unreachable. It's still fine to add for static-analysis tools and readability, but the commit message calling it a "missing" break is a stretch — it was never functionally absent.

[...]

---
Note:

Our agent completed the review of the patch. The full review can be
found at: https://github.com/linux-test-project/ltp/actions

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer

---

**Verdict: Needs revision** — fix the "GM" → "GB" typo in the commit body. The code change itself is correct.

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp