Date: Wed, 4 Jun 2014 09:25:11 -0400 From: Mark Johnston <markj@freebsd.org> To: Dmitry Yu Okunev <dyokunev@ut.mephi.ru> Cc: "freebsd-dtrace@freebsd.org" <freebsd-dtrace@freebsd.org> Subject: Re: failed to resolve cwd: Unknown variable name Message-ID: <CAMw1wOw4dkUeOrrdbHqmO-A_qB09dMaCr_aDTJSfSvZ8Ku3EUg@mail.gmail.com> In-Reply-To: <538EAAF1.1030005@ut.mephi.ru> References: <5388A227.7050805@ut.mephi.ru> <CAMw1wOwMU--0tDEjnK%2BcWW00d=d%2B%2B8BVmSCQ7XbR85bMQ0fhWw@mail.gmail.com> <538EAAF1.1030005@ut.mephi.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 4, 2014 at 1:13 AM, Dmitry Yu Okunev <dyokunev@ut.mephi.ru> wrote: > Hello. > > On 06/04/2014 06:28 AM, Mark Johnston wrote: >> On Fri, May 30, 2014 at 11:22 AM, Dmitry Yu Okunev <dyokunev@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? It's a safety thing. DTrace probes execute with interrupts disabled, so they're fairly limited in what they're allowed to do. Name resolution potentially requires the underlying filesystem code to read from disk or invoke an RPC, which cannot be done in probe context. Hence my suggestion of a cache-only lookup function that could be callable from within a probe. -Mark > >>, 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 :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMw1wOw4dkUeOrrdbHqmO-A_qB09dMaCr_aDTJSfSvZ8Ku3EUg>