[LTP] [PATCH v2] mem/min_free_kbytes: Fix incorrect pass/fail accounting
Sachin Sant
sachinp@linux.ibm.com
Fri Jul 10 07:08:41 CEST 2026
On 09/07/26 10:39 pm, Andrea Cervesato wrote:
> Hi Sachin,
>
> I think with this patch we are working around the problem. Which is..
> the test is badly written and it needs a complete refactoring, since
> it seems like a mix of old and new API.
Hi Andrea,
Thank you for the detailed review.
You are right — the original patch was a workaround rather than a proper
fix. The test was mixing old bare-fork patterns with the newer LTP API,
and patching around the symptom without addressing the structural problem
was the wrong approach.
I will rework the patch as a full refactor addressing all points raised:
1. Extract a set_min_free_kbytes() helper that consolidates the three
tune-selection cases using a switch statement and MIN() as suggested,
replacing the open-coded if/else if/else block in test_tune().
2. Replace all bare fork() calls with SAFE_FORK() throughout. The
eatup_mem children in test_tune() are still waited with SAFE_WAITPID
and their exit status is still inspected per-policy, because
overcommit_policy=1 expects SIGKILL — delegating those to
tst_reap_children() would incorrectly produce TBROK on a valid
outcome.
3. Drop the SAFE_WAITPID on the monitor child and its status check
from min_free_kbytes_test() entirely. The monitor child reports its
own TPASS/TFAIL via tst_res() and always exits 0, so the framework's
tst_reap_children() (called automatically after test_all returns)
handles it correctly without any duplicate logic in the test.
4. Revise the commit message to be short and self-explanatory without
re-narrating the diff.
I will send a v3 with the changes included.
--
Thanks
- Sachin
More information about the ltp
mailing list