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 <a...@freebsd.org> wrote:
> >>
> >> On 23/12/2014 04:39, Rui Paulo wrote:
> >>> On Dec 22, 2014, at 11:17, John Baldwin <j...@freebsd.org> wrote:
> >>>>
> >>>> On Monday, December 22, 2014 1:29:38 pm Rui Paulo wrote:
> >>>>> On Dec 22, 2014, at 06:40, John Baldwin <j...@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.
>
>
> 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.
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
