Date: Fri, 14 Nov 2014 09:54:18 +0000 From: Mike Gelfand <Mike.Gelfand@LogicNow.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: "hackers@freebsd.org" <hackers@freebsd.org> Subject: Re: [BUG] Getting path to program binary sometimes fails Message-ID: <B655709E-0D6F-4DE1-A746-9A20B897BEA8@logicnow.com> In-Reply-To: <20141113170758.GY17068@kib.kiev.ua> References: <91809230-5E81-4A6E-BFD6-BE8815A06BB2@logicnow.com> <20141113170758.GY17068@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 13, 2014, at 8:07 PM, Konstantin Belousov <kostikbel@gmail.com> wrot=
e:
> 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 =93Unless explicitly noted below, sy=
sctl() returns a consistent snapshot of the data requested=94 (surely we do=
n=92t expect half the path being returned; I=92m just trying to read thorou=
ghly). Later on there are no special notes on {CTL_KERN, KERN_PROC, KERN_PR=
OC_PATHNAME}; at least no notes on the unstable behavior being observed, an=
d no funny details of internal implementation you describe. ERRORS section =
only describes ENOENT condition as =93The name array specifies a value that=
is unknown,=94 which certainly is not the case here.
Since you=92re saying that current behavior is not a defect, maybe document=
ation is wrong (incomplete, misleading) then? I will readily accept the =93=
not a defect=94 explanation, but only if one wouldn=92t have to ask you eve=
ry time this oddity is met. If this is the expected error condition, what s=
hould I do to get the path reliably? Should I retry (and how many times)? Y=
ou=92re 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=92ll be able =
to get the path on next call? Could you guarantee that I=92ll be able to ge=
t the path at all if I fail two or more times? Should I rely on ENOENT spec=
ifically when retrying?
It would also be nice if you could tell whether anything had possibly chang=
ed between 8 and 9 releases that could lead to this behavior. As I said bef=
ore, same code works on FreeBSD 8 with no errors for more than two years. M=
oreover, I didn=92t previously mention that but 8 and 9 systems which I=92m=
currently testing on are installed on completely identical hardware.
> 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?B655709E-0D6F-4DE1-A746-9A20B897BEA8>