All of lore.kernel.org
 help / color / mirror / Atom feed
From: linuxtestproject.agent@gmail.com
To: Stephen Bertram <sbertram@redhat.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] semctl01: fix SEM_STAT failures under parallel LTP runs
Date: Wed, 29 Jul 2026 18:14:30 +0000	[thread overview]
Message-ID: <20260729181430.8673-1-linuxtestproject.agent@gmail.com> (raw)
In-Reply-To: <20260729175611.4161450-1-sbertram@redhat.com>

Hi Stephen,

On Wed, 29 Jul 2026, Stephen Bertram wrote:
> semctl01: fix SEM_STAT failures under parallel LTP runs

> +	if (hidx >= sem_index)
> +		tst_res(TPASS, "IPC_INFO highest index %d >= our index %d",
> +			hidx, sem_index);
> +	else
> +		tst_res(TFAIL, "IPC_INFO highest index %d < our index %d",
> +			hidx, sem_index);

Can this branch ever take the else path? sem_index is resolved while the
set is alive, and the kernel keeps ipc_get_maxidx() at or above the index
of every live entry - ipc_rmid() only recomputes ids->max_idx when the
removed index was the maximum, and it would then find our entry.

If so the IPC_INFO case no longer asserts anything. Would it make sense
to also validate the returned struct seminfo limits (semmni, semmsl,
semopm) against /proc/sys/kernel/sem, so that IPC_INFO is really
exercised?

> +	arg.__buf = &info;
> +	max_idx = SAFE_SEMCTL(id, 0, SEM_INFO, arg);

The kernel ignores the semid argument for SEM_INFO (semctl_info() never
looks it up), so passing the set id here reads as a per-set query when it
is not.

> +	arg.buf = &dummy_ds;
> +	for (i = 0; i <= max_idx; i++) {
> +		if (semctl(i, 0, SEM_STAT, arg) == id)
> +			return i;
> +	}

The bare semctl() looks deliberate here, since unused or unreadable
indices legitimately fail with EINVAL/EACCES and SAFE_SEMCTL() would
abort. Could a short comment be added to state that, so the missing
SAFE_ wrapper is not raised again on the next read?

The braces are also not needed for the single statement body.

> +		sem_index = get_sem_idx_from_id(sem_id);
> +		if (sem_index < 0)
> +			tst_brk(TBROK, "Failed to get sem_id to idx mapping");

Including sem_id in the message would help diagnose the case where the
lookup does fail.

Verdict - Needs revision

Pre-existing issues, unrelated to this patch:

func_rmid() runs after SAFE_SEMCTL(..., IPC_RMID, ...), and that macro
assigns -1 to its first argument, which is sem_id here. So the
TST_EXP_FAIL(semop(sem_id, ...), EINVAL) check gets EINVAL from the
invalid identifier rather than from the removed set.

msgctl12.c carries the same pattern this patch fixes: index_q is taken
from IPC_INFO in setup() and then used as the MSG_STAT index.

---
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-07-29 18:14 UTC|newest]

Thread overview: 21+ 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   ` [LTP] " linuxtestproject.agent
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
2026-07-28 13:06       ` [LTP] [PATCH v5] " Andrea Cervesato via ltp
2026-07-28 16:23       ` [LTP] [PATCH v6] " Stephen Bertram via ltp
2026-07-28 17:31         ` [LTP] " linuxtestproject.agent
2026-07-28 20:33         ` [LTP] [PATCH v7] semctl01: look up SEM_STAT index for this test's sem_id Stephen Bertram via ltp
2026-07-28 21:12           ` [LTP] " linuxtestproject.agent
2026-07-29 14:53           ` [LTP] [PATCH v8] semctl01: fix SEM_STAT failures under parallel LTP runs Stephen Bertram via ltp
2026-07-29 16:26             ` [LTP] " linuxtestproject.agent
2026-07-29 17:56             ` [LTP] [PATCH v9] " Stephen Bertram via ltp
2026-07-29 18:14               ` linuxtestproject.agent [this message]
2026-07-29 19:33             ` [LTP] [PATCH v10] " Stephen Bertram via ltp
2026-07-29 20:20               ` [LTP] " linuxtestproject.agent
2026-07-29 21:00               ` [LTP] [PATCH v11] " Stephen Bertram via ltp
2026-07-29 22:07                 ` [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=20260729181430.8673-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.