From owner-svn-src-head@FreeBSD.ORG Sun Apr 4 22:12:38 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30273106566C; Sun, 4 Apr 2010 22:12:38 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id ABEA28FC0C; Sun, 4 Apr 2010 22:12:37 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-253-149.belrs3.nsw.optusnet.com.au [122.106.253.149]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o34MCZPu008494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Apr 2010 08:12:35 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o34MCWDr020602; Mon, 5 Apr 2010 08:12:32 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o34MCWjh020601; Mon, 5 Apr 2010 08:12:32 +1000 (EST) (envelope-from peter) Date: Mon, 5 Apr 2010 08:12:32 +1000 From: Peter Jeremy To: Kostik Belousov Message-ID: <20100404221232.GJ86236@server.vk2pj.dyndns.org> References: <201004030839.o338d0VV032828@svn.freebsd.org> <20100404210314.GH86236@server.vk2pj.dyndns.org> <4BB9006A.8080301@freebsd.org> <20100404212742.GJ2415@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iRjOs3ViPWHdlw/I" Content-Disposition: inline In-Reply-To: <20100404212742.GJ2415@deviant.kiev.zoral.com.ua> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) X-CMAE-Score: 0 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Andriy Gapon Subject: Re: svn commit: r206129 - head/sys/kern X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 22:12:38 -0000 --iRjOs3ViPWHdlw/I Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Apr-05 00:27:42 +0300, Kostik Belousov wrote: >On Mon, Apr 05, 2010 at 12:11:06AM +0300, Andriy Gapon wrote: >> on 05/04/2010 00:03 Peter Jeremy said the following: >> > On 2010-Apr-03 08:39:00 +0000, Andriy Gapon wrote: >> >> vn_stat: take into account va_blocksize when setting st_blksize =2E.. >> > I haven't verified it but, based on a quick look at the change, I >> > suspect this will trigger the problem in bin/144446. Quick summary: >> > db(3) has restrictions on its internal bucket size but initializes it >> > from st_blksize with no sanity checking and ZFS can report blocksizes >> > outside the allowed bucket size range for db(3). >>=20 >> Thank you for pointing this out. >> If no one objects or provides a better patch, I will commit yours. > >I do not think this is very satisfying solution. Pre-patched libc >still suffer from the problem. You cannot run stable/8 libc on this >kernel. Firstly, has someone with a post-r206129 kernel verified that it does actually trigger the issue I reported in bin/144446? I'm not in a position to do so easily and it's possible that the problem is masked elsewhere. Also, Kostik's comment is a slight exaggeration: You can't create a db(3) database from scratch in a ZFS filesystem using db(3) defaults. Note that as of now, it's exactly the same situation as running -current libc with a post-r206129 kernel. -current is expected to include occasions of bumpiness so I don't see this as an immediate reason to revert r206129 - though if buildworld or installworld are affected, it at least needs a heads-up. OTOH, I think some care needs to taken over any MFC of this change. At the very least, the db(3) problem needs to be fixed and there probably needs to be an extended shakedown of r206129 to ensure that there aren't any other similar nasties lurking elsewhere. The problem I reported in bin/144446 is a bug in a userland utility and IMHO, it's not the kernel's responsibility to work around userland bugs. --=20 Peter Jeremy --iRjOs3ViPWHdlw/I Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAku5DtAACgkQ/opHv/APuIegqwCfT+ZGgoZyA1TQDgHIHS30qpmx dUUAoLk9nNoBsQhOe1p7Csib8uOpVwtD =/Drm -----END PGP SIGNATURE----- --iRjOs3ViPWHdlw/I--