From owner-svn-src-all@freebsd.org Sun Nov 15 19:36:22 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1E7A346693F; Sun, 15 Nov 2020 19:36:22 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CZ2WV06WFz3LyR; Sun, 15 Nov 2020 19:36:22 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bdragon/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id E4EBB2A428; Sun, 15 Nov 2020 19:36:21 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id BB32327C0054; Sun, 15 Nov 2020 14:36:21 -0500 (EST) Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Sun, 15 Nov 2020 14:36:21 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddvledgudefudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enfghrlhcuvffnffculddutddmnecujfgurhepofgfggfkjghffffhvffutgfgsehtqher tderreejnecuhfhrohhmpedfuehrrghnughonhcuuegvrhhgrhgvnhdfuceosggurhgrgh honheshfhrvggvuefuffdrohhrgheqnecuggftrfgrthhtvghrnhepieefgeeuveduffej teetjeejkeeftdetgffgieefgfetueegueekgeeutdduteejnecuffhomhgrihhnpehfrh gvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhepsggurhgrghhonhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthi dquddtgedvfeehkeeigedqudekuddtkeehuddqsggurhgrghhonheppefhrhgvvgeuufff rdhorhhgsehimhgrphdrtggt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 73FEBC200A5; Sun, 15 Nov 2020 14:36:21 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-570-gba0a262-fm-20201106.001-gba0a2623 Mime-Version: 1.0 Message-Id: <76667692-13ef-4522-ab23-240a1f6d57f3@www.fastmail.com> In-Reply-To: References: <202011150748.0AF7mqW3016900@repo.freebsd.org> <329C4753-BB97-4C67-8CDA-39EB67E16CE8@freebsd.org> <44B80F15-2BE7-4B7C-BC3D-B65511480E58@freebsd.org> Date: Sun, 15 Nov 2020 13:36:01 -0600 From: "Brandon Bergren" To: "Scott Long" Cc: "Jessica Clarke" , "Scott Long" , src-committers , svn-src-all , svn-src-head Subject: Re: svn commit: r367701 - head/lib/libutil Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 19:36:22 -0000 That would explain why I see what I see -- I did not install an updated = libc yet. On Sun, Nov 15, 2020, at 1:34 PM, Scott Long wrote: > It is a magical namespace, in that it comes from libc, not from the=20= > kernel. Please make sure that you=E2=80=99ve installed a more recent = libc, I=20 > guess? I just did a full build and install, and I=E2=80=99m unable to= =20 > replicate the problem. Maybe there=E2=80=99s a static-linked pkg runn= ing=20 > around somewhere? I=E2=80=99m at a loss for better ideas. >=20 > Scott >=20 >=20 > > On Nov 15, 2020, at 12:30 PM, Brandon Bergren = wrote: > >=20 > > I think the problem is that user.* is somehow magically namespaced, = so doing a "dumb" sysctlbyname will get the wrong one. > >=20 > > sysctl (the tool) does: > > __sysctl("sysctl.name2oid user.localbase",2,0xfffffbfffde98,0xfffffb= fffda98,0x810809000,14) =3D 0 (0x0) > > __sysctl("sysctl.oidfmt user.localbase",4,0xfffffbfffdef8,0xfffffbff= fd690,0x0,0) =3D 0 (0x0) > > __sysctl("sysctl.name { 8.21 }",4,0xfffffbfffc8f8,0xfffffbfffc480,0x= 0,0) =3D 0 (0x0) > > __sysctl("sysctl.oidfmt user.localbase",4,0xfffffbfffd0f8,0xfffffbff= fc488,0x0,0) =3D 0 (0x0) > > __sysctl("user.localbase",2,0x0,0xfffffbfffc480,0x0,0) =3D 0 (0x0) > > __sysctl("user.localbase",2,0x81080a000,0xfffffbfffd0f8,0x0,0) =3D 0= (0x0) > >=20 > > and picks up /usr/local. > >=20 > > whereas libutil is currently just doing > > __sysctlbyname("user.localbase",14,0xfffffbfffd4f8,0xfffffbfffd440,0= x0,0) =3D 0 (0x0) > >=20 > > which is returning the builtin "" from the static kernel variable. > >=20 > > On Sun, Nov 15, 2020, at 1:26 PM, Jessica Clarke wrote: > >> On 15 Nov 2020, at 19:10, Brandon Bergren wro= te: > >>>=20 > >>> On powerpc64 and powerpc64le, there is some really weird behavior = happening around the sysctl itself: > >>>=20 > >>> root@crow:~ # pkg > >>> The package management tool is not yet installed on your system. > >>> Do you want to fetch and install it now? [y/N]: N > >>> root@crow:~ # sysctl user.localbase > >>> user.localbase: /usr/local > >>> root@crow:~ # pkg > >>> The package management tool is not yet installed on your system. > >>> Do you want to fetch and install it now? [y/N]: N > >>> root@crow:~ # sysctl user.localbase=3D/usr/local > >>> user.localbase: /usr/local -> /usr/local > >>> root@crow:~ # pkg > >>> pkg: not enough arguments > >>> Usage: pkg [-v] [-d] [-l] [-N] [-j |-c |-r ] [-C ] [-R ] [-o v= ar=3Dvalue] [-4|-6] [] > >>>=20 > >>> For more information on available commands and options see 'pkg he= lp'. > >>> root@crow:~ #=20 > >>>=20 > >>>=20 > >>> I would double check very closely that the sysctl is being called = correctly, the sysctl tool manages to read it out, but libutil does not.= > >>=20 > >> That's odd. What does truss say? > >>=20 > >> Jess > >>=20 > >>> On Sun, Nov 15, 2020, at 1:06 PM, Scott Long wrote: > >>>>=20 > >>>>> On Nov 15, 2020, at 12:01 PM, Jessica Clarke wrote: > >>>>>>=20 > >>>>>> I felt similar concerns, but my misunderstanding of strlcpy() d= rove the > >>>>>> result. Since the use case for getlocalbase() lends itself to = also use > >>>>>> strlcat()/strlcpy(), I was trying to replicate the API semantic= s of those, > >>>>>> at least to the limit of my understanding. Thanks for the feed= back, I=E2=80=99ll > >>>>>> look at it some more. > >>>>>=20 > >>>>> Thanks. ENOMEM also feels inappropriate as no allocation is taki= ng > >>>>> place. Perhaps ENAMETOOLONG, which is used in similar cases for = things > >>>>> like gethostbyname? Though sysctlbyname uses ENOMEM instead... s= igh. > >>>>>=20 > >>>>=20 > >>>> Yep, I wasn=E2=80=99t happy with ENOMEM either but I couldn=E2=80= =99t find anything better. > >>>>=20 > >>>>> Also, if pathlen has already been checked against SSIZE_MAX (giv= ing > >>>>> EINVAL) and tmplen against pathlen there's no need to then check= tmplen > >>>>> against SSIZE_MAX. > >>>>>=20 > >>>>=20 > >>>> Done. > >>>>=20 > >>>>> I'd be happy to give a review on Phabricator if/when you have a = new > >>>>> patch. > >>>>>=20 > >>>>=20 > >>>> https://reviews.freebsd.org/D27227 > >>>>=20 > >>>> Thanks, > >>>> Scott > >>>>=20 > >>>>=20 > >>>=20 > >>> --=20 > >>> Brandon Bergren > >>> bdragon@FreeBSD.org > >>=20 > >>=20 > >=20 > > --=20 > > Brandon Bergren > > bdragon@FreeBSD.org >=20 > --=20 Brandon Bergren bdragon@FreeBSD.org