From owner-svn-src-all@freebsd.org Sun Nov 15 19:30:55 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 4B28A4663EE; Sun, 15 Nov 2020 19:30:55 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4CZ2PC1LBRz3LPP; Sun, 15 Nov 2020 19:30:55 +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 1A58D2A1A5; Sun, 15 Nov 2020 19:30:55 +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 C08C627C0054; Sun, 15 Nov 2020 14:30:54 -0500 (EST) Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Sun, 15 Nov 2020 14:30:54 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddvledguddvkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enfghrlhcuvffnffculddutddmnecujfgurhepofgfggfkjghffffhvffutgfgsehtqher tderreejnecuhfhrohhmpedfuehrrghnughonhcuuegvrhhgrhgvnhdfuceosggurhgrgh honheshfhrvggvuefuffdrohhrgheqnecuggftrfgrthhtvghrnhepieefgeeuveduffej teetjeejkeeftdetgffgieefgfetueegueekgeeutdduteejnecuffhomhgrihhnpehfrh gvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhepsggurhgrghhonhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthi dquddtgedvfeehkeeigedqudekuddtkeehuddqsggurhgrghhonheppefhrhgvvgeuufff rdhorhhgsehimhgrphdrtggt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 689E6C200A6; Sun, 15 Nov 2020 14:30:54 -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: In-Reply-To: <44B80F15-2BE7-4B7C-BC3D-B65511480E58@freebsd.org> 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:30:34 -0600 From: "Brandon Bergren" To: "Jessica Clarke" Cc: "Scott Long" , "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:30:55 -0000 I think the problem is that user.* is somehow magically namespaced, so d= oing a "dumb" sysctlbyname will get the wrong one. sysctl (the tool) does: __sysctl("sysctl.name2oid user.localbase",2,0xfffffbfffde98,0xfffffbfffd= a98,0x810809000,14) =3D 0 (0x0) __sysctl("sysctl.oidfmt user.localbase",4,0xfffffbfffdef8,0xfffffbfffd69= 0,0x0,0) =3D 0 (0x0) __sysctl("sysctl.name { 8.21 }",4,0xfffffbfffc8f8,0xfffffbfffc480,0x0,0)= =3D 0 (0x0) __sysctl("sysctl.oidfmt user.localbase",4,0xfffffbfffd0f8,0xfffffbfffc48= 8,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 (0x= 0) and picks up /usr/local. whereas libutil is currently just doing __sysctlbyname("user.localbase",14,0xfffffbfffd4f8,0xfffffbfffd440,0x0,0= ) =3D 0 (0x0) which is returning the builtin "" from the static kernel variable. On Sun, Nov 15, 2020, at 1:26 PM, Jessica Clarke wrote: > On 15 Nov 2020, at 19:10, Brandon Bergren wrote:= > >=20 > > On powerpc64 and powerpc64le, there is some really weird behavior ha= ppening 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 var= =3Dvalue] [-4|-6] [] > >=20 > > For more information on available commands and options see 'pkg help= '. > > root@crow:~ #=20 > >=20 > >=20 > > I would double check very closely that the sysctl is being called co= rrectly, 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() dro= ve the > >>>> result. Since the use case for getlocalbase() lends itself to al= so use > >>>> strlcat()/strlcpy(), I was trying to replicate the API semantics = of those, > >>>> at least to the limit of my understanding. Thanks for the feedba= ck, I=E2=80=99ll > >>>> look at it some more. > >>>=20 > >>> Thanks. ENOMEM also feels inappropriate as no allocation is taking= > >>> place. Perhaps ENAMETOOLONG, which is used in similar cases for th= ings > >>> like gethostbyname? Though sysctlbyname uses ENOMEM instead... sig= h. > >>>=20 > >>=20 > >> Yep, I wasn=E2=80=99t happy with ENOMEM either but I couldn=E2=80=99= t find anything better. > >>=20 > >>> Also, if pathlen has already been checked against SSIZE_MAX (givin= g > >>> EINVAL) and tmplen against pathlen there's no need to then check t= mplen > >>> against SSIZE_MAX. > >>>=20 > >>=20 > >> Done. > >>=20 > >>> I'd be happy to give a review on Phabricator if/when you have a ne= w > >>> patch. > >>>=20 > >>=20 > >> https://reviews.freebsd.org/D27227 > >>=20 > >> Thanks, > >> Scott > >>=20 > >>=20 > >=20 > > --=20 > > Brandon Bergren > > bdragon@FreeBSD.org >=20 > --=20 Brandon Bergren bdragon@FreeBSD.org