Date: Fri, 14 Nov 2014 12:23:06 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Mike Gelfand <Mike.Gelfand@LogicNow.com> Cc: "hackers@freebsd.org" <hackers@freebsd.org> Subject: Re: [BUG] Getting path to program binary sometimes fails Message-ID: <20141114102306.GE17068@kib.kiev.ua> In-Reply-To: <B655709E-0D6F-4DE1-A746-9A20B897BEA8@logicnow.com> References: <91809230-5E81-4A6E-BFD6-BE8815A06BB2@logicnow.com> <20141113170758.GY17068@kib.kiev.ua> <B655709E-0D6F-4DE1-A746-9A20B897BEA8@logicnow.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 14, 2014 at 09:54:18AM +0000, Mike Gelfand wrote:
> On Nov 13, 2014, at 8:07 PM, Konstantin Belousov <kostikbel@gmail.com> wrote:
>
> > This is not a defect. The vnode->path translation uses namecache, which
> > could be purged at any time. The behaviour is typical for most unix
> > implementations. Linux and new Solaris have 'rigid' namecache, where
> > name entry lifetime is the same as the vnode lifetime it is attached to.
> > I am not aware of any useful consequences of such design, except
> > vn_fullpath() working more reliable, but at the cost of increased
> > memory usage.
>
> The man page for sysctl(3) states that ?Unless explicitly noted
> below, sysctl() returns a consistent snapshot of the data requested?
> (surely we don?t expect half the path being returned; I?m just
> trying to read thoroughly). Later on there are no special notes on
> {CTL_KERN, KERN_PROC, KERN_PROC_PATHNAME}; at least no notes on the
> unstable behavior being observed, and no funny details of internal
> implementation you describe. ERRORS section only describes ENOENT
> condition as ?The name array specifies a value that is unknown,? which
> certainly is not the case here.
>
> Since you?re saying that current behavior is not a defect, maybe
> documentation is wrong (incomplete, misleading) then? I will readily
> accept the ?not a defect? explanation, but only if one wouldn?t have
> to ask you every time this oddity is met. If this is the expected
Provide the documentation patch.
> error condition, what should I do to get the path reliably? Should I
> retry (and how many times)? You?re saying cache is being purged; does
> it mean that when I ask for path then cache is populated again? Does
> it guarantee then that I?ll be able to get the path on next call?
> Could you guarantee that I?ll be able to get the path at all if I fail
> two or more times? Should I rely on ENOENT specifically when retrying?
After the path resolution failed, it can only succeed later if the cache
is populated again. Cache cannot be populated by the vnode->path
request, just think where to get the data ? The cache is populated
when lookup is performed, so if nothing accessed the file by name
between your two calls, second translation fails as well.
>
> It would also be nice if you could tell whether anything had possibly
> changed between 8 and 9 releases that could lead to this behavior. As
> I said before, same code works on FreeBSD 8 with no errors for more
> than two years. Moreover, I didn?t previously mention that but 8 and
> 9 systems which I?m currently testing on are installed on completely
> identical hardware.
Namecache behaves mostly the same in 8/9/10/HEAD. The failure of
vnode->path resolution due to purged cache is expected. There are in
fact some improvements, like relibably resolving pathes for directories
(not for the regular files) and for some special filesystems like devfs
or procfs. I do not remember exact point where that was added, in 8 or 9
lifetime.
>
> > Another possible reason for failed translation is the replacement of
> > the binary while it runs. There, rigid namecache does not help.
>
> Not the case here.
>
> Kind regards, Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141114102306.GE17068>