Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 15 Nov 2020 13:30:34 -0600
From:      "Brandon Bergren" <bdragon@FreeBSD.org>
To:        "Jessica Clarke" <jrtc27@freebsd.org>
Cc:        "Scott Long" <scottl@samsco.org>, "Scott Long" <scottl@FreeBSD.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org>
Subject:   Re: svn commit: r367701 - head/lib/libutil
Message-ID:  <a54c3d86-8499-4c2b-a83f-9db79a12e3ec@www.fastmail.com>
In-Reply-To: <44B80F15-2BE7-4B7C-BC3D-B65511480E58@freebsd.org>
References:  <202011150748.0AF7mqW3016900@repo.freebsd.org> <D5492BB4-A282-4E35-B02F-1216769FDA51@freebsd.org> <A39C12CC-D3D6-4166-9089-7466FA1C2B2D@samsco.org> <329C4753-BB97-4C67-8CDA-39EB67E16CE8@freebsd.org> <EBD050A5-70AE-43E8-A9E1-CCD3BCA11180@samsco.org> <f9904238-3923-40c1-b478-c5249821ed09@www.fastmail.com> <44B80F15-2BE7-4B7C-BC3D-B65511480E58@freebsd.org>

index | next in thread | previous in thread | raw e-mail

I think the problem is that user.* is somehow magically namespaced, so doing a "dumb" sysctlbyname will get the wrong one.

sysctl (the tool) does:
__sysctl("sysctl.name2oid user.localbase",2,0xfffffbfffde98,0xfffffbfffda98,0x810809000,14) = 0 (0x0)
__sysctl("sysctl.oidfmt user.localbase",4,0xfffffbfffdef8,0xfffffbfffd690,0x0,0) = 0 (0x0)
__sysctl("sysctl.name { 8.21 }",4,0xfffffbfffc8f8,0xfffffbfffc480,0x0,0) = 0 (0x0)
__sysctl("sysctl.oidfmt user.localbase",4,0xfffffbfffd0f8,0xfffffbfffc488,0x0,0) = 0 (0x0)
__sysctl("user.localbase",2,0x0,0xfffffbfffc480,0x0,0) = 0 (0x0)
__sysctl("user.localbase",2,0x81080a000,0xfffffbfffd0f8,0x0,0) = 0 (0x0)

and picks up /usr/local.

whereas libutil is currently just doing
__sysctlbyname("user.localbase",14,0xfffffbfffd4f8,0xfffffbfffd440,0x0,0) = 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 <bdragon@FreeBSD.org> wrote:
> > 
> > On powerpc64 and powerpc64le, there is some really weird behavior happening around the sysctl itself:
> > 
> > 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=/usr/local
> > user.localbase: /usr/local -> /usr/local
> > root@crow:~ # pkg
> > pkg: not enough arguments
> > Usage: pkg [-v] [-d] [-l] [-N] [-j <jail name or id>|-c <chroot path>|-r <rootdir>] [-C <configuration file>] [-R <repo config dir>] [-o var=value] [-4|-6] <command> [<args>]
> > 
> > For more information on available commands and options see 'pkg help'.
> > root@crow:~ # 
> > 
> > 
> > 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.
> 
> That's odd. What does truss say?
> 
> Jess
> 
> > On Sun, Nov 15, 2020, at 1:06 PM, Scott Long wrote:
> >> 
> >>> On Nov 15, 2020, at 12:01 PM, Jessica Clarke <jrtc27@freebsd.org> wrote:
> >>>> 
> >>>> I felt similar concerns, but my misunderstanding of strlcpy() drove the
> >>>> result.  Since the use case for getlocalbase() lends itself to also use
> >>>> strlcat()/strlcpy(), I was trying to replicate the API semantics of those,
> >>>> at least to the limit of my understanding.  Thanks for the feedback, I’ll
> >>>> look at it some more.
> >>> 
> >>> Thanks. ENOMEM also feels inappropriate as no allocation is taking
> >>> place. Perhaps ENAMETOOLONG, which is used in similar cases for things
> >>> like gethostbyname? Though sysctlbyname uses ENOMEM instead... sigh.
> >>> 
> >> 
> >> Yep, I wasn’t happy with ENOMEM either but I couldn’t find anything better.
> >> 
> >>> Also, if pathlen has already been checked against SSIZE_MAX (giving
> >>> EINVAL) and tmplen against pathlen there's no need to then check tmplen
> >>> against SSIZE_MAX.
> >>> 
> >> 
> >> Done.
> >> 
> >>> I'd be happy to give a review on Phabricator if/when you have a new
> >>> patch.
> >>> 
> >> 
> >> https://reviews.freebsd.org/D27227
> >> 
> >> Thanks,
> >> Scott
> >> 
> >> 
> > 
> > -- 
> >  Brandon Bergren
> >  bdragon@FreeBSD.org
> 
>

-- 
  Brandon Bergren
  bdragon@FreeBSD.org


help

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a54c3d86-8499-4c2b-a83f-9db79a12e3ec>