Linux Test Project
 help / color / mirror / Atom feed
From: linuxtestproject.agent@gmail.com
To: Andrea Cervesato <andrea.cervesato@suse.de>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] mremap01: Convert to new API
Date: Fri,  7 Aug 2026 13:05:58 +0000	[thread overview]
Message-ID: <20260807130558.8420-1-linuxtestproject.agent@gmail.com> (raw)
In-Reply-To: <20260807-rewrite_mremap_testing_suite-v3-1-dcca6d4ac0f1@suse.com>

Hi Andrea,

On Fri, 7 Aug 2026, Andrea Cervesato wrote:
> mremap01: Convert to new API

--- [PATCH 1/7] ---

> static int verify_file(void)
> {
> [...]
> 			tst_res(TFAIL, "file[%zu] == 0x%02x, expected 0x%02x",
> 				off, (unsigned char)got, (unsigned char)off);
> 			return 1;
> [...]
> 	if (verify_file())
> 		tst_res(TFAIL, "mremap()'d region did not sync to the file");

Could verify_file() report the final result directly instead of returning
pass/fail status to run()? A mismatch currently produces both the precise
byte failure and a second generic TFAIL for the same check.

--- [PATCH 3/7] ---

>  * - Obtain an unmapped address via ``tst_get_bad_addr()``.
> [...]
> 	bad_addr = tst_get_bad_addr(NULL);

Could this use an address that is actually unmapped, or describe the
partial-VMA case that is really tested? tst_get_bad_addr() creates and
retains a one-page PROT_NONE mapping, so old_address itself is mapped.

On Linux 7.2 this returns EFAULT because memsize extends beyond that
one-page VMA, not because old_address points to an unmapped region. The
description, algorithm, and commit message therefore claim different
coverage from the executed path.

--- [PATCH 4/7] ---

> Rewrite the test to use TST_EXP_FAIL_PTR_VOID() to verify that
> mremap() fails with MAP_FAILED and ENOMEM when growing an existing
> SysV shared memory mapping in place
> [...]
> Switch the Makefile from libltpipc to libltpnewipc

Could the commit message be updated to match the patch? The code replaces
SysV shared memory with a private anonymous mapping and removes the IPC
library dependency; it does not use libltpnewipc or GETIPCKEY().

--- [PATCH 5/7] ---

> Convert the mremap05 test case from the legacy LTP API to the new
> tst_test API.

Could the body explain why this semantic rewrite is needed and mention
that the positive MREMAP_FIXED cases are split into the later dedicated
test? It currently only restates the subject and does not give the
motivation or explain the series dependency.

--- [PATCH 6/7] ---

> static int check_pattern(char *addr, size_t pages)
> {
> [...]
> 		if (got != exp)
> 			return 1;
> [...]
> 	else if (check_pattern(ret, tc->new_pages))
> 		tst_res(TFAIL, "%s: pattern mismatch", tc->msg);

Could check_pattern() report the result where the mismatch is detected
instead of propagating pass/fail through its return value? Reporting the
offset and observed value there would also make the failure actionable
rather than producing only "pattern mismatch".

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

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

  reply	other threads:[~2026-08-07 13:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-07 12:17 [LTP] [PATCH v3 0/7] Rewrite mremap testing suite Andrea Cervesato
2026-08-07 12:17 ` [LTP] [PATCH v3 1/7] mremap01: Convert to new API Andrea Cervesato
2026-08-07 13:05   ` linuxtestproject.agent [this message]
2026-08-07 12:17 ` [LTP] [PATCH v3 2/7] mremap02: " Andrea Cervesato
2026-08-07 12:17 ` [LTP] [PATCH v3 3/7] mremap03: " Andrea Cervesato
2026-08-07 12:17 ` [LTP] [PATCH v3 4/7] mremap04: " Andrea Cervesato
2026-08-07 12:17 ` [LTP] [PATCH v3 5/7] mremap05: " Andrea Cervesato
2026-08-07 12:17 ` [LTP] [PATCH v3 6/7] mremap08: Extract test from mremap05 Andrea Cervesato
2026-08-07 12:17 ` [LTP] [PATCH v3 7/7] mremap09: Add test for expanding over unmapped gap Andrea Cervesato
  -- strict thread matches above, loose matches on Subject: below --
2026-08-07  6:59 [LTP] [PATCH v2 1/6] mremap01: Convert to new API Andrea Cervesato
2026-08-07  8:19 ` [LTP] " linuxtestproject.agent
2026-07-21 12:41 [LTP] [PATCH 1/5] " Andrea Cervesato
2026-07-21 13:53 ` [LTP] " linuxtestproject.agent

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260807130558.8420-1-linuxtestproject.agent@gmail.com \
    --to=linuxtestproject.agent@gmail.com \
    --cc=andrea.cervesato@suse.de \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox