[LTP] semctl01: fix SEM_STAT failures under parallel LTP runs

[linuxtestproject.agent@gmail.com]

Hi Stephen,

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

> +/*
> + * get_sem_idx_from_id() relies on this same identity (SEM_STAT(i) == id)
> + * to find sem_index during setup. Re-checking it here still has
> + * meaning: it verifies that SEM_STAT still resolves to our set at
> + * test-execution time, catching the case where a parallel IPC test
> + * reused sem_index in between - the exact race this patch fixes.
> + */
>  static void func_sstat(int semid)

Can a parallel IPC test really reuse sem_index here?

The kernel index is assigned by ipc_idr_alloc() when the set is created
and is only released by ipc_rmid() (ipc/util.c). The set created in
verify_semctl() stays alive until the IPC_RMID entry, which is the last
entry of tests[], so the index is reserved for this set for the whole
run and cannot be handed to another set in between.

The race the patch does fix looks like a different one: IPC_INFO returns
the globally highest used index, which need not belong to this test's
set. Would it be clearer to describe that instead?

Also, comments referring to "this patch" tend to age badly in the source
tree - could that rationale move to the commit message?

Last, the block documents get_sem_idx_from_id() but sits above
func_sstat(), before that helper is declared. Would it read better right
above the helper itself?

> +static int get_sem_idx_from_id(int id)
> +{
> +	struct seminfo info;
> +	struct semid_ds dummy_ds;
> +	union semun arg;
> +	int max_idx, i;

This is the same algorithm as get_shm_idx_from_id() in
testcases/kernel/syscalls/shmctl/shmctl01.c:227.

Would it make sense to put a common helper into libs/newipc so both
tests share it, instead of a second copy? If a shared helper is too
much for this fix, keeping the naming and the TBROK message aligned
with shmctl01 would still help.

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