Re: [LTP] msgstress SysV IPC testing suite

[Petr Vorel <pvorel@suse.cz>]

Hi,

> Hi all,

> I was taking a look msgstress testing suite that is supposed to stress the
> kernel SysV IPC.
> It's a well known testing suite that used to randomly stuck or fail, due to
> the poorly written code.

> I'm about to refactor its code, but I noticed that all 4 tests inside it
> (msgstress01-04) are basically implementing the same concept, if not the
> same code that looks copy-pasted.

> We basically have 2 or more processes reading/writing messages into the SysV
> IPC at the same time.
> If all messages are correctly sent and received, the test passes. The only
> difference is if these processes are spawned inside children or not.

> So I have a quite obvious observation: our main goal is to stress the SysV
> IPC, so we can trigger a bug and it doesn't matter if this is done inside
> children or not.

I hope so. It also looks to me, that all 4 tests do very similar thing.

Also test docs claims that msgstress03.c is msgstress01.c but reads
/proc/sys/kernel/msgmni, similarly msgstress04.c is msgstress02.c but reads
/proc/sys/kernel/msgmni. But I don't see that msgstress0[34].c would read
/proc/sys/kernel/msgmni.  msgget03.c (already rewritten to new API) is the only
test which reads it via .save_restore.

I suppose get_used_msgqueues() (in libs/libltpipc/libipc.c) can still be kept in
the old API and converted after all files are converted. But I would consider
using /proc/sysvipc/msg instead of "ipcs -q".

Thanks for looking this!

Kind regards,
Petr

> I'm planning to remove all those tests and to write a new one following the
> main concept, but without the actual redundancy. What do you think?

> Regards,
> Andrea Cervesato

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