From owner-freebsd-current@FreeBSD.ORG Fri Nov 14 14:28:52 2003 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 0E64116A4CF for ; Fri, 14 Nov 2003 14:28:52 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B04D143FE0 for ; Fri, 14 Nov 2003 14:28:49 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9p2/8.12.9) with ESMTP id hAEMQsMg024822; Fri, 14 Nov 2003 17:26:54 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)hAEMQs2h024819; Fri, 14 Nov 2003 17:26:54 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 14 Nov 2003 17:26:53 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Munish Chopra , kirk@mckusick.com In-Reply-To: <20031114221636.GA658@opiate.soulwax.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: HEADS-UP new statfs structure 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: Fri, 14 Nov 2003 22:28:52 -0000 On Fri, 14 Nov 2003, Munish Chopra wrote: > On 2003-11-14 21:50 +0000, Matt Smith wrote: > > > > The only thing I've found a problem with so far is postfix as I've > > mentioned. > > While attempting a portupgrade of postfix, I realized ruby core dumps > after the statfs stuff too (even after I rebuilt it). I'm a bit puzzled, > anyone else seeing this or is it a pilot error? What's going on is the following: while we have a compatibility system call in place, it only affects applications linked against non-current libc. As soon as you recompile libc, applications expecting the old statfs() ABI get the new statfs(), and depending on where their smaller struct statfs is located, may stomp on memory they're using for something else (like critical data structures). This means that any application using statfs() and linked against libc.so.5 may start having problems. Not only that, but as you begin to compile new programs, they start expecting the new statfs() API, so if you keep the old libc, they'll start expecting to see extended struct statfs information in a structure that's too small. This is almost certainly a less harmful failure mode than the former. However, it turns out statfs() is used in a fair number of applications (and libraries)... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories