From owner-svn-src-all@FreeBSD.ORG Tue Dec 23 07:04:51 2014 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79FBD2BC; Tue, 23 Dec 2014 07:04:51 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 21905168A; Tue, 23 Dec 2014 07:04:49 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA02652; Tue, 23 Dec 2014 09:06:35 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Y3JWL-000232-8J; Tue, 23 Dec 2014 09:04:41 +0200 Message-ID: <549913D4.5090103@FreeBSD.org> Date: Tue, 23 Dec 2014 09:03:48 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Rui Paulo , John Baldwin Subject: Re: svn commit: r276008 - in head/sys: kern sys References: <201412211332.sBLDW8VC030548@svn.freebsd.org> <201412220940.02509.jhb@freebsd.org> <08A2ABA0-C982-46BC-B309-3C23B8D277B9@me.com> <201412221417.42894.jhb@freebsd.org> <2C4635EF-6BE6-4ED7-B9D1-237F76259E88@me.com> In-Reply-To: <2C4635EF-6BE6-4ED7-B9D1-237F76259E88@me.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 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: Tue, 23 Dec 2014 07:04:51 -0000 On 23/12/2014 04:39, Rui Paulo wrote: > On Dec 22, 2014, at 11:17, John Baldwin wrote: >> >> On Monday, December 22, 2014 1:29:38 pm Rui Paulo wrote: >>> On Dec 22, 2014, at 06:40, John Baldwin wrote: >>>> Is there something specific to core dumps that makes vn_fullpath() more >>>> useful to have working before a process tries to open the core? (As >>>> compared to other newly-created files) >>> >>> Yes: the ability to provide the full path to userland when a core dump file >> is generated. >> >> Can you be more specific? Are we printing the path on the console after >> destroying the generated path? Is it being written into a note in the core >> itself (but only having the vnode of the core file available and not the >> generated path)? > > No. I have some code that calls devctl_notify() when a core dump is generated which is useful for running an automated debugging session. We use this at work and I'll see if I can upstream it. What Konstantin fixed was the generation of the cache entry in the corefile_open() routine. This lets me call vn_fullpath() after vn_close() with a high probability that it will work whereas, in the past, it was never in the cache, so vn_fullpath() would always fail. What is not entirely clear to me is why we need to recover the path from the vnode if we, obviously, have the path even before we have the vnode. -- Andriy Gapon