svn commit: r276008 - in head/sys: kern sys

[Rui Paulo]

On Dec 22, 2014, at 23:03, Andriy Gapon <avg at FreeBSD.org> wrote:
> 
> On 23/12/2014 04:39, Rui Paulo wrote:
>> On Dec 22, 2014, at 11:17, John Baldwin <jhb at freebsd.org> wrote:
>>> 
>>> On Monday, December 22, 2014 1:29:38 pm Rui Paulo wrote:
>>>> On Dec 22, 2014, at 06:40, John Baldwin <jhb at freebsd.org> 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. 

--
Rui Paulo