svn commit: r335690 - head/sys/kern

[Devin Teske]

> On Jun 27, 2018, at 5:59 PM, Warner Losh <imp at bsdimp.com> wrote:
> 
> 
> 
> On Wed, Jun 27, 2018 at 5:52 PM, Gleb Smirnoff <glebius at freebsd.org <mailto:glebius at freebsd.org>> wrote:
> On Wed, Jun 27, 2018 at 04:11:09AM +0000, Warner Losh wrote:
> W> Author: imp
> W> Date: Wed Jun 27 04:11:09 2018
> W> New Revision: 335690
> W> URL: https://svnweb.freebsd.org/changeset/base/335690 <https://svnweb.freebsd.org/changeset/base/335690>
> W> 
> W> Log:
> W>   Fix devctl generation for core files.
> W>   
> W>   We have a problem with vn_fullpath_global when the file exists. Work
> W>   around it by printing the full path if the core file name starts with /,
> W>   or current working directory followed by the filename if not.
> 
> Is this going to work when a core is dumped not at current working directory,
> but at absolute path? e.g. kern.corefile=/var/log/cores/%N.core
> 
> Yes. That works.
>  
> Looks like the vn_fullpath_global needs to be fixed rather than problem
> workarounded.
> 
> It can't be fixed reliably. FreeBSD does not and cannot map a vnode to a name. The only reason we're able to at all is due to the name cache. And when we recreate a file, we invalidate the name cache. And even if we fixed that, there's no guarantee the name cache won't get flushed before we translate the name.... Linux can do this because it keeps the path name associated with the inode. FreeBSD simply doesn't.
> 

They said it couldn't be done, but I personally have done it ...

I map vnodes to full paths in dwatch. It's not impossible, just implausibly hard.

I derived my formula by reading the C code which was very twisty-turny and rather hard to read at times (and I have been using C since 1998 on everything from AIX and OSF/1 to HP/UX, Cygwin, MinGW, FreeBSD, countless Linux-like things, IRIX, and a God-awful remainder of many others; the vnode code was an adventure to say the least).

You're welcome to see how it's done in /usr/libexec/dwatch/vop_create

I load up a clause-local variable named "path" with a path constructed from a pointer to a vnode structure argument to VOP_CREATE(9).

The D code could easily be rewritten back into C to walk the vnode to completion (compared to the D code which is bounded by depth-limit since DTrace doesn't provide loops; so you have to, as I have done, use a higher-level language wrapper to repeat the code to some desired limit; dwatch defaulting to 64 for directory depth limit).

Compared this, say, to vfssnoop.d from Chapter 5 of the DTrace book which utilizes the vfs:namei:lookup: probes. My approach in dwatch is far more accurate, produces full paths, and I've benchmarked it at lower overhead with better results.

Maybe some of this can be useful? If not, just ignore me.
-- 
Devin