From owner-svn-src-all@FreeBSD.ORG Tue Dec 23 08:19:28 2014 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F35188CE; Tue, 23 Dec 2014 08:19:27 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7E21564861; Tue, 23 Dec 2014 08:19:25 +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 KAA03518; Tue, 23 Dec 2014 10:21:18 +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 1Y3Kge-00028G-22; Tue, 23 Dec 2014 10:19:24 +0200 Message-ID: <54992563.8000702@FreeBSD.org> Date: Tue, 23 Dec 2014 10:18:43 +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 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> <549913D4.5090103@FreeBSD.org> <8F0C318C-9312-479E-BF1C-57E3654D6105@me.com> In-Reply-To: <8F0C318C-9312-479E-BF1C-57E3654D6105@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, John Baldwin 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 08:19:28 -0000 On 23/12/2014 09:55, Rui Paulo wrote: > On Dec 22, 2014, at 23:03, Andriy Gapon wrote: >> >> 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. > > Using the default setting for core files, it's based on the CWD of the process. If you're using a different kern.corefile setting, it's different. You will also need to account for the %N format string (check the code for indexpos). Given that this is far from being a hot path, it's much easier to just do a vn_fullpath() on the vnode than to deal with all the other details. Hmm, I mean that given this code: flags = O_CREAT | FWRITE | O_NOFOLLOW; NDINIT(&nd, LOOKUP, NOFOLLOW, UIO_SYSSPACE, name, td); error = vn_open_cred(&nd, &flags, cmode, oflags, td->td_ucred, NULL); 'name' is the name, right? Can we keep and use it? -- Andriy Gapon