From owner-svn-src-projects@FreeBSD.ORG Tue May 8 09:56:41 2012 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC80D106566B; Tue, 8 May 2012 09:56:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 4D63F8FC12; Tue, 8 May 2012 09:56:41 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q489uWLG067286; Tue, 8 May 2012 12:56:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q489uWIf075340; Tue, 8 May 2012 12:56:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q489uVDx075339; Tue, 8 May 2012 12:56:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 8 May 2012 12:56:31 +0300 From: Konstantin Belousov To: Grzegorz Bernacki Message-ID: <20120508095631.GV2358@deviant.kiev.zoral.com.ua> References: <201203170318.q2H3ITdI047893@svn.freebsd.org> <20120317085116.GC1340@garage.freebsd.pl> <20120317161050.GI75778@deviant.kiev.zoral.com.ua> <4FA8FFB9.7090002@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G+2xtMkjVKN5mon6" Content-Disposition: inline In-Reply-To: <4FA8FFB9.7090002@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r233072 - projects/nand/sys/kern X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 09:56:42 -0000 --G+2xtMkjVKN5mon6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 08, 2012 at 01:12:57PM +0200, Grzegorz Bernacki wrote: > On 03/17/12 17:10, Konstantin Belousov wrote: > >On Sat, Mar 17, 2012 at 09:51:16AM +0100, Pawel Jakub Dawidek wrote: > >>On Sat, Mar 17, 2012 at 03:18:29AM +0000, Grzegorz Bernacki wrote: > >>>Author: gber > >>>Date: Sat Mar 17 03:18:28 2012 > >>>New Revision: 233072 > >>>URL: http://svn.freebsd.org/changeset/base/233072 > >>> > >>>Log: > >>> Add VFS changes necessary for NANDFS to work. > >>> > >>> Ignore B_MANAGED buffer by syncer and ignore signal when msleep as = it > >>> can cause file system inconsistency. > >> > >>I'd suggest running these changes through kib@. Especially=20 > >>vn_start_write() > >>change below looks ugly, but maybe it is only temporary? > >It is not only ugly (and object against it). > > > >If the change makes any difference for the filesystem, then I just argue > >that the filesystem is broken. The vn_start_write() is done on the > >VFS entry peripheral, long before filesystem code is hit. > > > >I did not looked at the managed changes, you would need to describe > >what is wrong with current code and what is the purpose of the changes. > >B_MANAGED came from xfs, it seems, or at least xfs is the only current > >consumer of B_MANAGED buffers. >=20 > Hi Kostik, >=20 > Without our change in getblk() whenewer we allocate new block we get pani= c: >=20 > panic: bremfree: buffer 0xffffff807bf86080 not on a queue. >=20 > It is because blocks with B_MANAGED flag are not queued on any queue in= =20 > brelse() function. Could you look at it and give us approval to merge=20 > this change into HEAD? Right, but this is in fact the only function of the B_MANAGED flag. So the question is, what are you trying to accomplish. --G+2xtMkjVKN5mon6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+o7c8ACgkQC3+MBN1Mb4iE4gCfb0+uywOSiHpdcv3pYxQ6rlY/ iFcAnim67HzUPhyScxHoenoiaG15TyrY =nIwi -----END PGP SIGNATURE----- --G+2xtMkjVKN5mon6--