From: linuxtestproject.agent@gmail.com
To: Stephen Bertram <sbertram@redhat.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] semctl01: tolerate SEM_STAT races under parallel LTP runs
Date: Mon, 20 Jul 2026 23:13:35 +0000 [thread overview]
Message-ID: <20260720231335.4099-1-linuxtestproject.agent@gmail.com> (raw)
In-Reply-To: <20260720224936.2753334-1-sbertram@redhat.com>
Hi Stephen,
On Mon, 20 Jul 2026 18:49:30 -0400, Stephen Bertram wrote:
> semctl01: tolerate SEM_STAT races under parallel LTP runs
> +static void setup(void)
> +{
> + sem_id = SAFE_SEMGET(IPC_PRIVATE, PSEMS, IPC_CREAT | IPC_EXCL | SEM_RA);
> +}
Moving the SAFE_SEMGET into setup() breaks multi-iteration runs.
The old code had a lazy-init guard inside verify_semctl():
if (sem_id == -1)
sem_id = SAFE_SEMGET(IPC_PRIVATE, PSEMS, IPC_CREAT | IPC_EXCL | SEM_RA);
func_rmid() sets sem_id = -1 after IPC_RMID. On the next iteration
verify_semctl(0) calls SAFE_SEMCTL(sem_id=-1, 0, IPC_STAT, ...) which
returns EINVAL and triggers TBROK. Running ./semctl01 -i 2 reproduces
this immediately.
The lazy-init guard (or equivalent per-iteration re-creation) needs to
be kept.
> +static int do_sem_stat(union semun arg)
> +{
> + int idx, rval;
> + unsigned int retries = 5;
> +
> + do {
> + idx = semctl(0, 0, IPC_INFO, (union semun)&ipc_buf);
> + if (idx < 0)
> + tst_brk(TBROK | TERRNO, "semctl(0, 0, IPC_INFO)");
IPC_INFO is a helper call here, not the syscall under test. Can
SAFE_SEMCTL be used instead?
idx = SAFE_SEMCTL(0, 0, IPC_INFO, (union semun)&ipc_buf);
The behaviour is identical; SAFE_SEMCTL already calls tst_brk on
failure.
> + rval = semctl(idx, 0, SEM_STAT, arg);
> + if (rval >= 0) {
> + sem_index = idx;
> + return rval;
> + }
After this patch sem_index has no remaining readers. The *semid field
was removed from struct tcases so the variable is now write-only:
- func_iinfo() writes sem_index = hidx (and sem_index = 0 on TFAIL)
- do_sem_stat() writes sem_index = idx
But nothing reads it. Can sem_index and all three assignment sites be
removed?
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
next prev parent reply other threads:[~2026-07-20 23:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-14 16:49 [LTP] [PATCH v2] semctl: updates for multi worker testing Stephen Bertram via ltp
2026-04-14 17:15 ` [LTP] " linuxtestproject.agent
2026-07-20 22:49 ` [LTP] [PATCH v3] semctl01: tolerate SEM_STAT races under parallel LTP runs Stephen Bertram via ltp
2026-07-20 23:13 ` linuxtestproject.agent [this message]
2026-07-20 23:56 ` [LTP] [PATCH v4] " Stephen Bertram via ltp
2026-07-21 2:38 ` [LTP] " linuxtestproject.agent
2026-07-21 13:55 ` [LTP] [PATCH v5] " Stephen Bertram via ltp
2026-07-21 14:40 ` [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=20260720231335.4099-1-linuxtestproject.agent@gmail.com \
--to=linuxtestproject.agent@gmail.com \
--cc=ltp@lists.linux.it \
--cc=sbertram@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.