svn commit: r367701 - head/lib/libutil

[Brandon Bergren]

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 
> kernel.  Please make sure that you’ve installed a more recent libc, I 
> guess?  I just did a full build and install, and I’m unable to 
> replicate the problem.  Maybe there’s a static-linked pkg running 
> around somewhere?  I’m at a loss for better ideas.
> 
> Scott
> 
> 
> > On Nov 15, 2020, at 12:30 PM, Brandon Bergren <bdragon at FreeBSD.org> wrote:
> > 
> > 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 at FreeBSD.org> wrote:
> >>> 
> >>> On powerpc64 and powerpc64le, there is some really weird behavior happening around the sysctl itself:
> >>> 
> >>> root at 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 at crow:~ # sysctl user.localbase
> >>> user.localbase: /usr/local
> >>> root at 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 at crow:~ # sysctl user.localbase=/usr/local
> >>> user.localbase: /usr/local -> /usr/local
> >>> root at 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 at 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 at 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 at FreeBSD.org
> >> 
> >> 
> > 
> > -- 
> >  Brandon Bergren
> >  bdragon at FreeBSD.org
> 
>

-- 
  Brandon Bergren
  bdragon at FreeBSD.org