[Bug tapsets/6762] New: Some syscalls functions just wrappers for other syscalls

[Bug tapsets/6762] New: Some syscalls functions just wrappers for other syscalls

[wcohen at redhat dot com]

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.

-- 
           Summary: Some syscalls functions just wrappers for other syscalls
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: wcohen at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=6762

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/6762] Some syscalls functions just wrappers for other syscalls

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-10-20 16:50 -------
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.  :-(


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6762

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/6762] Some syscalls functions just wrappers for other syscalls

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2008-10-20 18:53 -------
(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().


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6762

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/6762] Some syscalls functions just wrappers for other syscalls

[dsmith at redhat dot com]

------- Additional Comments From dsmith at redhat dot com  2010-01-13 21:02 -------
Since these failures no longer occur on current Red Hat Enterprise
Linux 5 (2.6.18-164.el5), I'm closing this one.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsmith at redhat dot com
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=6762

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/6762] Some syscalls functions just wrappers for other syscalls

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2010-02-16 20:04 -------
This problem periodically reoccurs; we will have to deal with it
properly.  See bug #11263.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


http://sourceware.org/bugzilla/show_bug.cgi?id=6762

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug tapsets/6762] Some syscalls functions just wrappers for other syscalls

[dsmith at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=6762

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from David Smith <dsmith at redhat dot com> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.