Issue with rt_sigqueueinfo testcase in LTP:
rohit verma <rohit.170309@gmail.com> reported: I have found an issue with rt_sigqueueinfo test-case. Following is the test output:
rt_sigqueueinfo01 1 PASS : Test Succeeded
rt_sigqueueinfo01 1 FAIL : Test Failed, errno=1 : Operation not permitted
rt_sigqueueinfo01 1 PASS : Test Succeeded
rt_sigqueueinfo01 1 FAIL : Test Failed, errno=1 : Operation not permitted
rt_sigqueueinfo01 0 WARN : tst_rmdir(): rmobj(/tmp/rt_3FaSpK) failed: lstat(/tmp/rt_3FaSpK) failed; errno=2: No such file or directory
I think the following lines are causing the failures:
(Line - 164)
uinfo.si_errno = 0;
uinfo.si_code = 0;//SI_USER
TEST(retval = syscall(__NR_rt_sigqueueinfo, getpid(), 17, &uinfo));
Reason -
You can observe the following comment & source when you look at the Linux source (v 2.6.29) (linux-2.6.29/kernel/signal.c):
/* Not even root can pretend to send signals from the kernel.
Nor can they impersonate a kill(), which adds source info. */
if (info.si_code >= 0)
return -EPERM;
which implies that si_code cannot be set to ' 0 ' (SI_USER) when invoking the rt_sigqueueinfo syscall. I am not sure how to fix this issue. But, a possible fix would be to remove the second set of fork & rt_sigqueueinfo invocations and use the first set (with SI_QUEUE). If needed, the loop count can be increased.
Henry Yei <hyei@mvista.com> replied: Yes, I had just noticed this as well. Since it was "passing", it took awhile to spot. Returning pass even with tst_resm(TFAIL,.. Being called must have something to do with the forking, but I'm not familiar with how the LTP framework deals with that. In any case, I've create this patch for our internal tree that does the following:
- cleans up spacing for tabs, it was mix of two before
- removes the second testcase which is I think is invalid (this gets rid of the bad return code as well).
- removed the inner loop, it doesn't make sense as the tst_exit in the original code would never let it run past the first loop.
- moved cleanup() and setup() to the appropriate places where they will only be called in pairs.
Garrett Cooper <yanegomi@gmail.com> replied: I don't think that's the problem. I think that the real problem is how the testcase itself is written, because I don't see any code that checks WIFEXITED and WIFSIGNALED (I would check for both those items when doing sigqueue), and I don't see where the child(ren) actually exit... HMMM...
1 file changed