From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 14 13:30:30 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88BCBE2E for ; Fri, 14 Nov 2014 13:30:30 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0063.outbound.protection.outlook.com [157.56.110.63]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2802F6C3 for ; Fri, 14 Nov 2014 13:30:29 +0000 (UTC) Received: from DM2PR04MB477.namprd04.prod.outlook.com (10.141.105.13) by DM2PR04MB365.namprd04.prod.outlook.com (10.141.98.27) with Microsoft SMTP Server (TLS) id 15.1.16.15; Fri, 14 Nov 2014 09:54:24 +0000 Received: from DM2PR04MB477.namprd04.prod.outlook.com (10.141.105.13) by DM2PR04MB477.namprd04.prod.outlook.com (10.141.105.13) with Microsoft SMTP Server (TLS) id 15.1.16.15; Fri, 14 Nov 2014 09:54:18 +0000 Received: from DM2PR04MB477.namprd04.prod.outlook.com ([169.254.15.59]) by DM2PR04MB477.namprd04.prod.outlook.com ([169.254.15.59]) with mapi id 15.01.0016.006; Fri, 14 Nov 2014 09:54:18 +0000 From: Mike Gelfand To: Konstantin Belousov Subject: Re: [BUG] Getting path to program binary sometimes fails Thread-Topic: [BUG] Getting path to program binary sometimes fails Thread-Index: AQHP/y1OF6HbydE23kCBwyNP5wFRKZxeymWAgAEZIgA= Date: Fri, 14 Nov 2014 09:54:18 +0000 Message-ID: References: <91809230-5E81-4A6E-BFD6-BE8815A06BB2@logicnow.com> <20141113170758.GY17068@kib.kiev.ua> In-Reply-To: <20141113170758.GY17068@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.140.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR04MB477;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR04MB477; x-forefront-prvs: 03950F25EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(377454003)(189002)(71364002)(199003)(46102003)(77156002)(62966003)(66066001)(20776003)(95666004)(105586002)(64706001)(106116001)(106356001)(77096003)(21056001)(99286002)(99396003)(31966008)(107046002)(120916001)(110136001)(50986999)(76176999)(101416001)(54356999)(97736003)(33656002)(19580405001)(19580395003)(82746002)(2656002)(40100003)(92566001)(87936001)(92726001)(122556002)(86362001)(83716003)(36756003)(1411001)(4396001)(104396001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR04MB477; H:DM2PR04MB477.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <741FA9DE4BDB024B9C7030DCD2D981CF@namprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR04MB365; X-OriginatorOrg: logicnow.com X-Mailman-Approved-At: Fri, 14 Nov 2014 13:58:23 +0000 Cc: "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 13:30:30 -0000 On Nov 13, 2014, at 8:07 PM, Konstantin Belousov 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=