From owner-svn-src-all@freebsd.org Thu Jun 28 02:14:51 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8F06102A522; Thu, 28 Jun 2018 02:14:50 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from shxd.cx (mail.shxd.cx [64.201.244.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 796D381074; Thu, 28 Jun 2018 02:14:50 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from [64.201.244.132] (port=49179 helo=[10.0.0.104]) by shxd.cx with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1fYD89-0008Ms-Mn; Wed, 27 Jun 2018 16:17:17 +0000 From: Devin Teske Message-Id: <623F6077-0A89-4D35-9E83-76BF40CC290F@FreeBSD.org> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r335690 - head/sys/kern Date: Wed, 27 Jun 2018 19:14:47 -0700 In-Reply-To: Cc: Devin Teske , Gleb Smirnoff , Warner Losh , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org To: Warner Losh References: <201806270411.w5R4B9ZB078994@repo.freebsd.org> <20180627235216.GO1165@FreeBSD.org> <16B9F36D-E92A-4FEC-B096-5E24A4E180FC@FreeBSD.org> X-Mailer: Apple Mail (2.3273) Sender: devin@shxd.cx Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 02:14:51 -0000 > On Jun 27, 2018, at 6:58 PM, Warner Losh wrote: >=20 >=20 >=20 > On Wed, Jun 27, 2018 at 7:49 PM, Devin Teske > wrote: >=20 >> On Jun 27, 2018, at 5:59 PM, Warner Losh > wrote: >>=20 >>=20 >>=20 >> On Wed, Jun 27, 2018 at 5:52 PM, Gleb Smirnoff > 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>=20 >> W> Log: >> W> Fix devctl generation for core files. >> W> =20 >> 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. >>=20 >> Is this going to work when a core is dumped not at current working = directory, >> but at absolute path? e.g. kern.corefile=3D/var/log/cores/%N.core >>=20 >> Yes. That works. >> =20 >> Looks like the vn_fullpath_global needs to be fixed rather than = problem >> workarounded. >>=20 >> 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. >>=20 >=20 > They said it couldn't be done, but I personally have done it ... >=20 > I map vnodes to full paths in dwatch. It's not impossible, just = implausibly hard. >=20 > 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). >=20 > You're welcome to see how it's done in /usr/libexec/dwatch/vop_create >=20 > 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). >=20 > 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). >=20 > 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. >=20 > Maybe some of this can be useful? If not, just ignore me. >=20 > 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. >=20 > I look forward to seeing your conversion of the D to C that works, = even when there's namespace cache pressure. >=20 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. --=20 Devin=