From owner-svn-src-all@freebsd.org Thu Jun 28 02:35:48 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 59601102C544 for ; Thu, 28 Jun 2018 02:35:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1BC18222F for ; Thu, 28 Jun 2018 02:35:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x229.google.com with SMTP id u4-v6so10491651itg.0 for ; Wed, 27 Jun 2018 19:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7mMrt93/aYSbKB3L36FmBe6oN1Qj4u03PnbmiS3yG1I=; b=Kw8oDQoK9AjjPjA9Pi7NUcrhGGWtw8vMZw9JYVLShhV0bUdTKgKjT68JkdGxSJ3v+B 8RVRHSX+M9ufr16fz/H13VvPHnHHDwH//ZweeL/o1x9G3o0bVhIUVHhgrvtzFrss7GZL cO03T32CXnPI0tPbKDdJEUujlR5ZzsLFLdNPa6NanoVAgUMmomWy4xftgIz2m/MFe7cd 3+GgxWAKe6MzY94dq2Rqy+c4SbMwlwils8w/v0CxQ+C4wKVaUE2Ss3d16l7+iukxs+xF 94FmVElTSHtHE4bIuzVpsbmaEuagzQf7uo05ntqDWmlSfe/RfA8oOEXNUDMsjos70Onx vKFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7mMrt93/aYSbKB3L36FmBe6oN1Qj4u03PnbmiS3yG1I=; b=nDqEqItYdXBugXE8OPYX219C/egvHUn9xBK7jKDVtHVM9d0b6+ACCaDvrm0sXTg1lW B8NjEV5t5XmkItoT0etk7n9tmONmjZXO9aLJOt6kWt1OG5ARYGLM9u2V+WkNhXO9cYOH GS7IAmI9CQJWOXN68Rw7F6zSVsOixb1fz4LC8NstRGVpk8btfPzNbo+LtXwvsq+twxWj DMSGsf15gbuXP/BwgdL59GOedTJ9vdDNFACP1KF7ycqecV8/congUYSLqFmY4NaMnxGK Kujiz6QhuL14KkrIR9QVoNTSA+Ljwj5L6EqHp55Il6pL2N+dWFVcMqKkcS3twzxBMohY BuPQ== X-Gm-Message-State: APt69E1KYiIrgEw5YD3RSCQx+deH0bfW4SCfrLqpwRBilZfMjuVbZUEr Hj6L8Eo2qHLIbQTLFBdJLXFFh28HAgy7eK+SV1em7Q== X-Google-Smtp-Source: ADUXVKKiI3GOGmKcDH+5mNaZzmyjD+VLtI/Mz9YUTGRsDZmDOaJulDFiceFvQE5bRI4FeTNKMMpSBhLjObNwlrwXFww= X-Received: by 2002:a24:7c8d:: with SMTP id a135-v6mr6954526itd.73.1530153347036; Wed, 27 Jun 2018 19:35:47 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:5945:0:0:0:0:0 with HTTP; Wed, 27 Jun 2018 19:35:46 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <623F6077-0A89-4D35-9E83-76BF40CC290F@FreeBSD.org> References: <201806270411.w5R4B9ZB078994@repo.freebsd.org> <20180627235216.GO1165@FreeBSD.org> <16B9F36D-E92A-4FEC-B096-5E24A4E180FC@FreeBSD.org> <623F6077-0A89-4D35-9E83-76BF40CC290F@FreeBSD.org> From: Warner Losh Date: Wed, 27 Jun 2018 20:35:46 -0600 X-Google-Sender-Auth: hEqdopGbDVbn_WzCMbzF2XUHBBE Message-ID: Subject: Re: svn commit: r335690 - head/sys/kern To: Devin Teske Cc: Gleb Smirnoff , Warner Losh , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" 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:35:48 -0000 On Wed, Jun 27, 2018 at 8:14 PM, Devin Teske wrote: > > On Jun 27, 2018, at 6:58 PM, Warner Losh wrote: > > > > On Wed, Jun 27, 2018 at 7:49 PM, Devin Teske wrote: > >> >> On Jun 27, 2018, at 5:59 PM, Warner Losh wrote: >> >> >> >> 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> >>> 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