fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
hchiramm_ has joined #systemtap
hchiramm has quit [Ping timeout: 244 seconds]
<jhg_>
Are there any clever and fun ways to traverse these hash lists associated with the VFS inode?
<jhg_>
it seems gdb can gather some of this information
hpt has joined #systemtap
scox has joined #systemtap
hchiramm_ has quit [Ping timeout: 250 seconds]
fche has quit [Ping timeout: 260 seconds]
hchiramm_ has joined #systemtap
hchiramm__ has joined #systemtap
hchiramm_ has quit [Ping timeout: 252 seconds]
hchiramm__ has quit [Ping timeout: 250 seconds]
irker990 has quit [Quit: transmission timeout]
hchiramm has joined #systemtap
ananth has joined #systemtap
ravi_ has joined #systemtap
hchiramm has quit [Ping timeout: 250 seconds]
hchiramm has joined #systemtap
zodbot has quit [Disconnected by services]
hchiramm has quit [Ping timeout: 250 seconds]
srikar_away is now known as srikar
zodbot has joined #systemtap
ananth has quit [Ping timeout: 276 seconds]
hchiramm has joined #systemtap
pmuldoon has quit [Remote host closed the connection]
tonyj_ has quit [Read error: Connection reset by peer]
pmuldoon has joined #systemtap
hpt has quit [Ping timeout: 258 seconds]
hpt has joined #systemtap
hpt has quit [Quit: leaving]
ph7 has joined #systemtap
ph7 has quit [Quit: Leaving.]
scox has quit [Ping timeout: 276 seconds]
fche has joined #systemtap
nkambo1 has joined #systemtap
nkambo has quit [Ping timeout: 258 seconds]
pmuldoon has quit [Quit: Leaving]
pmuldoon has joined #systemtap
wcohen has quit [Ping timeout: 276 seconds]
ravi_ has quit [Remote host closed the connection]
<jhg_>
my exact error message: ERROR: read fault [man error::fault] at 0x0000000000060133 (addr) near operator '@cast' at /usr/share/systemtap/tapset/linux/dentry.stp:73:25
<jhg_>
oh wait... does @cast(inode, "struct inode")->i_dentry->first, even exist?
<jhg_>
yes. yes, it does. struct hlist_head i_dentry; OR (union) struct rcu_head i_rcu;
<jhg_>
hm... something is wrong with my systemtap... I remember dentry::inode_name() working in the past
<jhg_>
fche: ^ when you get a moment
<fche>
that addr 0x60133 looks like a very wrong address
<jhg_>
fche: inode number instead of pointer to the struct. thanks
<jhg_>
so how do I find this address. hmmm
blU0 has joined #systemtap
<jhg_>
hmm... it changes around a bit
nkambo1 has quit [Ping timeout: 240 seconds]
hchiramm has joined #systemtap
hchiramm has quit [Ping timeout: 250 seconds]
hchiramm has joined #systemtap
srikar is now known as srikar_away
irker286 has quit [Quit: transmission timeout]
nkambo has joined #systemtap
hchiramm has quit [Ping timeout: 250 seconds]
<jhg_>
damn... I can't seem to match on the dentry->d_name
<jhg_>
which is really kernel_string($dentry->d_name->name)
<fche>
what do you mean can't match on ?
scox_ has joined #systemtap
<jhg_>
there is a certain dentry that I know is getting modified at some point via dput(), yet I cannot seem to match the strings. http://hastebin.com/irofikazox.pl
<jhg_>
or unhash
scox_ has quit [Client Quit]
<jhg_>
of the name of the file in question
<fche>
maybe try substring-match as in =~ or isinstr() ?
* jhg_
looks it up
hchiramm has joined #systemtap
<jhg_>
so ( "some string to be searched" =~ "*string*") == 1
<fche>
=~ is regex not glob
<fche>
=~ "string" should do it; methinks we're by default unanchored
* jhg_
nods
blUz has joined #systemtap
mbenitez has quit [Quit: Leaving]
blU0 has quit [Ping timeout: 250 seconds]
<jhg_>
damn... nothing. even when I do a rmdir.
<fche>
where are you setting a probe ?
<fche>
dput & dentry_unhash?
<fche>
not familiar enough with vfs internals to know whether those are likely to trap rmdir's
<jhg_>
the interface between the AFS kernel module and the linux kernel that does the business of unhashing or some such.
<jhg_>
re: vfs, me either. learning.
<fche>
then you can start some bulkier tracing - don't bother filter at first, just print $$parms e.g.
wcohen has quit [Ping timeout: 240 seconds]
tromey has quit [Quit: ERC (IRC client for Emacs 25.1.1)]
brolley has left #systemtap [#systemtap]
<jhg_>
fche: what kind of hardening should or can I do to the char array strings that may or may not exist for kernel_string()?
<jhg_>
I get things like this with some frequency: ERROR: kernel string copy fault at 0x0000000000000038 [man error::fault] near identifier 'kernel_string' at /usr/share/systemtap/tapset/linux/conversions.stp:18:10
<jhg_>
and I have it wrapped with a if (@defined($dentry->d_iname))
<jhg_>
and somehow systemtap is getting it right with $$vars$$
hchiramm has quit [Ping timeout: 250 seconds]
<jistone>
kernel_string(ptr, "alt")
<jistone>
or roll your own: try { s=kernel_string(ptr) } catch { do something else }
<jistone>
^ jhg_
<jistone>
kernel_string_quoted is nice too
<jhg_>
jistone: just saw that. why would it error though?
<jistone>
jhg_, what do you mean? a bad pointer is... bad. @defined is not about the quality of the pointer, just whether we know how to access something
mbenitez has joined #systemtap
mbenitez has quit [Changing host]
mbenitez has joined #systemtap
mbenitez has quit [Remote host closed the connection]
<jhg_>
right. I have lost my mind. this is a question for vfs and why they have dentry's without names
<jhg_>
or even valid pointers for the name string?
<jhg_>
that doesn't really make sense
<jhg_>
kernel_string_quoted() looks good
<jhg_>
very weird. some dentry, like for dbus-daemon, can be concatenated into error messages...
drsmith has left #systemtap [#systemtap]
<jhg_>
(the d_iname, that is)
hchiramm has joined #systemtap
<jhg_>
jistone: even kernel_string_quoted() appears to croak when trying to look for a member which does not exist
<jhg_>
@defined perhaps
<jistone>
right, @defined to guard for things that may not exist or have good dwarf
<jistone>
things like kernel_string_quoted for pointers that may be invalid memory
<jhg_>
if (@defined($dentry->d_name)) always returns false. hmm.
<jistone>
ah, because that's a struct. so this is a little loose, but it means d_name is not something you can read directly
<jistone>
try @defined(& $dentry->d_name), or a further field underneath
<jhg_>
that worked better, but now we hard fault out: ERROR: read fault [man error::fault] at 0x0000000000000028 (addr) near identifier '$dentry' at osi_dentry_trace.stp:32:48
<fche>
I bet your incoming $dentry is simply 0
<jhg_>
fche: you win!
<jhg_>
yay! mystery solved... I can spelunker again. =)
<fche>
systemtap, your essential tool for software spelunking