From owner-svn-src-all@FreeBSD.ORG Tue Dec 23 09:46:26 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 889AE149; Tue, 23 Dec 2014 09:46:26 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 2B8C21DB9; Tue, 23 Dec 2014 09:46:25 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sBN9kKfK025494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Dec 2014 11:46:20 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sBN9kKfK025494 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sBN9kJsv025492; Tue, 23 Dec 2014 11:46:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 23 Dec 2014 11:46:19 +0200 From: Konstantin Belousov To: Andriy Gapon Subject: Re: svn commit: r276008 - in head/sys: kern sys Message-ID: <20141223094619.GA2148@kib.kiev.ua> 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> <54992563.8000702@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54992563.8000702@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, John Baldwin , Rui Paulo 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 09:46:26 -0000 On Tue, Dec 23, 2014 at 10:18:43AM +0200, Andriy Gapon wrote: > 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? No, not right. It is the name used for resolution using namei(), while the path obtained from vn_fullpath() is passed to usermode. For 'name' to be useful, it must be used in exactly the same lookup environment, i.e. cwd/root dir at al should be the same.