Re: [LTP] [PATCH v2] rseq01: basic test rseq

[Cyril Hrubis <chrubis@suse.cz>]

Hi!
> > > +#if defined(HAVE_SYS_RSEQ_H) && defined(RSEQ_SIG)
> >                                              ^
> > 					     Where is this macro
> > 					     defined?
> RSEQ_SIG is arch specific macro , following are result in my test system:
> 
> find / -name "*.h" | xargs grep RSEQ_SIG
> /usr/include/x86_64-linux-gnu/bits/rseq.h:#define RSEQ_SIG        0x53053053
> 
> dpkg -S /usr/include/x86_64-linux-gnu/bits/rseq.h
> libc6-dev:amd64: /usr/include/x86_64-linux-gnu/bits/rseq.h

If that is a macro defined in a header the it does not make sense to
guard like this. We add fallback definitions instead of disabling code
this way.

> > > +#include <stdio.h>
> > > +#include <sched.h>
> > > +#include "lapi/rseq.h"
> > > +
> > > +static void run(void)
> > > +{
> > > +	check_rseq_available();
> > > +
> > > +	TST_EXP_PASS(!(sched_getcpu() >= 0));
> > 
> > This does not actually check anything useful.
> This case used to test against glibc's implementation, correct me if i am wrong.
> Once i saw following commit in glibc, so i think we can use sched_getcpu 
> do some sanity check for rseq implementation in glibc. 
> 1d350aa060 Linux: Use rseq to accelerate sched_getcpu

The sched_getcpu() would not test rseq at all on anything but glibc and
would give users false hope that rseq was actually tested even if it
was not.

If you want to make sure sched_getcpu() works fine you should write
sched_getcpu() test instead.

> > Very basic test would register rqseq, then loop over available CPUs, pin
> > a process to the CPU and check that rqsed did register the buffers. The
> > very basic test would look like:
> > 
> > https://github.com/torvalds/linux/blob/master/tools/testing/selftests/rseq/basic_test.c
> > 
> 
> Thanks for your feedback, i have a question on test direction, which one is our target?
> 
> 1) Check system call ONLY regardless glibc version/implementation then we move linux kernel test(as above link you mentioned) into our test.
> 
> 2) Check glibc's implemenation for rseq(from 2.35), such as 1.check sched_getcpu, 2.check glibc API 
> how to disable rseq feature which support automaticly from glibc start. (e3e589829d nptl: Add glibc.pthread.rseq tunable to control rseq registration). Then our target is move glibc test case to our test.

Please forget about glibc, it's not the only libc out there. The test
has to work correctly regardless the libc implementation, there are at
least five different libc variants used out there.


-- 
Cyril Hrubis
chrubis@suse.cz

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