[Bug runtime/5042] procfs probe script not recreating /proc entries in some cases

[mmlnx at us dot ibm dot com]

------- Additional Comments From mmlnx at us dot ibm dot com  2007-09-18 20:30 -------
(In reply to comment #2)
> Created an attachment (id=2010)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=2010&action=view)
> possible fix
> 
> Can you try this patch and see what you think?

The behavior is different with this patch, but still not correct.  Here's what I
did to test: 

1. Run "staprun <module>.ko" in an xterm.  The module creates /proc/systemtap,
/proc/systemtap/<module>, and /proc/systemtap/<module>/<value>.

2. In a second xterm, cd to /proc/systemtap/<module>.

3. Ctrl-c out of staprun.  The deferred deletion messages appear in
/var/log/messages as before, but staprun doesn't exit yet.

4. cd ../ in the second xterm.

5. The <module> directory is now deleted and staprun exits.  From a third xterm,
do "ls /proc".  /proc/systemtap does not appear.  However, pwd in the second
xterm indicates it's still there.  It must be in some interim state (deleted,
but not completely).

6. Reload the module again with "staprun <module>.ko".  path_lookup() finds the
existing /proc/systemtap and, thus, doesn't recreate it.  The module just links
<module> and <module>/<value> off of the existing /proc/systemtap.

7. /proc/systemtap can only be accessed in the second xterm.  As soon as I cd
out of /proc/systemtap, it's no longer accessible from a shell even though it
exists in some form.

One solution might be to simply not delete /proc/systemtap.  Let the first
module create it, then leave it around for other modules to use even if the
first module is removed.
  



-- 


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

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