Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 12 Oct 2024 13:32:23 -0400
From:      "David E. Cross" <david@crossfamilyweb.com>
To:        Mark Johnston <markj@freebsd.org>
Cc:        Cy Schubert <Cy.Schubert@cschubert.com>, Enji Cooper <yaneurabeya@gmail.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org>
Subject:   Re: Review D38047 ... and then there was one....
Message-ID:  <da103db1-b5a3-e9d3-b6fd-c09acbf53644@crossfamilyweb.com>
In-Reply-To: <ZwqZ8C5Zwizh1rLF@nuc>
References:  <20241007150830.939DC334@slippy.cwsent.com> <AE37187C-79D0-4B5E-87F0-6BB52822F03B@gmail.com> <20241011153526.431EA110@slippy.cwsent.com> <2b399f81-ccca-0eb5-3175-5b59e4253b7b@crossfamilyweb.com> <ZwqZ8C5Zwizh1rLF@nuc>

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

On 10/12/24 11:46, Mark Johnston wrote:
>
> Even if the whole patch is applied atomically, it affects multiple
> binaries in the system (at least libc.so and nscd), and there's nothing
> guaranteeing that the update is somehow applied atomically across the
> whole system.  What if some applications using an older libc end up
> still running with an updated nscd?  That's an untested configuration,
> but it might still arise if the whole patch is committed as one unit.


Oops, I forgot to address that point.  Yes.  But I am not sure how to 
"fix" that.  But OLD libc with NEW nscd won't be an issue; nscd only 
responds to what it is given, and this won't be changing any returns of 
existing types.  NEW libc with OLD nscd could be catastrophic however, 
even with agent code disabled, since new libc will try to store 
getgroupmembership() (via lt_pivot and the marshalling and unmarshalling 
functions) into nscd which just will not understand.  I haven't even 
attempted to test this to even know what will go boom.

Put nscd in with the new handling and then wait an entire release 
cycle?  That seems excessive, and even then won't guarantee anything,

someone can go right from 14.0 to 14.2 or 14.0 to 15.0, etc. Given the 
(not) bug reported earlier with pipe limits I don't think it is an 
unreasonable stand to say that libc goes with the world, you cannot just 
upgrade libc and not /bin and /usr/bin and expect that to work in all 
cases.  Certainly the documented process is for 
buildworld/buildkernel/installkernel/installworld.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?da103db1-b5a3-e9d3-b6fd-c09acbf53644>