softdep panic while low on memory during "make buildworld"

Nicolas Thery nthery at
Sat Jan 26 02:33:50 PST 2008

2008/1/26, Matthew Dillon <dillon at>:
> :I have 2G of RAM, and I'm able to reproduce this if I really stress the
> :machine.  I've turned off softupdates since this was killing my
> :productivity.
>     Could you try to get a kernel core?  Maybe there's something else going
>     on here that can be easily tracked down.  I don't recall softupdates
>     causing this panic in the past.  Maybe I broke something when I
>     augmented the biodeps code.

I noticed that bp->b_dep is an empty list.  So it looks like there are
no dangling dependencies when buf_deallocate() is called.

I also noticed that bp->b_ops is set by hammerfs and ffs but never
reset to NULL.  So maybe the faulty buffer had initially some
dependencies that were resolved and the buffer was later on recycled
for another operation without dependency.

WARNING: I've got a very limited knowledge of softupdates, so don't
try the following!
To check this hypothesis, I applied the following crude patch and I'm
rebuilding world right now on my 64mb machine:

Index: src2/sys/vfs/ufs/ffs_softdep.c
--- src2.orig/sys/vfs/ufs/ffs_softdep.c	2008-01-05 15:02:41.000000000 +0100
+++ src2/sys/vfs/ufs/ffs_softdep.c	2008-01-22 13:51:29.000000000 +0100
@@ -5137,6 +5137,10 @@
 static void
 softdep_deallocate_dependencies(struct buf *bp)
+	/* XXX */
+	if (LIST_EMPTY(&bp->b_dep))
+		return;
 	if ((bp->b_flags & B_ERROR) == 0)
 		panic("softdep_deallocate_dependencies: dangling deps");
 	softdep_error(bp->b_vp->v_mount->mnt_stat.f_mntfromname, bp->b_error);

Should that hypothesis proves true, it may be better to reset
bp->b_ops when the last dependency is resolved.

Let's wait for that buildworld to complete or panic ...

More information about the Bugs mailing list