[LTP] ltp: syscalls/madvise09: Reset cgroup memory limits before test retries

[linuxtestproject.agent@gmail.com]

Hi Wake,

On Fri, 10 Jul 2026 02:15:02 +0000, Wake Liu wrote:
> ltp: syscalls/madvise09: Reset cgroup memory limits before test retries

> ### Background
> When executing `madvise09`, the test intermittently fails with:
>
> ```
> madvise09.c:163: TFAIL: MADV_FREE pages were freed immediately
> ...
> madvise09.c:116: TINFO: 0x7476845000 unexpected   (0) at 1 expected 'a'
> madvise09.c:232: TFAIL: Found 2 corrupted page(s)
> ```

The Signed-off-by: tag is missing from the commit message. It is
mandatory and must appear at the end of the body.

The commit body shows the failure symptoms but does not explain the
root cause. The code comment explains it well (cgroup memory.max
persists at MEM_LIMIT after a retry, so the new child inherits a
constrained limit before it can even touch the madvised pages). That
root cause belongs in the commit message body, not only in the source
comment.

> +	if (SAFE_CG_HAS(tst_cg, "memory.max"))
> +		SAFE_CG_PRINT(tst_cg, "memory.max", "max");

> 	SAFE_CG_PRINTF(tst_cg, "memory.max", "%d", MEM_LIMIT);

There is an inconsistency here. The reset is guarded by
SAFE_CG_HAS(tst_cg, "memory.max"), but the subsequent write to the
same file (a few lines later) is unconditional. If memory.max can be
absent, the unconditional write would abort. If it is always present
when the memory controller is available (as the unconditional write
assumes), the guard is dead code and misleading.

setup() uses SAFE_CG_HAS only for memory.swap.max, because swap
accounting is optional. memory.max is mandatory with the memory
controller. Dropping the SAFE_CG_HAS guard from the new code would
be consistent with the rest of the file.

Verdict - Needs revision

---
Note:

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