From owner-freebsd-current@FreeBSD.ORG Tue Sep 28 15:37:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9F2F16A4CE for ; Tue, 28 Sep 2004 15:37:28 +0000 (GMT) Received: from mail.freebsd.org.cn (dns3.freebsd.org.cn [61.129.66.75]) by mx1.FreeBSD.org (Postfix) with SMTP id DF20043D4C for ; Tue, 28 Sep 2004 15:37:25 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: (qmail 18978 invoked by uid 0); 28 Sep 2004 15:33:19 -0000 Received: from unknown (HELO beastie.frontfree.net) (219.239.98.7) by mail.freebsd.org.cn with SMTP; 28 Sep 2004 15:33:19 -0000 Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 99920132562; Tue, 28 Sep 2004 23:35:44 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03160-07; Tue, 28 Sep 2004 23:35:38 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 6BDED13255F; Tue, 28 Sep 2004 23:35:37 +0800 (CST) Date: Tue, 28 Sep 2004 23:35:37 +0800 From: Xin LI To: Matthias Andree Message-ID: <20040928153537.GA3185@frontfree.net> References: <20040927224353.845381B217@merlin.emma.line.org> <20040928043351.GA2400@frontfree.net> <20040928071758.GB14942@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.3-delphij FreeBSD 5.3-delphij #4: Mon Sep 13 12:44:05 CST 2004 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: by amavisd-new at frontfree.net cc: Ruslan Ermilov cc: Matthias Andree cc: current@FreeBSD.org Subject: Re: bin/72138: libc.so.5 isn't installed in a safe way X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 15:37:29 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 28, 2004 at 10:38:23AM +0200, Matthias Andree wrote: > I must say that although Xin's patch will certainly work well to address > my original PR, I like Ruslan's idea better, because it appears to work Yes, I like it too :-) Ruslan's patch is apparantly better because it also protected other shared libraries. > for all precious libraries, not just libc. But there is more "precious" > stuff, /bin, /sbin, /boot (including kernel), /rescue (I was glad I had > the latter, otherwise my system would have been dead.) > > Using -S for the whole system might be a bit slow without softupdates > (or async, which I do not favor) but would not be a bad idea from a > robustness point of view which I personally prefer. I think it the slowdown would not be too much for this issue. For a filesystem without SoftUpdates enabled, the operations are: - Increase the inode reference count in preparation of referencing it - Add a new entity for the 'canonical' name and reference the inode - Remove the old entry for the 'temporary' name - Decrease the reference count back=20 Of course, with synchnously mounted file system, you will initialize four disk writes, however, the majority of metadata update, say, the file block descriptions (i.e. storage bitmaps, etc) were already written on disk, so this (theorically) won't be a big impact. My only concern of having -S for the whole installation is that when we terminate it (accidentially or intentionally), we may left some file like install.Xb5Q7c or something like it, which is not so easy to cleanup until the next time we have a ``make installworld''. What's more, I think it is easy for any user to use ``make "INSTALL=3Dinstall -CS" installworld'' if they really need the functionality. Without having -S for the whole installation gives more flexiblity, while having -S for shared libraries would protect users from having their system in a horrible state (after all, having a bad rtld-elf.so or libc.so is not something interest :-) So I personally prefer we have -S for the shared libraries (as Ruslan's patch did) - and give our user community the choose of whether to have INSTALL=3Dinstall -S in their make.conf. What do you think about this? Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBWYTJ/cVsHxFZiIoRApd/AKCJMEC9RCvvu9eIlqcP9rsEiO20kwCfWTyj UFt78PKzht8raTKRvCEUOQ4= =/5bL -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0--