Date: Sun, 27 Sep 1998 07:54:29 +1000 From: Bruce Evans <bde@zeta.org.au> To: Don.Lewis@tsc.tdk.com, freebsd-current@FreeBSD.ORG, street@iname.com Subject: Re: Softupdates panics Message-ID: <199809262154.HAA06071@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>} panic: newdirrem: inum 494166 should be 494160 >} >} syncing disks... panic: softdep_disk_write_complete: lock is held > >Something should probably be done about this double panic. The problem >is that the softupdates code is calling panic() while it has an internal >lock set, and then softupdates is being reentered when the kernel tries to >flush all the dirty buffers. Very little can be done except not call sync() in panic(). sync() in panic() was never guaranteed to work, despite/because of sometimes doing evil things like calling filesystem routiens from interrupt handlers, and now that there are lots of filesystem locks, sync() in a filesystem panic is almost guaranteed to trip over a filesystem lock - the locks are just harder to subvert than spl's. The right way to do it is probably to write out all dirty buffers and associated metadata to a special place on the dump device using a standalone output routine, or just write them out as part of the dump, and use a utility to untangle the mess after rebooting. >I'd be willing to bet that the newdirrem panic is has a similar cause >to the recently fixed initiate_write_filepage panic. That problem was >caused by the softupdates code unlocking a directory at the wrong time >during ufs_create() and allowing a directory slot to be reused. Alas, >ufs_rename() is much more complicated to debug. I believe there are races in xxx_checkpath(). It certainly unlocks, and I've been able to damage the directory structure by simulating a race: arrange for ufs_checkpath() to sleep for a minute or two near the end of the main loop in ufs_checkpath(), and while it is sleeping, manually rearrange the unlocked directory tree in a certain way. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809262154.HAA06071>