Access of global variables in the script

Access of global variables in the script

[Arkady]

Hi,

My goal is to find out the absolute path of the just opened file in
the context of probe syscall.open.return

I checked the function fullpath_struct_file in the dentry.stp. Can I
code a better (faster) implementation than task_dentry_path() with
inline C?

A side note - task_dentry_path does not lock when traversing the
dentry->parent... tree. Is it safe?

I am trying to implement (essentially copy&paste) a function
dentry_path_raw() from the kernel 2.6.38 in the script targeting
kernel Linux centos6 2.6.32-642.el6.x86_64 #1 SMP Tue May 10 17:27:01
UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

I think that I need to check if the rename_lock is available similarly
two what dentry_path_raw() does (see
http://elixir.free-electrons.com/linux/v2.6.38/source/fs/dcache.c#L2738).
Am I right?

I am doing something like this:
$ sudo stap -e 'probe begin {printf ("addr %d\n",
@var("rename_lock@fs/dcache.c")); exit(); }'

semantic error: while processing probe begin
semantic error: unable to find global 'rename_lock' in kernel, in
fs/dcache.c: operator '@var' at <input>:1:36

In the code include/linux/dcache.h I see the external (not exported)
variable rename_lock
http://elixir.free-electrons.com/linux/v2.6.32/source/include/linux/dcache.h#L190

Why does the build fail?

Thanks

Re: Access of global variables in the script

[Frank Ch. Eigler]

Hi -

> [...]
> I checked the function fullpath_struct_file in the dentry.stp. Can I
> code a better (faster) implementation than task_dentry_path() with
> inline C?
>
> A side note - task_dentry_path does not lock when traversing the
> dentry->parent... tree. Is it safe?

These two issues are related, and represent a deliberate design choice.
When one uses embedded-C code in stap, one has to shoulder the entire
burden of ensuring its safety & correctness.  A pointer use bug there
can bring the machine down.  Blocking for a lock can bring the machine
down.

In contrast, the same algorithm expressed within the script language
will use protected pointer dereferencing, time/space-limited
computation, and no blocking.  In the worst case, the script will stop,
or produce wrong results.  That is much better than the alternative.


> [...]
> semantic error: unable to find global 'rename_lock' in kernel, in
> fs/dcache.c: operator '@var' at <input>:1:36
> [...]

(Not sure about this part.)


- FChE