From nobody Sat Oct 12 17:32:23 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XQrD357s9z5YjsL for ; Sat, 12 Oct 2024 17:32:35 +0000 (UTC) (envelope-from david@crossfamilyweb.com) Received: from mail.dcrosstech.com (syn-024-097-005-251.biz.spectrum.com [24.97.5.251]) (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 "mail.dcrosstech.com", Issuer "DCrossTech.com LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XQrD34NyFz470K; Sat, 12 Oct 2024 17:32:35 +0000 (UTC) (envelope-from david@crossfamilyweb.com) Authentication-Results: mx1.freebsd.org; none X-Virus-Scanned: amavisd-new at dcrosstech.com Received: from [10.1.12.130] (d130.office.dcrosstech.com [10.1.12.130]) (authenticated bits=0) by mail.dcrosstech.com (8.15.2/8.15.2) with ESMTPSA id 49CHWNhn044131 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sat, 12 Oct 2024 17:32:23 GMT (envelope-from david@crossfamilyweb.com) X-Authentication-Warning: mail.priv.dcrosstech.com: Host d130.office.dcrosstech.com [10.1.12.130] claimed to be [10.1.12.130] Message-ID: Date: Sat, 12 Oct 2024 13:32:23 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: Review D38047 ... and then there was one.... Content-Language: en-US To: Mark Johnston Cc: Cy Schubert , Enji Cooper , FreeBSD Hackers References: <20241007150830.939DC334@slippy.cwsent.com> <20241011153526.431EA110@slippy.cwsent.com> <2b399f81-ccca-0eb5-3175-5b59e4253b7b@crossfamilyweb.com> From: "David E. Cross" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11351, ipnet:24.97.0.0/16, country:US] X-Rspamd-Queue-Id: 4XQrD34NyFz470K X-Spamd-Bar: ---- 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.