[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