From owner-freebsd-fs Mon Dec 2 11: 0:53 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F0DE37B404 for ; Mon, 2 Dec 2002 11:00:53 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C879843E4A for ; Mon, 2 Dec 2002 11:00:52 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id gB2J0qx3028350 for ; Mon, 2 Dec 2002 11:00:52 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id gB2J0q37028338 for fs@freebsd.org; Mon, 2 Dec 2002 11:00:52 -0800 (PST) Date: Mon, 2 Dec 2002 11:00:52 -0800 (PST) Message-Id: <200212021900.gB2J0q37028338@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: fs@FreeBSD.org Subject: Current problem reports assigned to you Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2000/10/06] kern/21807 fs [patches] Make System attribute correspon 1 problem total. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Dec 4 18:19: 9 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C98FC37B401 for ; Wed, 4 Dec 2002 18:19:06 -0800 (PST) Received: from smtp01.iprimus.net.au (smtp01.iprimus.net.au [210.50.30.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2B2043EA9 for ; Wed, 4 Dec 2002 18:19:04 -0800 (PST) (envelope-from tim@robbins.dropbear.id.au) Received: from dilbert.robbins.dropbear.id.au ([210.50.204.50]) by smtp01.iprimus.net.au with Microsoft SMTPSVC(5.0.2195.5600); Thu, 5 Dec 2002 13:19:01 +1100 Received: from dilbert.robbins.dropbear.id.au (2aowoa1lio721sew@localhost [127.0.0.1]) by dilbert.robbins.dropbear.id.au (8.12.6/8.12.6) with ESMTP id gB52IxWo055462 for ; Thu, 5 Dec 2002 13:19:00 +1100 (EST) (envelope-from tim@dilbert.robbins.dropbear.id.au) Received: (from tim@localhost) by dilbert.robbins.dropbear.id.au (8.12.6/8.12.6/Submit) id gB52Iw6S055461 for freebsd-fs@freebsd.org; Thu, 5 Dec 2002 13:18:58 +1100 (EST) (envelope-from tim) Date: Thu, 5 Dec 2002 13:18:58 +1100 From: Tim Robbins To: freebsd-fs@freebsd.org Subject: vflush() and dependencies between vnodes Message-ID: <20021205131858.A54625@dilbert.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-OriginalArrivalTime: 05 Dec 2002 02:19:02.0087 (UTC) FILETIME=[AD497570:01C29C04] Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've spent the past couple of days tracking down the bug that caused umount -f on smbfs to panic, and umount without -f to often give EBUSY when it should not have. smbfs stores a pointer to each file or directory's parent directory in the smbnode struct and vref()'s the parent directory's vnode. This means that an smbfs directory vnode cannot be removed before all of its children have vrele()'d it. However, vflush() iterates through the mount's vnode list from start to end, so if a directory vnode appears in the list before its children, it will not be removed. This causes a panic when umount -f is used because smbfs_reclaim() calls vrele() on the parent vnode after it has already been freed. This also causes umount without -f to erroneously return EBUSY. Can anyone think of a better way to solve this problem than to keep rescanning the mount's vnode list until no more vnodes can be freed, like the patch below does? The output is typically like this: vflush: trying again, 202 busy vnodes left vflush: trying again, 64 busy vnodes left vflush: trying again, 9 busy vnodes left vflush: trying again, 5 busy vnodes left vflush: trying again, 3 busy vnodes left vflush: trying again, 2 busy vnodes left vflush: trying again, 1 busy vnodes left vflush: forcibly closing 1 vnodes It seems to take approximately lg N passes where N is the number of busy vnodes in the list, so its performance is not terribly bad, it's just not very elegant. Tim Index: vfs_subr.c =================================================================== RCS file: /x/freebsd/src/sys/kern/vfs_subr.c,v retrieving revision 1.420 diff -u -r1.420 vfs_subr.c --- vfs_subr.c 27 Nov 2002 16:45:54 -0000 1.420 +++ vfs_subr.c 5 Dec 2002 00:49:39 -0000 @@ -73,6 +73,8 @@ #include #include +#include + static MALLOC_DEFINE(M_NETADDR, "Export Host", "Export host address structure"); static void addalias(struct vnode *vp, dev_t nvp_rdev); @@ -2322,7 +2324,7 @@ struct thread *td = curthread; /* XXX */ struct vnode *vp, *nvp, *rootvp = NULL; struct vattr vattr; - int busy = 0, error; + int busy = 0, error, lastpass = 0, prevbusy = INT_MAX; if (rootrefs > 0) { KASSERT((flags & (SKIPSYSTEM | WRITECLOSE)) == 0, @@ -2394,7 +2396,7 @@ * or character devices, revert to an anonymous device. For * all other files, just kill them. */ - if (flags & FORCECLOSE) { + if (lastpass && flags & FORCECLOSE) { if (vp->v_type != VCHR) { vgonel(vp, td); } else { @@ -2413,6 +2415,38 @@ VI_UNLOCK(vp); mtx_lock(&mntvnode_mtx); busy++; + } + if (busy != 0 && !lastpass) { + if (busy < prevbusy) { + /* + * Some vnodes were removed but some are still active. + * Rescan the list trying to close them again in case + * some vnodes are holding references to others. + * + * This happens on smbfs because file vnodes hold + * references to their parent directories. + */ +#ifdef DIAGNOSTIC + printf("vflush: trying again, %d busy vnodes left\n", + busy); +#endif + prevbusy = busy; + busy = 0; + goto loop; + } + if (flags & FORCECLOSE) { + /* + * There are no more inactive vnodes to remove. Make + * a final pass over the list to forcibly close any + * remaining active vnodes. + */ +#ifdef DIAGNOSTIC + printf("vflush: forcibly closing %d vnodes\n", busy); +#endif + lastpass = 1; + busy = 0; + goto loop; + } } mtx_unlock(&mntvnode_mtx); if (rootrefs > 0 && (flags & FORCECLOSE) == 0) { To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Dec 4 18:48: 0 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9027937B401; Wed, 4 Dec 2002 18:47:59 -0800 (PST) Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id D794343EC5; Wed, 4 Dec 2002 18:47:57 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0353.cvx40-bradley.dialup.earthlink.net ([216.244.43.98] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 18Jm3Q-00046m-00; Wed, 04 Dec 2002 18:47:57 -0800 Message-ID: <3DEEBE0B.CA5156EE@mindspring.com> Date: Wed, 04 Dec 2002 18:46:35 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Robbins Cc: freebsd-fs@freebsd.org Subject: Re: vflush() and dependencies between vnodes References: <20021205131858.A54625@dilbert.robbins.dropbear.id.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Tim Robbins wrote: > smbfs stores a pointer to each file or directory's parent directory in > the smbnode struct and vref()'s the parent directory's vnode. This means > that an smbfs directory vnode cannot be removed before all of its > children have vrele()'d it. However, vflush() iterates through the > mount's vnode list from start to end, so if a directory vnode appears > in the list before its children, it will not be removed. This causes a > panic when umount -f is used because smbfs_reclaim() calls vrele() on the > parent vnode after it has already been freed. This also causes umount > without -f to erroneously return EBUSY. > > Can anyone think of a better way to solve this problem than to keep > rescanning the mount's vnode list until no more vnodes can be freed, > like the patch below does? Yes. Let SMBFS own its own vnodes, instead of renting them from the system vnode pool. Problem solved. Personally, I think your patch is "good enough". -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Dec 5 2:22:38 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B66937B401; Thu, 5 Dec 2002 02:22:37 -0800 (PST) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id E034543ECD; Thu, 5 Dec 2002 02:22:35 -0800 (PST) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 5 Dec 2002 10:22:35 +0000 (GMT) To: Tim Robbins Cc: freebsd-fs@freebsd.org Subject: Re: vflush() and dependencies between vnodes In-Reply-To: Your message of "Thu, 05 Dec 2002 13:18:58 +1100." <20021205131858.A54625@dilbert.robbins.dropbear.id.au> Date: Thu, 05 Dec 2002 10:22:34 +0000 From: Ian Dowse Message-ID: <200212051022.aa49886@salmon.maths.tcd.ie> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <20021205131858.A54625@dilbert.robbins.dropbear.id.au>, Tim Robbins writes: >I've spent the past couple of days tracking down the bug that caused >umount -f on smbfs to panic, and umount without -f to often give EBUSY >when it should not have. > >smbfs stores a pointer to each file or directory's parent directory in >the smbnode struct and vref()'s the parent directory's vnode. This means >that an smbfs directory vnode cannot be removed before all of its >children have vrele()'d it. However, vflush() iterates through the >mount's vnode list from start to end, so if a directory vnode appears >in the list before its children, it will not be removed. This causes a >panic when umount -f is used because smbfs_reclaim() calls vrele() on the >parent vnode after it has already been freed. This also causes umount >without -f to erroneously return EBUSY. >Can anyone think of a better way to solve this problem than to keep >rescanning the mount's vnode list until no more vnodes can be freed, >like the patch below does? I think for the non-forced case, an approach like this is quite a reasonable solution to avoid the EBUSY errors. For the forced case it shouldn't be necessary though - vnodes are not freed until the last reference is dropped, so even if a referenced vnode gets killed before the vnode that references it, calling vrele() on the original vnode should do the right thing and be safe. I have noticed panics recently when forcefully unmounting nfs filesystems, so there may be a more general problem here (I have some local changes that KASSERT that a vnode is unlocked when its last reference is vrele()'d, and I use vop_stdlock for nfs - the KASSERT often triggers after a forceful unmount, suggesting that something is doing too many vrele()'s and missing an unlock). Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Dec 5 13:42:30 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB0C237B401; Thu, 5 Dec 2002 13:42:27 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-64-169-106-8.dsl.lsan03.pacbell.net [64.169.106.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B2CB43EC5; Thu, 5 Dec 2002 13:42:21 -0800 (PST) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 9715966BE3; Thu, 5 Dec 2002 13:42:20 -0800 (PST) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id C853D12A3; Thu, 5 Dec 2002 13:42:19 -0800 (PST) Date: Thu, 5 Dec 2002 13:42:19 -0800 From: Kris Kennaway To: current@FreeBSD.org, fs@FreeBSD.org Cc: kirk@mckusick.com Subject: panic: ffs_vfree: range: dev = ad4s1c, ino = -1690809896, fs = /mnt2 Message-ID: <20021205214219.GA1190@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I got this on a recent -current (kernel built Dec 1). The filesystem was under heavy disk load at the time (cvsup of CVS repo, make installworld, and cvs update of the src tree from a sparc64 NFS client). When it rebooted there was minor FS corruption (a few files lost/truncated). Kris panic: bremfree: bp 0xce65cf00 not locked panic messages: --- panic: ffs_vfree: range: dev = ad4s1c, ino = -1690809896, fs = /mnt2 syncing disks, buffers remaining... panic: bremfree: bp 0xce65cf00 not locked Uptime: 3d12h58m21s Dumping 511 MB ata0: resetting devices .. done 16 32[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 48 64[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 --- #0 doadump () at ../../../kern/kern_shutdown.c:232 232 dumping++; (kgdb) bt #0 doadump () at ../../../kern/kern_shutdown.c:232 #1 0xc01e10d5 in boot (howto=260) at ../../../kern/kern_shutdown.c:364 #2 0xc01e1323 in panic () at ../../../kern/kern_shutdown.c:517 #3 0xc0221ad7 in bremfree (bp=0xce65cf00) at ../../../kern/vfs_bio.c:632 #4 0xc02244d0 in getblk (vp=0xc4156000, blkno=352, size=16384, slpflag=0, slptimeo=0) at ../../../kern/vfs_bio.c:2344 #5 0xc0221c0a in breadn (vp=0xc4156000, blkno=0, size=0, rablkno=0x0, rabsize=0x0, cnt=0, cred=0x0, bpp=0x0) at ../../../kern/vfs_bio.c:690 #6 0xc0221bbc in bread (vp=0x0, blkno=0, size=0, cred=0x0, bpp=0x0) at ../../../kern/vfs_bio.c:672 #7 0xc02b0878 in ffs_update (vp=0xc44fa5dc, waitfor=0) at ../../../ufs/ffs/ffs_inode.c:102 #8 0xc02c49df in ffs_fsync (ap=0xdc06a864) at ../../../ufs/ffs/ffs_vnops.c:315 #9 0xc02c3b4e in ffs_sync (mp=0xc4032600, waitfor=2, cred=0xc150af00, td=0xc038ac80) at vnode_if.h:612 #10 0xc0235a78 in sync (td=0xc038ac80, uap=0x0) at ../../../kern/vfs_syscalls.c:138 #11 0xc01e0d1c in boot (howto=256) at ../../../kern/kern_shutdown.c:273 #12 0xc01e1323 in panic () at ../../../kern/kern_shutdown.c:517 #13 0xc02acc0b in ffs_freefile (fs=0xc4304800, devvp=0xc44fbce4, ino=2604157400, mode=16832) at ../../../ufs/ffs/ffs_alloc.c:1899 #14 0xc02bd124 in handle_workitem_freefile (freefile=0xc7e53120) at ../../../ufs/ffs/ffs_softdep.c:3389 #15 0xc02bb48b in softdep_freefile (pvp=0x0, ino=2604157400, mode=0) at ../../../ufs/ffs/ffs_softdep.c:2338 #16 0xc02aca3e in ffs_vfree (pvp=0x0, ino=0, mode=16832) at ../../../ufs/ffs/ffs_alloc.c:1864 #17 0xc02aa604 in ffs_valloc (pvp=0xc7b0ea8c, mode=16832, cred=0xc710fe80, vpp=0xdc06aa54) at ../../../ufs/ffs/ffs_alloc.c:864 #18 0xc02d0028 in ufs_mkdir (ap=0xdc06abbc) at ../../../ufs/ufs/ufs_vnops.c:1375 #19 0xc02d18e8 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2796 #20 0xc023a866 in kern_mkdir (td=0xc7b9fd20, path=---Can't read userspace from dump, or kernel process--- ) at vnode_if.h:757 #21 0xc023a629 in mkdir (td=0x0, uap=0x0) at ../../../kern/vfs_syscalls.c:2882 #22 0xc0325dee in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 134594432, tf_ebp = -1077939272, tf_isp = -603542156, tf_ebx = 134539156, tf_edx = 134536583, tf_ecx = -1077939536, tf_eax = 136, tf_trapno = 0, tf_err = 2, tf_eip = 671871219, tf_cs = 31, tf_eflags = 514, tf_esp = -1077939412, tf_ss = 47}) at ../../../i386/i386/trap.c:1033 #23 0xc031602d in Xint0x80_syscall () at {standard input}:140 ---Can't read userspace from dump, or kernel process--- --mYCpIKhGyMATD0i+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE978g6Wry0BWjoQKURAkmlAJ9cVW1r6h5zjke8dYHLsaB1DghepgCfQZQM NQapsfwSHkDCG7xgMcFuLxw= =0ysJ -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Dec 5 15:33:31 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE72437B401; Thu, 5 Dec 2002 15:33:27 -0800 (PST) Received: from juno.com (adsl-66-124-154-165.dsl.sntc01.pacbell.net [66.124.154.165]) by mx1.FreeBSD.org (Postfix) with SMTP id 426E443ECD; Thu, 5 Dec 2002 15:32:29 -0800 (PST) (envelope-from harbeck@juno.com) Received: from [60.4.3.129] by symail.kustanai.co.kr with smtp; 06 Dec 2002 03:32:19 -0900 Received: from 84.239.38.8 ([84.239.38.8]) by mailout2-eri1.midmouth.com with asmtp; 05 Dec 2002 18:27:56 +0300 Received: from unknown (HELO mta21.bigpong.com) (145.51.44.13) by mail.gimmixx.net with asmtp; 05 Dec 2002 21:23:33 -0300 Received: from 30.147.153.164 ([30.147.153.164]) by rly-yk04.aolmd.com with local; 05 Dec 2002 18:19:10 +0500 Reply-To: Message-ID: <004b07e08c8b$5731a7a1$7cd27ca2@grbwnb> From: To: Cc: , , , , , , , , , , , , , , , Subject: Financial freedom in 24 days or less Date: Fri, 06 Dec 2002 10:27:03 -1100 MiME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: The Bat! (v1.52f) Business Importance: Normal Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, Would you like to make $100,000 a year online? If so, then this is your magical email to the kingdom of financial freedom. Think about how life would be WITHOUT an alarm clock waking you up every morning. Or sitting in traffic all morning. Are you frustrated that you belong to the corporate world? IMAGINE your daily commute taking 20 seconds as you walk to your computer! Is this just a dream? Many people think so but they are ABSOLUTELY WRONG. Financial freedom is given to people who jump at the opportunity, not to those who hesitate. 2 years ago I was just like you, I was making $12 an hour working my butt off struggling to pay my bills. One day, a friend of mine introduced me to the GREATEST business ever created online. Within 6 months of working just an hour a day, I was able to quit my full time job and leave the corporate world FOREVER. Now I would like to share this opportunity with you. It is MY DUTY to help you get to the places you dream about, and I'm about to do just that. Normally, there is a $29.99 charge associated with joining this business. But for the next 48 hours, you can sign up, ABSOLUTELY FREE. Even if this isn't the opportunity of a lifetime, how can you afford to pass up this chance? You have nothing to lose! No credit card required, Nothing! All you have to do is click on the link below to learn more about this AMAZING business. http://www.product-galore.com/affiliate.htm Thank you and have a great day! Dan Meadows Jr. 0863al5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Dec 5 16:43:52 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1D1F37B406 for ; Thu, 5 Dec 2002 16:43:49 -0800 (PST) Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5565E43E4A for ; Thu, 5 Dec 2002 16:43:49 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.3/8.12.3) with ESMTP id gB60hW59091888; Thu, 5 Dec 2002 16:43:32 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200212060043.gB60hW59091888@beastie.mckusick.com> To: Kris Kennaway Subject: Re:panic: ffs_vfree: range: dev = ad4s1c, ino = -1690809896, fs = /mnt2 Cc: Robert Watson , fs@FreeBSD.ORG In-Reply-To: Your message of "Thu, 05 Dec 2002 13:42:19 PST." <20021205214219.GA1190@rot13.obsecurity.org> Date: Thu, 05 Dec 2002 16:43:32 -0800 From: Kirk McKusick Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Do you still have this crash dump available? The back trace looks "impossible". The call to ffs_vfree at line #16 below shows pvp=0 and ino=0. Inspection of the code shows this to be impossible as three lines above the call to ffs_vfree is a check for ino == 0 which takes a different path. The call to softdep_freefile at #15 uses the passed in value of ino, yet shows ino=2604157400. So I have no idea what is really going on here. I am guessing that gdb must be lying about the values. Alternatively you kernel stack is somehow getting trashed. At any rate, if you still have the dump available, it would be useful to send me the output from the following gdb commands: frame 17 print error print ino print ipref print cg print pvp print *pvp print pip print *pip print fs print *fs Thanks, Kirk McKusick =-=-=-=-=-= Date: Thu, 5 Dec 2002 13:42:19 -0800 From: Kris Kennaway To: current@FreeBSD.ORG, fs@FreeBSD.ORG Cc: kirk@mckusick.com Subject: panic: ffs_vfree: range: dev = ad4s1c, ino = -1690809896, fs = /mnt2 I got this on a recent -current (kernel built Dec 1). The filesystem was under heavy disk load at the time (cvsup of CVS repo, make installworld, and cvs update of the src tree from a sparc64 NFS client). When it rebooted there was minor FS corruption (a few files lost/truncated). Kris panic: bremfree: bp 0xce65cf00 not locked panic messages: --- panic: ffs_vfree: range: dev = ad4s1c, ino = -1690809896, fs = /mnt2 syncing disks, buffers remaining... panic: bremfree: bp 0xce65cf00 not locked Uptime: 3d12h58m21s Dumping 511 MB ata0: resetting devices .. done 16 32[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 48 64[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 --- #0 doadump () at ../../../kern/kern_shutdown.c:232 232 dumping++; (kgdb) bt #0 doadump () at ../../../kern/kern_shutdown.c:232 #1 0xc01e10d5 in boot (howto=260) at ../../../kern/kern_shutdown.c:364 #2 0xc01e1323 in panic () at ../../../kern/kern_shutdown.c:517 #3 0xc0221ad7 in bremfree (bp=0xce65cf00) at ../../../kern/vfs_bio.c:632 #4 0xc02244d0 in getblk (vp=0xc4156000, blkno=352, size=16384, slpflag=0, slptimeo=0) at ../../../kern/vfs_bio.c:2344 #5 0xc0221c0a in breadn (vp=0xc4156000, blkno=0, size=0, rablkno=0x0, rabsize=0x0, cnt=0, cred=0x0, bpp=0x0) at ../../../kern/vfs_bio.c:690 #6 0xc0221bbc in bread (vp=0x0, blkno=0, size=0, cred=0x0, bpp=0x0) at ../../../kern/vfs_bio.c:672 #7 0xc02b0878 in ffs_update (vp=0xc44fa5dc, waitfor=0) at ../../../ufs/ffs/ffs_inode.c:102 #8 0xc02c49df in ffs_fsync (ap=0xdc06a864) at ../../../ufs/ffs/ffs_vnops.c:315 #9 0xc02c3b4e in ffs_sync (mp=0xc4032600, waitfor=2, cred=0xc150af00, td=0xc038ac80) at vnode_if.h:612 #10 0xc0235a78 in sync (td=0xc038ac80, uap=0x0) at ../../../kern/vfs_syscalls.c:138 #11 0xc01e0d1c in boot (howto=256) at ../../../kern/kern_shutdown.c:273 #12 0xc01e1323 in panic () at ../../../kern/kern_shutdown.c:517 #13 0xc02acc0b in ffs_freefile (fs=0xc4304800, devvp=0xc44fbce4, ino=2604157400, mode=16832) at ../../../ufs/ffs/ffs_alloc.c:1899 #14 0xc02bd124 in handle_workitem_freefile (freefile=0xc7e53120) at ../../../ufs/ffs/ffs_softdep.c:3389 #15 0xc02bb48b in softdep_freefile (pvp=0x0, ino=2604157400, mode=0) at ../../../ufs/ffs/ffs_softdep.c:2338 #16 0xc02aca3e in ffs_vfree (pvp=0x0, ino=0, mode=16832) at ../../../ufs/ffs/ffs_alloc.c:1864 #17 0xc02aa604 in ffs_valloc (pvp=0xc7b0ea8c, mode=16832, cred=0xc710fe80, vpp=0xdc06aa54) at ../../../ufs/ffs/ffs_alloc.c:864 #18 0xc02d0028 in ufs_mkdir (ap=0xdc06abbc) at ../../../ufs/ufs/ufs_vnops.c:1375 #19 0xc02d18e8 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2796 #20 0xc023a866 in kern_mkdir (td=0xc7b9fd20, path=---Can't read userspace from dump, or kernel process--- ) at vnode_if.h:757 #21 0xc023a629 in mkdir (td=0x0, uap=0x0) at ../../../kern/vfs_syscalls.c:2882 #22 0xc0325dee in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 134594432, tf_ebp = -1077939272, tf_isp = -603542156, tf_ebx = 134539156, tf_edx = 134536583, tf_ecx = -1077939536, tf_eax = 136, tf_trapno = 0, tf_err = 2, tf_eip = 671871219, tf_cs = 31, tf_eflags = 514, tf_esp = -1077939412, tf_ss = 47}) at ../../../i386/i386/trap.c:1033 #23 0xc031602d in Xint0x80_syscall () at {standard input}:140 ---Can't read userspace from dump, or kernel process--- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Dec 5 16:49:32 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A98537B401 for ; Thu, 5 Dec 2002 16:49:29 -0800 (PST) Received: from obsecurity.dyndns.org (adsl-64-169-106-8.dsl.lsan03.pacbell.net [64.169.106.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6475043E9C for ; Thu, 5 Dec 2002 16:49:28 -0800 (PST) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 09E3866BE3; Thu, 5 Dec 2002 16:49:28 -0800 (PST) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 85BEC1308; Thu, 5 Dec 2002 16:49:21 -0800 (PST) Date: Thu, 5 Dec 2002 16:49:21 -0800 From: Kris Kennaway To: Kirk McKusick Cc: Kris Kennaway , Robert Watson , fs@FreeBSD.ORG Subject: Re: panic: ffs_vfree: range: dev = ad4s1c, ino = -1690809896, fs = /mnt2 Message-ID: <20021206004921.GB69174@rot13.obsecurity.org> References: <20021205214219.GA1190@rot13.obsecurity.org> <200212060043.gB60hW59091888@beastie.mckusick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200212060043.gB60hW59091888@beastie.mckusick.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Dec 05, 2002 at 04:43:32PM -0800, Kirk McKusick wrote: > Do you still have this crash dump available? The back trace looks > "impossible". The call to ffs_vfree at line #16 below shows pvp=0 > and ino=0. Inspection of the code shows this to be impossible > as three lines above the call to ffs_vfree is a check for ino == 0 > which takes a different path. The call to softdep_freefile at #15 > uses the passed in value of ino, yet shows ino=2604157400. So I > have no idea what is really going on here. I am guessing that gdb > must be lying about the values. Alternatively you kernel stack is > somehow getting trashed. At any rate, if you still have the dump > available, it would be useful to send me the output from the > following gdb commands: > > frame 17 > print error > print ino > print ipref > print cg > print pvp > print *pvp > print pip > print *pip > print fs > print *fs (kgdb) frame 17 #17 0xc02aa604 in ffs_valloc (pvp=0xc7b0ea8c, mode=16832, cred=0xc710fe80, vpp=0xdc06aa54) at ../../../ufs/ffs/ffs_alloc.c:864 864 UFS_VFREE(pvp, ino, mode); (kgdb) print error $1 = 5 (kgdb) print ino $2 = 2604157400 (kgdb) print ipref $3 = 0 (kgdb) print cg $4 = 16832 (kgdb) print pvp $5 = (struct vnode *) 0xc7b0ea8c (kgdb) print *pvp $6 = {v_interlock = {mtx_object = {lo_class = 0xc038f2a0, lo_name = 0xc0367c5d "vnode interlock", lo_type = 0xc0367c5d "vnode interlock", lo_flags = 196608, lo_list = {tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0, mtx_blocked = {tqh_first = 0x0, tqh_last = 0xc7b0eab0}, mtx_contested = {le_next = 0x0, le_prev = 0x0}, mtx_acqtime = 0, mtx_filename = 0x0, mtx_lineno = 0}, v_iflag = 512, v_usecount = 1, v_numoutput = 0, v_vxproc = 0x0, v_holdcnt = 2, v_cleanblkhd = {tqh_first = 0x0, tqh_last = 0xc7b0eae4}, v_cleanblkroot = 0x0, v_dirtyblkhd = {tqh_first = 0xce594ec0, tqh_last = 0xce594f4c}, v_dirtyblkroot = 0xce594ec0, v_vflag = 0, v_writecount = 0, v_object = 0x0, v_lastw = 0, v_cstart = 0, v_lasta = 0, v_clen = 0, v_un = {vu_mountedhere = 0x0, vu_socket = 0x0, vu_spec = {vu_cdev = 0x0, vu_specnext = {sle_next = 0x0}}, vu_fifoinfo = 0x0}, v_freelist = {tqe_next = 0xc7d53384, tqe_prev = 0xc03c5174}, v_nmntvnodes = {tqe_next = 0xc7d53384, tqe_prev = 0xc67bcd8c}, v_synclist = {le_next = 0xc67bcce4, le_prev = 0xc7d53434}, v_type = VDIR, v_tag = 0xc0369ec6 "ufs", v_data = 0xc6475300, v_lock = {lk_interlock = 0xc03c1ab4, lk_flags = 16778304, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 80, lk_wmesg = 0xc0369ec6 "ufs", lk_timo = 6, lk_lockholder = 12154, lk_newlock = 0x0}, v_vnlock = 0xc7b0eb50, v_op = 0xc403c100, v_mount = 0xc4514800, v_cache_src = {lh_first = 0xc61aff40}, v_cache_dst = {tqh_first = 0xc72cf100, tqh_last = 0xc72cf110}, v_id = 27432477, v_dd = 0xc552ace4, v_ddid = 27432291, v_pollinfo = 0x0, v_label = {l_flags = 0, l_perpolicy = {{l_ptr = 0x0, l_long = 0}, { l_ptr = 0x0, l_long = 0}, {l_ptr = 0x0, l_long = 0}, {l_ptr = 0x0, l_long = 0}}}, v_cachedfs = 1034, v_cachedid = 4294967295} (kgdb) print pip $7 = (struct inode *) 0x5 (kgdb) print *pip ---Can't read userspace from dump, or kernel process--- (kgdb) print fs $8 = (struct fs *) 0xc4304800 (kgdb) print *fs $9 = {fs_firstfield = 0, fs_unused_1 = 0, fs_sblkno = 8, fs_cblkno = 16, fs_iblkno = 24, fs_dblkno = 792, fs_old_cgoffset = 1024, fs_old_cgmask = -1, fs_old_time = 1038811783, fs_old_size = 28523391, fs_old_dsize = 28297588, fs_ncg = 288, fs_bsize = 16384, fs_fsize = 2048, fs_frag = 8, fs_minfree = 8, fs_old_rotdelay = 0, fs_old_rps = 60, fs_bmask = -16384, fs_fmask = -2048, fs_bshift = 14, fs_fshift = 11, fs_maxcontig = 7, fs_maxbpg = 4096, fs_fragshift = 3, fs_fsbtodb = 2, fs_sbsize = 2048, fs_spare1 = {-1024, 10}, fs_nindir = 4096, fs_inopb = 128, fs_old_nspf = 4, fs_optim = 0, fs_old_npsect = 4096, fs_old_interleave = 1, fs_old_trackskew = 0, fs_id = {852110010, 602686169}, fs_old_csaddr = 792, fs_cssize = 6144, fs_cgsize = 16384, fs_spare2 = 1, fs_old_nsect = 4096, fs_old_spc = 4096, fs_old_ncyl = 27855, fs_old_cpg = 97, fs_ipg = 12288, fs_fpg = 99328, fs_old_cstotal = {cs_ndir = 175477, cs_nbfree = 2335208, cs_nifree = 2455182, cs_nffree = 134981}, fs_fmod = 1 '\001', fs_clean = 0 '\0', fs_ronly = 0 '\0', fs_old_flags = -126 '\202', fs_fsmnt = "/mnt2", '\0' , fs_cgrotor = 33, fs_ocsp = {0x0 }, fs_contigdirs = 0xc418dc80 "", fs_csp = 0xc418c000, fs_maxcluster = 0xc418d800, fs_active = 0x0, fs_old_cpc = 0, fs_maxbsize = 16384, fs_sparecon64 = {0 }, fs_sblockloc = 8192, fs_cstotal = {cs_ndir = 200327, cs_nbfree = 2081558, cs_nifree = 2374747, cs_nffree = 165297, cs_numclusters = 0, cs_spare = {0, 0, 0}}, fs_time = 1039118152, fs_size = 28523391, fs_dsize = 28297588, fs_csaddr = 792, fs_pendingblocks = 14244, fs_pendinginodes = 61, fs_snapinum = { 0 }, fs_avgfilesize = 16384, fs_avgfpdir = 64, fs_save_cgsize = 0, fs_sparecon32 = {0 }, fs_flags = 2, fs_contigsumsize = 7, fs_maxsymlinklen = 60, fs_old_inodefmt = 2, fs_maxfilesize = 17592186044415, fs_qbmask = 16383, fs_qfmask = 2047, fs_state = 0, fs_old_postblformat = 1, fs_old_nrpos = 1, fs_spare5 = {0, 0}, fs_magic = 72020} (kgdb) Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Dec 5 17:35:52 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C48137B401 for ; Thu, 5 Dec 2002 17:35:48 -0800 (PST) Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75A3C43EB2 for ; Thu, 5 Dec 2002 17:35:47 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.3/8.12.3) with ESMTP id gB61Zk59092119; Thu, 5 Dec 2002 17:35:46 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200212060135.gB61Zk59092119@beastie.mckusick.com> To: Kris Kennaway Subject: panic: ffs_vfree: range: dev = ad4s1c, ino = -1690809896, fs = /mnt2 Cc: Robert Watson , fs@FreeBSD.ORG In-Reply-To: Your message of "Thu, 05 Dec 2002 16:49:21 PST." <20021206004921.GB69174@rot13.obsecurity.org> Date: Thu, 05 Dec 2002 17:35:46 -0800 From: Kirk McKusick Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Well it is not at all clear how the dirpref routine came up with such an out of whack inode preference (2604157400 when the filesystem has only 3538944 inodes), but the following fix should catch it and make it harmless. I have submitted the patch to release engineering. Kirk McKusick =-=-=-=-= Index: ffs_alloc.c =================================================================== RCS file: /usr/ncvs/src/sys/ufs/ffs/ffs_alloc.c,v retrieving revision 1.102 diff -c -r1.102 ffs_alloc.c *** ffs_alloc.c 2002/09/19 03:55:30 1.102 --- ffs_alloc.c 2002/12/06 01:15:50 *************** *** 841,847 **** ipref = ffs_dirpref(pip); else ipref = pip->i_number; ! if (ipref >= fs->fs_ncg * fs->fs_ipg) ipref = 0; cg = ino_to_cg(fs, ipref); /* --- 841,847 ---- ipref = ffs_dirpref(pip); else ipref = pip->i_number; ! if ((unsigned)ipref >= fs->fs_ncg * fs->fs_ipg) ipref = 0; cg = ino_to_cg(fs, ipref); /* =-=-=-=-= Date: Thu, 5 Dec 2002 16:49:21 -0800 From: Kris Kennaway To: Kirk McKusick Cc: Kris Kennaway , Robert Watson , fs@FreeBSD.ORG Subject: panic: ffs_vfree: range: dev = ad4s1c, ino = -1690809896, fs = /mnt2 X-ASK-Info: Whitelist match On Thu, Dec 05, 2002 at 04:43:32PM -0800, Kirk McKusick wrote: > Do you still have this crash dump available? The back trace looks > "impossible". The call to ffs_vfree at line #16 below shows pvp=0 > and ino=0. Inspection of the code shows this to be impossible > as three lines above the call to ffs_vfree is a check for ino == 0 > which takes a different path. The call to softdep_freefile at #15 > uses the passed in value of ino, yet shows ino=2604157400. So I > have no idea what is really going on here. I am guessing that gdb > must be lying about the values. Alternatively you kernel stack is > somehow getting trashed. At any rate, if you still have the dump > available, it would be useful to send me the output from the > following gdb commands: > > frame 17 > print error > print ino > print ipref > print cg > print pvp > print *pvp > print pip > print *pip > print fs > print *fs (kgdb) frame 17 #17 0xc02aa604 in ffs_valloc (pvp=0xc7b0ea8c, mode=16832, cred=0xc710fe80, vpp=0xdc06aa54) at ../../../ufs/ffs/ffs_alloc.c:864 864 UFS_VFREE(pvp, ino, mode); (kgdb) print error $1 = 5 (kgdb) print ino $2 = 2604157400 (kgdb) print ipref $3 = 0 (kgdb) print cg $4 = 16832 (kgdb) print pvp $5 = (struct vnode *) 0xc7b0ea8c (kgdb) print *pvp $6 = {v_interlock = {mtx_object = {lo_class = 0xc038f2a0, lo_name = 0xc0367c5d "vnode interlock", lo_type = 0xc0367c5d "vnode interlock", lo_flags = 196608, lo_list = {tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0, mtx_blocked = {tqh_first = 0x0, tqh_last = 0xc7b0eab0}, mtx_contested = {le_next = 0x0, le_prev = 0x0}, mtx_acqtime = 0, mtx_filename = 0x0, mtx_lineno = 0}, v_iflag = 512, v_usecount = 1, v_numoutput = 0, v_vxproc = 0x0, v_holdcnt = 2, v_cleanblkhd = {tqh_first = 0x0, tqh_last = 0xc7b0eae4}, v_cleanblkroot = 0x0, v_dirtyblkhd = {tqh_first = 0xce594ec0, tqh_last = 0xce594f4c}, v_dirtyblkroot = 0xce594ec0, v_vflag = 0, v_writecount = 0, v_object = 0x0, v_lastw = 0, v_cstart = 0, v_lasta = 0, v_clen = 0, v_un = {vu_mountedhere = 0x0, vu_socket = 0x0, vu_spec = {vu_cdev = 0x0, vu_specnext = {sle_next = 0x0}}, vu_fifoinfo = 0x0}, v_freelist = {tqe_next = 0xc7d53384, tqe_prev = 0xc03c5174}, v_nmntvnodes = {tqe_next = 0xc7d53384, tqe_prev = 0xc67bcd8c}, v_synclist = {le_next = 0xc67bcce4, le_prev = 0xc7d53434}, v_type = VDIR, v_tag = 0xc0369ec6 "ufs", v_data = 0xc6475300, v_lock = {lk_interlock = 0xc03c1ab4, lk_flags = 16778304, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 80, lk_wmesg = 0xc0369ec6 "ufs", lk_timo = 6, lk_lockholder = 12154, lk_newlock = 0x0}, v_vnlock = 0xc7b0eb50, v_op = 0xc403c100, v_mount = 0xc4514800, v_cache_src = {lh_first = 0xc61aff40}, v_cache_dst = {tqh_first = 0xc72cf100, tqh_last = 0xc72cf110}, v_id = 27432477, v_dd = 0xc552ace4, v_ddid = 27432291, v_pollinfo = 0x0, v_label = {l_flags = 0, l_perpolicy = {{l_ptr = 0x0, l_long = 0}, { l_ptr = 0x0, l_long = 0}, {l_ptr = 0x0, l_long = 0}, {l_ptr = 0x0, l_long = 0}}}, v_cachedfs = 1034, v_cachedid = 4294967295} (kgdb) print pip $7 = (struct inode *) 0x5 (kgdb) print *pip ---Can't read userspace from dump, or kernel process--- (kgdb) print fs $8 = (struct fs *) 0xc4304800 (kgdb) print *fs $9 = {fs_firstfield = 0, fs_unused_1 = 0, fs_sblkno = 8, fs_cblkno = 16, fs_iblkno = 24, fs_dblkno = 792, fs_old_cgoffset = 1024, fs_old_cgmask = -1, fs_old_time = 1038811783, fs_old_size = 28523391, fs_old_dsize = 28297588, fs_ncg = 288, fs_bsize = 16384, fs_fsize = 2048, fs_frag = 8, fs_minfree = 8, fs_old_rotdelay = 0, fs_old_rps = 60, fs_bmask = -16384, fs_fmask = -2048, fs_bshift = 14, fs_fshift = 11, fs_maxcontig = 7, fs_maxbpg = 4096, fs_fragshift = 3, fs_fsbtodb = 2, fs_sbsize = 2048, fs_spare1 = {-1024, 10}, fs_nindir = 4096, fs_inopb = 128, fs_old_nspf = 4, fs_optim = 0, fs_old_npsect = 4096, fs_old_interleave = 1, fs_old_trackskew = 0, fs_id = {852110010, 602686169}, fs_old_csaddr = 792, fs_cssize = 6144, fs_cgsize = 16384, fs_spare2 = 1, fs_old_nsect = 4096, fs_old_spc = 4096, fs_old_ncyl = 27855, fs_old_cpg = 97, fs_ipg = 12288, fs_fpg = 99328, fs_old_cstotal = {cs_ndir = 175477, cs_nbfree = 2335208, cs_nifree = 2455182, cs_nffree = 134981}, fs_fmod = 1 '\001', fs_clean = 0 '\0', fs_ronly = 0 '\0', fs_old_flags = -126 '\202', fs_fsmnt = "/mnt2", '\0' , fs_cgrotor = 33, fs_ocsp = {0x0 }, fs_contigdirs = 0xc418dc80 "", fs_csp = 0xc418c000, fs_maxcluster = 0xc418d800, fs_active = 0x0, fs_old_cpc = 0, fs_maxbsize = 16384, fs_sparecon64 = {0 }, fs_sblockloc = 8192, fs_cstotal = {cs_ndir = 200327, cs_nbfree = 2081558, cs_nifree = 2374747, cs_nffree = 165297, cs_numclusters = 0, cs_spare = {0, 0, 0}}, fs_time = 1039118152, fs_size = 28523391, fs_dsize = 28297588, fs_csaddr = 792, fs_pendingblocks = 14244, fs_pendinginodes = 61, fs_snapinum = { 0 }, fs_avgfilesize = 16384, fs_avgfpdir = 64, fs_save_cgsize = 0, fs_sparecon32 = {0 }, fs_flags = 2, fs_contigsumsize = 7, fs_maxsymlinklen = 60, fs_old_inodefmt = 2, fs_maxfilesize = 17592186044415, fs_qbmask = 16383, fs_qfmask = 2047, fs_state = 0, fs_old_postblformat = 1, fs_old_nrpos = 1, fs_spare5 = {0, 0}, fs_magic = 72020} (kgdb) Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Dec 5 21:35:16 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B30E37B401 for ; Thu, 5 Dec 2002 21:35:15 -0800 (PST) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F55243E9C for ; Thu, 5 Dec 2002 21:35:14 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by rwcrmhc51.attbi.com (rwcrmhc51) with ESMTP id <20021206053512051008cds5e>; Fri, 6 Dec 2002 05:35:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id VAA40912; Thu, 5 Dec 2002 21:34:22 -0800 (PST) Date: Thu, 5 Dec 2002 21:34:20 -0800 (PST) From: Julian Elischer To: Kirk McKusick Cc: Kris Kennaway , Robert Watson , fs@FreeBSD.ORG Subject: Re: panic: ffs_vfree: range: dev = ad4s1c, ino = -1690809896, fs = /mnt2 In-Reply-To: <200212060135.gB61Zk59092119@beastie.mckusick.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is one of the reasons that I think such fields should all be defined as unsigned to start with.. On Thu, 5 Dec 2002, Kirk McKusick wrote: > Well it is not at all clear how the dirpref routine came up with > such an out of whack inode preference (2604157400 when the filesystem > has only 3538944 inodes), but the following fix should catch it and > make it harmless. I have submitted the patch to release engineering. > > Kirk McKusick > > =-=-=-=-= > > Index: ffs_alloc.c > =================================================================== > RCS file: /usr/ncvs/src/sys/ufs/ffs/ffs_alloc.c,v > retrieving revision 1.102 > diff -c -r1.102 ffs_alloc.c > *** ffs_alloc.c 2002/09/19 03:55:30 1.102 > --- ffs_alloc.c 2002/12/06 01:15:50 > *************** > *** 841,847 **** > ipref = ffs_dirpref(pip); > else > ipref = pip->i_number; > ! if (ipref >= fs->fs_ncg * fs->fs_ipg) > ipref = 0; > cg = ino_to_cg(fs, ipref); > /* > --- 841,847 ---- > ipref = ffs_dirpref(pip); > else > ipref = pip->i_number; > ! if ((unsigned)ipref >= fs->fs_ncg * fs->fs_ipg) > ipref = 0; > cg = ino_to_cg(fs, ipref); > /* > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Dec 6 1:54:15 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E998237B401 for ; Fri, 6 Dec 2002 01:54:12 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5C8943ED4 for ; Fri, 6 Dec 2002 01:54:11 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id UAA27255; Fri, 6 Dec 2002 20:53:46 +1100 Date: Fri, 6 Dec 2002 20:53:55 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Julian Elischer Cc: Kirk McKusick , Kris Kennaway , Robert Watson , Subject: Re: panic: ffs_vfree: range: dev = ad4s1c, ino = -1690809896, fs = /mnt2 In-Reply-To: Message-ID: <20021206201556.B8366-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 5 Dec 2002, Julian Elischer wrote: > This is one of the reasons that I think such fields should all be > defined as unsigned to start with.. This is actually an example of why naive conversion to use unsigned is usually wrong. The bug seems to have nothing to do with signedness, except for a bug in the debugging message. > > Well it is not at all clear how the dirpref routine came up with > > such an out of whack inode preference (2604157400 when the filesystem > > has only 3538944 inodes), but the following fix should catch it and > > make it harmless. I have submitted the patch to release engineering. > > > > Kirk McKusick > > > > =-=-=-=-= > > > > Index: ffs_alloc.c > > =================================================================== > > RCS file: /usr/ncvs/src/sys/ufs/ffs/ffs_alloc.c,v > > retrieving revision 1.102 > > diff -c -r1.102 ffs_alloc.c > > *** ffs_alloc.c 2002/09/19 03:55:30 1.102 > > --- ffs_alloc.c 2002/12/06 01:15:50 > > *************** > > *** 841,847 **** > > ipref = ffs_dirpref(pip); > > else > > ipref = pip->i_number; > > ! if (ipref >= fs->fs_ncg * fs->fs_ipg) > > ipref = 0; > > cg = ino_to_cg(fs, ipref); > > /* > > --- 841,847 ---- > > ipref = ffs_dirpref(pip); > > else > > ipref = pip->i_number; > > ! if ((unsigned)ipref >= fs->fs_ncg * fs->fs_ipg) > > ipref = 0; > > cg = ino_to_cg(fs, ipref); > > /* > > This change has no effect on any supported system, since `ipref' is already an unsigned type (ino_t == uint32_t), which is in fact identical with unsigned on all supported systems. The analysis is slightly more complicated on exotic systems. Many things are broken on systems with ints smaller than 32 bits, and the change increases the breakage by clipping the LHS (if the filesystem has more than UINT_MAX inodes). The change causes at most slightly different signed-versus unsigned comparision warnings on systems with ints larger than 32 bits. The RHS multiplies 2 int32_t's and the multiplication may in theory overflow, but newfs presumably won't create filesystems for which it overflows (ones with more than 2^31-1 inodes), so there should be no signedness problems in practice. Related cosmetic bugs: (1) `unsigned' is not correctly misspelled u_int. (2) the original panic message has a wrong function name and a wrong printf format for printing ino_t's. Te following patch fixes (2) and a nearby non-misspelling of `unsigned' (the only other one in ffs_alloc.c). %%% Index: ffs_alloc.c =================================================================== RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_alloc.c,v retrieving revision 1.103 diff -u -2 -r1.103 ffs_alloc.c --- ffs_alloc.c 6 Dec 2002 02:08:46 -0000 1.103 +++ ffs_alloc.c 6 Dec 2002 09:13:26 -0000 @@ -1649,5 +1683,5 @@ */ static int -ffs_isfreeblock(struct fs *fs, unsigned char *cp, ufs1_daddr_t h) +ffs_isfreeblock(struct fs *fs, u_char *cp, ufs1_daddr_t h) { @@ -1897,6 +1931,6 @@ } if ((u_int)ino >= fs->fs_ipg * fs->fs_ncg) - panic("ffs_vfree: range: dev = %s, ino = %d, fs = %s", - devtoname(dev), ino, fs->fs_fsmnt); + panic("ffs_freefile: range: dev = %s, ino = %lu, fs = %s", + devtoname(dev), (u_long)ino, fs->fs_fsmnt); if ((error = bread(devvp, cgbno, (int)fs->fs_cgsize, NOCRED, &bp))) { brelse(bp); @@ -1916,5 +1950,5 @@ (u_long)ino + cg * fs->fs_ipg, fs->fs_fsmnt); if (fs->fs_ronly == 0) - panic("ffs_vfree: freeing free inode"); + panic("ffs_freefile: freeing free inode"); } clrbit(inosused, ino); %%% Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Dec 6 15:59:42 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD33E37B401 for ; Fri, 6 Dec 2002 15:59:40 -0800 (PST) Received: from smtp02.iprimus.net.au (smtp02.iprimus.net.au [210.50.76.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F7A943EA9 for ; Fri, 6 Dec 2002 15:59:39 -0800 (PST) (envelope-from tim@robbins.dropbear.id.au) Received: from dilbert.robbins.dropbear.id.au ([210.50.218.27]) by smtp02.iprimus.net.au with Microsoft SMTPSVC(5.0.2195.5600); Sat, 7 Dec 2002 10:59:26 +1100 Received: from dilbert.robbins.dropbear.id.au (vac8o01zm78abzs3@localhost [127.0.0.1]) by dilbert.robbins.dropbear.id.au (8.12.6/8.12.6) with ESMTP id gB6NxPWo057534; Sat, 7 Dec 2002 10:59:25 +1100 (EST) (envelope-from tim@dilbert.robbins.dropbear.id.au) Received: (from tim@localhost) by dilbert.robbins.dropbear.id.au (8.12.6/8.12.6/Submit) id gB6NxNUh057533; Sat, 7 Dec 2002 10:59:23 +1100 (EST) (envelope-from tim) Date: Sat, 7 Dec 2002 10:59:23 +1100 From: Tim Robbins To: Ian Dowse Cc: freebsd-fs@FreeBSD.ORG Subject: Re: vflush() and dependencies between vnodes Message-ID: <20021207105923.A57199@dilbert.robbins.dropbear.id.au> References: <20021205131858.A54625@dilbert.robbins.dropbear.id.au> <200212051022.aa49886@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200212051022.aa49886@salmon.maths.tcd.ie>; from iedowse@maths.tcd.ie on Thu, Dec 05, 2002 at 10:22:34AM +0000 X-OriginalArrivalTime: 06 Dec 2002 23:59:27.0610 (UTC) FILETIME=[82892DA0:01C29D83] Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Dec 05, 2002 at 10:22:34AM +0000, Ian Dowse wrote: > In message <20021205131858.A54625@dilbert.robbins.dropbear.id.au>, Tim Robbins > writes: > >I've spent the past couple of days tracking down the bug that caused > >umount -f on smbfs to panic, and umount without -f to often give EBUSY > >when it should not have. > > > >smbfs stores a pointer to each file or directory's parent directory in > >the smbnode struct and vref()'s the parent directory's vnode. This means > >that an smbfs directory vnode cannot be removed before all of its > >children have vrele()'d it. However, vflush() iterates through the > >mount's vnode list from start to end, so if a directory vnode appears > >in the list before its children, it will not be removed. This causes a > >panic when umount -f is used because smbfs_reclaim() calls vrele() on the > >parent vnode after it has already been freed. This also causes umount > >without -f to erroneously return EBUSY. > > >Can anyone think of a better way to solve this problem than to keep > >rescanning the mount's vnode list until no more vnodes can be freed, > >like the patch below does? > > I think for the non-forced case, an approach like this is quite a > reasonable solution to avoid the EBUSY errors. For the forced case > it shouldn't be necessary though - vnodes are not freed until the > last reference is dropped, so even if a referenced vnode gets killed > before the vnode that references it, calling vrele() on the original > vnode should do the right thing and be safe. True, there's no need to rescan the mount's vnode list when it's been forcibly unmounted. All of the "lastpass" logic can probably be removed, then. And you're right, it is safe to vrele() the original vnode. The problem with smbfs is that it stores a pointer to the parent's "smbnode" structure inside its own, but the parent's smbnode is freed when the parent is reclaimed. It ends up accessing data that has already been freed since the parent's vnode is stored inside its smbnode. The solution seems to be to store a pointer to the parent's vnode inside the childrens' struct smbnodes. Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Dec 6 17: 9:23 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2678037B401 for ; Fri, 6 Dec 2002 17:09:22 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 986A043EC5 for ; Fri, 6 Dec 2002 17:09:21 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.6/8.12.5) with SMTP id gB719EBF003354; Fri, 6 Dec 2002 20:09:14 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 6 Dec 2002 20:09:14 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: "David E. Cross" Cc: freebsd-fs@freebsd.org Subject: Re: openafs question In-Reply-To: <200211281128.gASBS2g04424@monica.cs.rpi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 28 Nov 2002, David E. Cross wrote: > I've been working on the FreeBSD-OpenAFS port, and I seem to be down to > one last bug; I know what it is, I am just having trouble getting the > solution to it. Darwin appears to use a VSTANDARD flag to identify vnodes managed by the system vnode pool. vfree() on Darwin notices non-standard vnodes, and simply returns. I haven't read the OpenAFS code in ages -- certainly not since it gained Darwin support, so I don't know how exactly it handles determining it has been reclaimed (perhaps this happens as part of its VOP_INACTIVE() code, although they'd have to be careful about races there). We might be able to play much the same trick, although you'd want to do it very carefully so as to maintain the same locking invariants as standard vnodes, etc. Presumably changing to a model that doesn't involve non-standard vnode handling would involve extensive changes to OpenAFS? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Dec 6 17:11:27 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BD0837B406 for ; Fri, 6 Dec 2002 17:11:26 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7DD843EA9 for ; Fri, 6 Dec 2002 17:11:25 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.6/8.12.5) with SMTP id gB71BEBF003661; Fri, 6 Dec 2002 20:11:15 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 6 Dec 2002 20:11:14 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: "David E. Cross" Cc: fs@freebsd.org Subject: Re: AFS nastiest hack ever question In-Reply-To: <200211291011.gATABpU07028@monica.cs.rpi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 29 Nov 2002, David E. Cross wrote: > Just when I thought I was done ;) > > Ok.. Quick summary. "afs_symlink" will panic the kernel. The problem > is that the symlink syscall expects VOP_SYSCALL to fill in the "vpp" > with the vnode of the newly created symlink. AFS doesn't do this, ever, > it, internally creates its private vnode, and then calls its own "vput" > on it, immediately claiming it back to the system (which is good in some > ways since afs vnodes don't play nice with system vnodes). To "fix" > this I would need to significantly modify AFS's code. Or... what I have > done is to : If OpenAFS has its own vnode handling for the reclaim of the vnode by the OS when its reference count drops to 0, it should be able to handle the consumer of VOP_SYMLINK() returning the reference just fine. This would be no different than the consumer of namei() returning the vnode when it isn't needed. I'd probably just #if 0 the vput in the OpenAFS code. As you observe, our VFS assumes that you do return the vnode so that you can perform race-free operations on the symlink, for better or for worse... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message