Date: Tue, 7 Nov 2000 23:09:00 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Matt Dillon <dillon@earth.backplane.com> Cc: Kirk McKusick <mckusick@mckusick.com>, arch@FreeBSD.ORG Subject: Re: softdep panic due to blocked malloc (with traceback) Message-ID: <Pine.BSF.4.21.0011072254370.3075-100000@besplex.bde.org> In-Reply-To: <200011070246.eA72kF271154@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 6 Nov 2000, Matt Dillon wrote:
> This occured during low-memory deadlock testing:
>
> -Matt
>
> (pageout daemon)
>
> A blocked malloc in the pageout daemon with a softdep lock
> held:
>
> #2 0xc0238f93 in vm_wait () at ../../vm/vm_page.c:891
> #3 0xc0232d58 in kmem_malloc (map=0xc02db6a0, size=16384, flags=0)
> at ../../vm/vm_kern.c:361
> #4 0xc015bb47 in malloc (size=16384, type=0xc02c0c20, flags=0)
> at ../../kern/kern_malloc.c:188
> #5 0xc0223321 in softdep_disk_io_initiation (bp=0xcf379220)
> at ../../ufs/ffs/ffs_softdep.c:2807
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ here
> #6 0xc01964c3 in spec_strategy (ap=0xdca8fbdc)
> at ../../miscfs/specfs/spec_vnops.c:412
> #7 0xc0195fe1 in spec_vnoperate (ap=0xdca8fbdc)
> at ../../miscfs/specfs/spec_vnops.c:117
> #8 0xc022f31d in ufs_vnoperatespec (ap=0xdca8fbdc)
> at ../../ufs/ufs/ufs_vnops.c:2303
> #9 0xc022ed55 in ufs_strategy (ap=0xdca8fc20) at vnode_if.h:923
> #10 0xc022f2ed in ufs_vnoperate (ap=0xdca8fc20)
> at ../../ufs/ufs/ufs_vnops.c:2285
> #11 0xc018369f in bwrite (bp=0xcf379220) at vnode_if.h:923
> #12 0xc021f3e3 in ffs_balloc (ap=0xdca8fd40) at ../../ufs/ffs/ffs_balloc.c:316
> #13 0xc0228119 in ffs_write (ap=0xdca8fd90) at vnode_if.h:1035
> #14 0xc023d3fb in vnode_pager_generic_putpages (vp=0xe191fd80, m=0xdca8fea0,
>
>
> Caused a panic to occur here in the update daemon:
>
> #10 0xc0220429 in acquire_lock (lk=0xc02c0f5c)
> at ../../ufs/ffs/ffs_softdep.c:262
> #11 0xc02207a6 in softdep_process_worklist (matchmnt=0x0)
> at ../../ufs/ffs/ffs_softdep.c:546
> #12 0xc018b26b in sched_sync () at ../../kern/vfs_subr.c:1034
> #13 0xc02542a0 in fork_trampoline ()
> cannot read proc at 0
> (kgdb) frame 10
> #10 0xc0220429 in acquire_lock (lk=0xc02c0f5c)
> at ../../ufs/ffs/ffs_softdep.c:262
> 262 panic("softdep_lock: lock held by %d", lk->lkt_held);
> (kgdb)
This is fixed in -current:
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_softdep.c,v
Working file: ffs_softdep.c
head: 1.74
...
----------------------------
revision 1.73
date: 2000/09/07 23:02:55; author: mckusick; state: Exp; lines: +3 -3
Cannot do MALLOC with M_WAITOK while holding ACQUIRE_LOCK
Obtained from: Ethan Solomita <ethan@geocast.com>
----------------------------
... but I don't see how using malloc() in low-level i/o routines can be
safe in general. Deadlock seems to be possible if completion of output
is necessary to free some pages. Deadlock just usually doesn't occur,
because the system attempts to reserve enough free pages to satisfy
low-level memory allocations.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0011072254370.3075-100000>