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

[linuxtestproject.agent@gmail.com]

Hi Stephen,

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

>  static void func_iinfo(int hidx)
>  {
> -	if (hidx >= 0) {
> -		sem_index = hidx;
> +	if (hidx >= 0)
>  		tst_res(TPASS, "the highest index is correct");
> -	} else {
> -		sem_index = 0;
> +	else
>  		tst_res(TFAIL, "the highest index is incorrect");
> -	}
>  }

hidx comes from SAFE_SEMCTL(..., IPC_INFO, ...) in verify_semctl().
safe_semctl() already calls tst_brk(TBROK) when the return value is
negative for IPC_INFO (sem_ret_check() falls into the default branch,
"return ret < 0"), so hidx cannot be negative here.

That means the TFAIL branch is unreachable and the IPC_INFO test case
can only ever report TPASS.

Before this patch the function at least had the side effect of
publishing sem_index. Now that this is gone, is there anything left for
this test case to verify? Comparing hidx against the index returned by
the new lookup helper would give it some meaning, otherwise it is just
a check that the framework already made.

> -	if (semidx >= 0)
> +	if (semidx == sem_id)
>  		tst_res(TPASS, "id of the semaphore set is correct");
>  	else
> -		tst_res(TFAIL, "id of the semaphore set is incorrect");
> +		tst_res(TFAIL, "expected sem_id %d, got %d", sem_id, semidx);

The parameter is the SEM_STAT return value, which is a semid and not an
index, and it is now compared against sem_id. Would renaming it to
semid (or rval) match what it holds? "expected sem_id %d, got %d" reads
oddly against a variable called semidx.

> +/*
> + * SEM_STAT takes an index into the kernel's internal array, not a semid.
> + * Return the index that maps to this test's set.
> + */
> +static int get_sem_idx_from_id(int id)

This sits between the tests[] table and verify_semctl(), which splits
the table from its only consumer. All other helpers in this file are
defined above tests[] - could this one go there too?

shmctl01.c uses the same get_shm_idx_from_id() idiom and additionally
prints the mapping:

	tst_res(TINFO, "shm_id=%i maps to kernel index=%i", shm_id, shm_idx);

Adding the equivalent TINFO here would help when the SEM_STAT case
fails on a busy machine.

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