Date: Wed, 27 Jun 2018 20:35:46 -0600 From: Warner Losh <imp@bsdimp.com> To: Devin Teske <dteske@freebsd.org> Cc: Gleb Smirnoff <glebius@freebsd.org>, Warner Losh <imp@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r335690 - head/sys/kern Message-ID: <CANCZdfonitWdaAXXoQnPZtMd_ytumGdWr=WYfX5CHYMytsXuOA@mail.gmail.com> In-Reply-To: <623F6077-0A89-4D35-9E83-76BF40CC290F@FreeBSD.org> References: <201806270411.w5R4B9ZB078994@repo.freebsd.org> <20180627235216.GO1165@FreeBSD.org> <CANCZdfpdBOin=w0qEGXM%2BciTAbETezYTOPq1nuEV1pT5QATEHA@mail.gmail.com> <16B9F36D-E92A-4FEC-B096-5E24A4E180FC@FreeBSD.org> <CANCZdfpJzFn0tj-PGY8Zp%2BMT7AZrYxTR5DEjHsFeDFfiDCnxGw@mail.gmail.com> <623F6077-0A89-4D35-9E83-76BF40CC290F@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 27, 2018 at 8:14 PM, Devin Teske <dteske@freebsd.org> wrote: > > On Jun 27, 2018, at 6:58 PM, Warner Losh <imp@bsdimp.com> wrote: > > > > On Wed, Jun 27, 2018 at 7:49 PM, Devin Teske <dteske@freebsd.org> wrote: > >> >> On Jun 27, 2018, at 5:59 PM, Warner Losh <imp@bsdimp.com> wrote: >> >> >> >> On Wed, Jun 27, 2018 at 5:52 PM, Gleb Smirnoff <glebius@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 >>> 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. >> > > IMHO, there's no benefit from the crazy hoops than the super simple > heuristic I did: if the path starts with / print it. If the path doesn't > print cwd / and then the path. > > I look forward to seeing your conversion of the D to C that works, even > when there's namespace cache pressure. > > > I was looking at the output of "dwatch -dX vop_create" (the -d flag to > dwatch causes the generated dwatch to be printed instead of executed) and > thinking to myself: > > I could easily convert this, as I can recognize the flattened loop > structure. However, not many people will be able to do it. I wasn't really > volunteering, but now I'm curious what other people see when they run > "dwatch -dX vop_create". If it's half as bad as I think it is, then I'll > gladly do it -- but will have to balance it against work priorities. > We don't have the data you do in vop_create anymore, just the vp at the point in the code where we want to do the reverse translation... But we also have a name that's been filled in from the template and cwd, which gives us almost the same thing as we'd hoped to dig out of the name cache... Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfonitWdaAXXoQnPZtMd_ytumGdWr=WYfX5CHYMytsXuOA>