rt_sigqueueinfo
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
rt_sigqueueinfo
by Cyril Hrubis-2
::
Rate this Message:
Hi!
While looking on compilation warnings I've discovered that test testcases/kernel/syscalls/rt_sigqueueinfo/rt_sigqeueuinfo.c has several issues. The most problematic ones are: * There is quite a number of meaningless comments. * There is tst_exit() in the middle of the for cycle, so option -i is effectively disabled * The test is creating temporary directories, why do we need that for testing kernel signal queues? * Why we are forking and doing nothing in the parent process? * We are sending signal 17 that could be SIGUSR2, SIGCHILD or SIGSTOP and depends on hardware platform so symbolic name rather than number should be used. * We are sending singnal but there is no checking that it arrives. * There is no return, exit() or tst_exit() at the end of main() * Casting NULL to (char*) or (option_t*) is meaningless. ... Also test uses usctest.h that is IMHO not really useful because it adds too much complexity and its code is broken too :(. It should be either fixed or thrown away. Looking into crackerjack tests it looks to me like crackerjack just tries to call syscalls to crash the kernel and don't care about the userspace too much (at least the tests I've seen). So using their code is IMHO questionable. And other rt_sig* tests have some of the issues written above. I would really like to fix these tests, but before I start rewriting them, I'm asking for opinions. -- Cyril Hrubis chrubis@... ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Ltp-list mailing list Ltp-list@... https://lists.sourceforge.net/lists/listinfo/ltp-list |
|
|
Re: rt_sigqueueinfo
by Henry Yei
::
Rate this Message:
> -----Original Message-----
> Hi! > While looking on compilation warnings I've discovered that test > testcases/kernel/syscalls/rt_sigqueueinfo/rt_sigqeueuinfo.c has several > issues. > > The most problematic ones are: > > * There is quite a number of meaningless comments. > > * There is tst_exit() in the middle of the for cycle, so option > -i is effectively disabled > > * The test is creating temporary directories, why do we need that > for testing kernel signal queues? > > * Why we are forking and doing nothing in the parent process? > > * We are sending signal 17 that could be SIGUSR2, SIGCHILD or SIGSTOP > and depends on hardware platform so symbolic name rather than number > should be used. > > * We are sending singnal but there is no checking that it > arrives. > > * There is no return, exit() or tst_exit() at the end of main() > > * Casting NULL to (char*) or (option_t*) is meaningless. > > ... > > Also test uses usctest.h that is IMHO not really useful because it adds > too > much complexity and its code is broken too :(. It should be either > fixed or > thrown away. > > Looking into crackerjack tests it looks to me like crackerjack just > tries to > call syscalls to crash the kernel and don't care about the userspace > too much > (at least the tests I've seen). So using their code is IMHO > questionable. > > And other rt_sig* tests have some of the issues written above. > > I would really like to fix these tests, but before I start rewriting > them, > I'm asking for opinions. > > -- > Cyril Hrubis > chrubis@... > Cyril, For the rt_sig* tests I have some changes in my internal tree to set SIGSETSIZE depending on arch rather than to use the hardcoded value of 8 in orderto fix mips failures. Please consider folding this change into your proposal. I've submitted similar changes in a recent ppoll01 patch, and am awaiting comments on correctness. Ex) +#if defined (__mips__) +#define SIGSETSIZE 16 +#else +#define SIGSETSIZE 8 +#endif -TEST(syscall(__NR_rt_sigprocmask, SIG_BLOCK, &set, &oset, 8)); +TEST(syscall(__NR_rt_sigprocmask, SIG_BLOCK, &set, &oset, SIGSETSIZE)); ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Ltp-list mailing list Ltp-list@... https://lists.sourceforge.net/lists/listinfo/ltp-list |
|
|
Re: rt_sigqueueinfo
by Subrata Modak
::
Rate this Message:
On Thu, 2009-11-05 at 12:34 -0800, Henry Yei wrote:
> > -----Original Message----- > > Hi! > > While looking on compilation warnings I've discovered that test > > testcases/kernel/syscalls/rt_sigqueueinfo/rt_sigqeueuinfo.c has several > > issues. > > > > The most problematic ones are: > > > > * There is quite a number of meaningless comments. > > > > * There is tst_exit() in the middle of the for cycle, so option > > -i is effectively disabled > > > > * The test is creating temporary directories, why do we need that > > for testing kernel signal queues? > > > > * Why we are forking and doing nothing in the parent process? > > > > * We are sending signal 17 that could be SIGUSR2, SIGCHILD or SIGSTOP > > and depends on hardware platform so symbolic name rather than number > > should be used. > > > > * We are sending singnal but there is no checking that it > > arrives. > > > > * There is no return, exit() or tst_exit() at the end of main() > > > > * Casting NULL to (char*) or (option_t*) is meaningless. > > > > ... > > > > Also test uses usctest.h that is IMHO not really useful because it adds > > too > > much complexity and its code is broken too :(. It should be either > > fixed or > > thrown away. > > > > Looking into crackerjack tests it looks to me like crackerjack just > > tries to > > call syscalls to crash the kernel and don't care about the userspace > > too much > > (at least the tests I've seen). So using their code is IMHO > > questionable. > > > > And other rt_sig* tests have some of the issues written above. > > > > I would really like to fix these tests, but before I start rewriting > > them, > > I'm asking for opinions. > > > > -- > > Cyril Hrubis > > chrubis@... > > > > Cyril, > > For the rt_sig* tests I have some changes in my internal tree to set SIGSETSIZE depending on arch rather than to use the hardcoded value of 8 in orderto fix mips failures. Please consider folding this change into your proposal. I've submitted similar changes in a recent ppoll01 patch, and am awaiting comments on correctness. > > Ex) > > +#if defined (__mips__) > +#define SIGSETSIZE 16 > +#else > +#define SIGSETSIZE 8 > +#endif > > -TEST(syscall(__NR_rt_sigprocmask, SIG_BLOCK, &set, &oset, > 8)); > +TEST(syscall(__NR_rt_sigprocmask, SIG_BLOCK, &set, &oset, > SIGSETSIZE)); Yes, i would vote for this approach. Please consider submitting your overall changes. Regards-- Subrata > > > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Ltp-list mailing list > Ltp-list@... > https://lists.sourceforge.net/lists/listinfo/ltp-list ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Ltp-list mailing list Ltp-list@... https://lists.sourceforge.net/lists/listinfo/ltp-list |
|
|
Re: rt_sigqueueinfo
by Cyril Hrubis-2
::
Rate this Message:
Hi!
> For the rt_sig* tests I have some changes in my internal tree to set SIGSETSIZE depending on arch rather than to use the hardcoded value of 8 in orderto fix mips failures. Please consider folding this change into your proposal. I've submitted similar changes in a recent ppoll01 patch, and am awaiting comments on correctness. > > Ex) > > +#if defined (__mips__) > +#define SIGSETSIZE 16 > +#else > +#define SIGSETSIZE 8 > +#endif > > -TEST(syscall(__NR_rt_sigprocmask, SIG_BLOCK, &set, &oset, > 8)); > +TEST(syscall(__NR_rt_sigprocmask, SIG_BLOCK, &set, &oset, > SIGSETSIZE)); > Well there is _SIGSET_NWORDS macro defined in my /usr/include/sigset/bits.h header and it's defined as (1024 / (8 * sizeof (unsigned long int). Anyway this should be moved to some header in $LTPROOT/include/ or better we should test for _SIGSET_NWORDS aviability in configure script. -- Cyril Hrubis chrubis@... ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Ltp-list mailing list Ltp-list@... https://lists.sourceforge.net/lists/listinfo/ltp-list |
|
|
Re: rt_sigqueueinfo
by Cyril Hrubis-2
::
Rate this Message:
Hi!
> Well there is _SIGSET_NWORDS macro defined in my /usr/include/sigset/bits.h > header and it's defined as (1024 / (8 * sizeof (unsigned long int). Anyway > this should be moved to some header in $LTPROOT/include/ or better we should > test for _SIGSET_NWORDS aviability in configure script. ... and fallback to (1024 / (8 * sizeof (unsigned long int) if there is no _SIGSET_NWORDS macro defined. -- Cyril Hrubis chrubis@... ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Ltp-list mailing list Ltp-list@... https://lists.sourceforge.net/lists/listinfo/ltp-list |
|
|
Re: rt_sigqueueinfo
by Henry Yei
::
Rate this Message:
I checked the value of (1024 / (8 * sizeof (unsigned long int))) and it is 32 on both our mips, mips64, and x86 targets. Calling ppoll fails with invalid argument error in all of these cases. I don't see a user/include/sigset/bits.h header in our userland, but _SIGSET_NWORDS macro also returns 32 when printed out.
> -----Original Message----- > From: Cyril Hrubis [mailto:chrubis@...] > Sent: Monday, November 16, 2009 8:23 AM > To: Henry Yei > Cc: ltp-list@... > Subject: Re: [LTP] rt_sigqueueinfo > > Hi! > > For the rt_sig* tests I have some changes in my internal tree to set > SIGSETSIZE depending on arch rather than to use the hardcoded value of > 8 in orderto fix mips failures. Please consider folding this change > into your proposal. I've submitted similar changes in a recent ppoll01 > patch, and am awaiting comments on correctness. > > > > Ex) > > > > +#if defined (__mips__) > > +#define SIGSETSIZE 16 > > +#else > > +#define SIGSETSIZE 8 > > +#endif > > > > -TEST(syscall(__NR_rt_sigprocmask, SIG_BLOCK, &set, &oset, > > 8)); > > +TEST(syscall(__NR_rt_sigprocmask, SIG_BLOCK, &set, &oset, > > SIGSETSIZE)); > > > > Well there is _SIGSET_NWORDS macro defined in my > /usr/include/sigset/bits.h > header and it's defined as (1024 / (8 * sizeof (unsigned long int). > Anyway > this should be moved to some header in $LTPROOT/include/ or better we > should > test for _SIGSET_NWORDS aviability in configure script. > > -- > Cyril Hrubis > chrubis@... ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Ltp-list mailing list Ltp-list@... https://lists.sourceforge.net/lists/listinfo/ltp-list |
|
|
Re: rt_sigqueueinfo
by Cyril Hrubis-2
::
Rate this Message:
Hi!
> I checked the value of (1024 / (8 * sizeof (unsigned long int))) and it is 32 > on both our mips, mips64, and x86 targets. Calling ppoll fails with invalid > argument error in all of these cases. I don't see a > user/include/sigset/bits.h header in our userland, but _SIGSET_NWORDS macro > also returns 32 when printed out. My mistake, the last size argument is sizeof(sigset_t) but not the userspace one but the kernel sigset_t (that is defined as bitfield big enough for all signals). Glibc pases _NSIG/8 here which seems to be correct (as _NSIG is defined as 128 on mips). -- Cyril Hrubis chrubis@... ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Ltp-list mailing list Ltp-list@... https://lists.sourceforge.net/lists/listinfo/ltp-list |
|
|
Re: rt_sigqueueinfo
by Henry Yei
::
Rate this Message:
> > I checked the value of (1024 / (8 * sizeof (unsigned long int))) and
> it is 32 > > on both our mips, mips64, and x86 targets. Calling ppoll fails with > invalid > > argument error in all of these cases. I don't see a > > user/include/sigset/bits.h header in our userland, but _SIGSET_NWORDS > macro > > also returns 32 when printed out. > > My mistake, the last size argument is sizeof(sigset_t) but not the > userspace > one but the kernel sigset_t (that is defined as bitfield big enough for > all > signals). Glibc pases _NSIG/8 here which seems to be correct (as _NSIG > is > defined as 128 on mips). > > -- > Cyril Hrubis > chrubis@... Cyril, Thanks, changing hardcoded/defined values to _NSIG/8 does the trick for the following tests: ppoll01, rt_sigprocmask01, rt_sigprocmask02, rt_sigsuspend01, signalfd4_01, signalfd4_02. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Ltp-list mailing list Ltp-list@... https://lists.sourceforge.net/lists/listinfo/ltp-list |
|
|
Re: rt_sigqueueinfo
by yaneurabeya
::
Rate this Message:
On Thu, Nov 19, 2009 at 3:11 PM, Henry Yei <hyei@...> wrote:
>> > I checked the value of (1024 / (8 * sizeof (unsigned long int))) and >> it is 32 >> > on both our mips, mips64, and x86 targets. Calling ppoll fails with >> invalid >> > argument error in all of these cases. I don't see a >> > user/include/sigset/bits.h header in our userland, but _SIGSET_NWORDS >> macro >> > also returns 32 when printed out. >> >> My mistake, the last size argument is sizeof(sigset_t) but not the >> userspace >> one but the kernel sigset_t (that is defined as bitfield big enough for >> all >> signals). Glibc pases _NSIG/8 here which seems to be correct (as _NSIG >> is >> defined as 128 on mips). >> >> -- >> Cyril Hrubis >> chrubis@... > > Cyril, > > Thanks, changing hardcoded/defined values to _NSIG/8 does the trick for the following tests: ppoll01, rt_sigprocmask01, rt_sigprocmask02, rt_sigsuspend01, signalfd4_01, signalfd4_02. I'll go ahead and fix all these. Thanks, -Garrett ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Ltp-list mailing list Ltp-list@... https://lists.sourceforge.net/lists/listinfo/ltp-list |
| Free embeddable forum powered by Nabble | Forum Help |
