Re: dereferencing filenames from a vfs_write probe

[fche at redhat dot com (Frank Ch. Eigler)]

dave-systemtap@skeptech.org writes:

> [...]  This happens to be 2.6.16.19.  I'm curious, how often do
> systemtap scripts need to change in practice because of data
> struture changes in the kernel?

It happens - it's one of the mixed blessings of a fast-churning
kernel.  Once the core of the system settles down, we will be able to
spend more time at pulling in such functions into the script tapset,
so that end-user scripts are better isolated from changes.

> Cool thanks. So based on that code I've chopped out the following function:
> function get_path:string (dentry:dentry *,vsmnt:vsmount *) %{
>   char *page = (char *)__get_free_page(GFP_KERNEL);
>   sprintf("%s",d_path(dentry, vfsmnt, page, PAGE_SIZE));
>   free_page((unsigned long)page);
> %}

Other than this code not compiling, it's not generally proper to make
potentially blocking calls like GFP_KERNEL allocations.  From the
context of your script it may be safe, but functions to be considered
for the general tapset must not make potentially blocking operations
such as a GFP_KERNEL allocation or a lock acquire.

> [...]
> I guess this means I'm only allowed to pass strings or longs into
> embedded C functions. I guess it's time to do some more rtfm'ing. 

(Pointers are cast to longs.)

- FChE