[LTP] msgstress SysV IPC testing suite

[LTP] msgstress SysV IPC testing suite

[Andrea Cervesato via ltp]

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'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

Re: [LTP] msgstress SysV IPC testing suite

[Petr Vorel]

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