When looking through the results of the nightly tests on Red Hat Enterprise Linux 5 (2.6.18-92.1.6.el5 kernel) a number of the syscall.stp test failed: FAIL: 64-bit access FAIL: 64-bit chmod FAIL: 64-bit forkwait FAIL: 64-bit link FAIL: 32-bit access FAIL: 32-bit chmod FAIL: 32-bit forkwait FAIL: 32-bit link Looking through the output found output like the following for the access test: access: access ("foobar1", F_OK) = access: faccessat (AT_FDCWD, "foobar1", F_OK) = 0 0 The sys_access function is just a wrapper for the sys_faccessat function. Thus, the faccessat output occurs in the middle. This is not what users are expecting. Look at 2.6.26 kernel also saw similar problems with sys_chmod and sys_creat.
One possible fix is to extend the syscalls tapset thusly: # add someplace global syscall_inplay probe process.syscall { syscall_inplay[tid()] = $syscall } probe process.syscall.return { delete syscall_inplay[tid()] } probe process.thread.end { delete syscall_inplay[tid()] } # then for each "nestable" system call handler probe syscall.faccessat = kernel.function(" ...") { if (syscall_inplay[tid()]) next; } Alternately, one can instrument just the "nester" and "nestee" probe pairs with similar logic, without general system-wide utrace syscall probes. Alternately, one can kludge the test case to accept and ignore such nesting. :-(
(In reply to comment #1) > Alternately, one can kludge the test case to accept and ignore such > nesting. :-( I actually did this a while ago: commit 5311c037f83f66967f9de4cc66815f93940bb005 Author: Mark Wielaard <mjw@redhat.com> Date: Sun Oct 5 00:29:49 2008 +0200 Expect syscall faccessat, fchmodat, linkat, symlinkat, readlinkat chain-call diff --git a/testsuite/systemtap.syscall/ChangeLog b/testsuite/systemtap.syscall index 772f980..7cb97df 100644 --- a/testsuite/systemtap.syscall/ChangeLog +++ b/testsuite/systemtap.syscall/ChangeLog @@ -1,3 +1,11 @@ +2008-10-04 Mark Wielaard <mjw@redhat.com> + + * access.c: sys_access() calls through to sys_faccessat(). + * chmod.c: sys_chmod() calls through to sys_fchmodat(). + * link.c: sys_link() calls through to sys_linkat(), + sys_symlink() calls through to sys_symlinkat(), + sys_readlink() calls through to sys_readlinkat().
Since these failures no longer occur on current Red Hat Enterprise Linux 5 (2.6.18-164.el5), I'm closing this one.
This problem periodically reoccurs; we will have to deal with it properly. See bug #11263.
(In reply to Frank Ch. Eigler from comment #4) > This problem periodically reoccurs; we will have to deal with it > properly. See bug #11263. As part of all the syscall tapset work that's been done recently (bug #16716), a fix to avoid syscall nesting has been developed (originally for bug #15219). This fix involves use of the @__syscall_gate() family of macros. This fix basically says if we're in syscall.faccessat, but the syscall number isn't __NR_faccessat, return. Every known instance of this problem has been fixed. It is likely there are problems with syscalls without a test program. We'll have to tackle these as we continue work in this area. I'm going mark this bug as resolved, and we'll just file individual bugs on syscalls without test programs and fix nesting problems then.