From owner-freebsd-dtrace@FreeBSD.ORG Wed Jun 4 13:25:13 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36055194; Wed, 4 Jun 2014 13:25:13 +0000 (UTC) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D640D2276; Wed, 4 Jun 2014 13:25:12 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id ij19so4045434vcb.16 for ; Wed, 04 Jun 2014 06:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=U/+pKcE2TDbDuMf9pO/J0J5c/Dye7jvuYCgJ9tDtVa0=; b=Lr1YsOvhtWCEJRprfXKP6thQtBs5po3fNrr1QmqQZwhSptVN6uaxXK6q+NgCGjpqqi g2+Fk2ChBk5nMRYNiYVwpcUxjgDGXAiD7ZVVNaKulQ+/l7NKgVGOxM0JyoTpxnWIkFt3 tPi5o32FTVxjTjL+oLu9B5Ct5bImh96UNc4Z39iHHfrZv3ipb0wGRHaBw1+kCcwqEJVc D6EiGe1Gtonjd7UAYe7oCxhmuT6QUk+r+dIidgjCZsmhxLBm33vlZcEjzzXY01BqLTfP 65hkZHb4tA/33AgHIFO5kUJYIISqiUkbf5ym6mKO0bfB/qH/qDye6Q6wHuvWLu3zAdUf 8rDA== MIME-Version: 1.0 X-Received: by 10.52.138.232 with SMTP id qt8mr12674265vdb.44.1401888311728; Wed, 04 Jun 2014 06:25:11 -0700 (PDT) Sender: markjdb@gmail.com Received: by 10.220.162.68 with HTTP; Wed, 4 Jun 2014 06:25:11 -0700 (PDT) In-Reply-To: <538EAAF1.1030005@ut.mephi.ru> References: <5388A227.7050805@ut.mephi.ru> <538EAAF1.1030005@ut.mephi.ru> Date: Wed, 4 Jun 2014 09:25:11 -0400 X-Google-Sender-Auth: sx-OqOYvCCD-deJWjPTb1QU4gic Message-ID: Subject: Re: failed to resolve cwd: Unknown variable name From: Mark Johnston To: Dmitry Yu Okunev Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "A discussion list for developers working on DTrace in FreeBSD." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 13:25:13 -0000 On Wed, Jun 4, 2014 at 1:13 AM, Dmitry Yu Okunev wrote: > Hello. > > On 06/04/2014 06:28 AM, Mark Johnston wrote: >> On Fri, May 30, 2014 at 11:22 AM, Dmitry Yu Okunev 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 :)