failed to resolve cwd: Unknown variable name

[Dmitry Yu Okunev]

Hello.

On 06/04/2014 06:28 AM, Mark Johnston wrote:
> On Fri, May 30, 2014 at 11:22 AM, Dmitry Yu Okunev <dyokunev at ut.mephi.ru> wrote:
>> Hello.
>>
>> I cannot use dtrace in FreeBSD for my need due to next bug.
>>
>> It's said that there's a build-in variable "cwd" contains "the name of
>> the current working directory of the process associated with the current
>> thread" [1]
>>
>> [1] http://docs.oracle.com/cd/E18752_01/html/819-5488/gcfpz.html
>>
>> But when I try to use the variable I get a failure:
>>> dtrace: invalid probe specifier syscall:::entry { printf("%s", cwd);
>> }: in action list: failed to resolve cwd: Unknown variable name
>>
>> You can get the same error by running a dtrace-script from official
>> FreeBSD distribution:
>>> /usr/share/dtrace/toolkit/opensnoop -c
> 
> Unfortunately, it looks like implementing this variable in FreeBSD
> would be somewhat non-trivial. illumos (and presumably Solaris) caches
> a full path to the file backing a given vnode, whereas FreeBSD only
> caches file names and builds up a full path dynamically in
> vn_fullpath1().

That's strange problem because audit already returns full paths in
FreeBSD. It just uses "vn_fullpath*()"?

> So one can get a bit of the way there with something ugly like
> 
>     inline string cwd =
> stringof(curthread->td_proc->p_fd->fd_cdir->v_cache_dst.tqh_first->nc_name);
> 
> to get the last component of a process' cwd (it needs a check for a
> missing cache entry), but I don't see any easy way to get at the full
> cwd. Calling vn_fullpath() in probe context would be a pretty bad idea
> since it may invoke VFS operations

Hm. If it's performance problem only, then personally I can endure that.

Can I use vn_fullpath*() in dtrace probes on current FreeBSD?

>, so adding support for the cwd
> variable would probably involve adding cache-only lookup code to
> vfs_cache.c. That said, I'm not super familiar with this stuff, so I
> could be missing something; this is just based on my previously
> stymied efforts trying to get a full path for a vnode in a DTrace
> probe, for example when trying to figure out which files are getting
> fsync'ed.

Ok. It's became much more clear. Thanks :)


-- 
Best regards, Dmitry.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-dtrace/attachments/20140604/1d909db7/attachment.sig>