Re: Fixing $ORGIN RPATHs - at least some of them

[christos%zoulas.com@localhost (Christos Zoulas)]

On Nov 6, 10:37am, martin%duskware.de@localhost (Martin Husemann) wrote:
-- Subject: Re: Fixing $ORGIN RPATHs - at least some of them

| I don't fully understand this point. We do not try vnode_to_path() for
| the name currently (AFAICT).

https://nxr.netbsd.org/xref/src/sys/kern/vfs_getcwd.c#410

It is exactly the same code in vnode_to_path(). In this case lvp is p->p_textvp,
i.e. it is not a directory so it will not fail and call getwd_scandir() if
it is not in the cache.

| The point is that the kernel currently does a good job when it is easy
| and nothing at all when not. That is fine, most of the time the additional
| work will not be needed ever.
| 
| But now if userland *knows* it will need the additional data, it can
| ask the kernel to try harder (and I don't care if that is via sysctl or
| procfs).

There is no try harder, which is what I am trying to explain. All 3 methods
are doing exactly the same thing. This is the problem we have; the only way
to get back from a vnode to a path is by using the reverse namei cache.

| Looking at the procfs code it seems that it would fail whenever a __getcwd(2)
| would fail - and in the context of $ORIGIN I find this an acceptable 
| restriction (after removing the obvious and simple limits like lengths and
| nullfs).

No, that's getcwd_common() and it is what vnode_to_path() uses *if*
it can determine the parent directory vnode of the text vnode from
the reverse lookup. The vnode_to_path() is just a wrapper around it.

christos