Re: kern/52769: Deadlock in ffs?

[Nick Hudson <skrll%netbsd.org@localhost>]

The following reply was made to PR kern/52769; it has been noted by GNATS.

From: Nick Hudson <skrll%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/52769: Deadlock in ffs?
Date: Wed, 29 Nov 2017 12:46:11 +0000

 On 11/28/17 15:00, martin%NetBSD.org@localhost wrote:
 
 > So I dropped into ddb and got:
 > Stopped in pid 0.2 (system) at  netbsd:breakpoint+0x5:  leave
 > db{0}> ps
 > PID    LID S CPU     FLAGS       STRUCT LWP *               NAME WAIT
 > 29181    1 3   0         0   ffffe403e1d3c200             reboot tstile
 > 3481     1 3   0        80   ffffe40368d5e080               tcsh ttyraw
 > 18588    1 3   2   1000000   ffffe4040092db80                cvs biolock
 > 14652    1 3   3        80   ffffe403be513640                 sh wait
 > 13756    1 3   1        80   ffffe40397f5f460          ssh-agent select
 > 7734     1 3   0        80   ffffe4038e491460               tcsh pause
 > 22820    1 3   5   1000000   ffffe403ccf032c0                cvs biolock
 > db{0}> bt /a 0xffffe4040092db80
 > trace: pid 18588 lid 1 at 0xffffe4011e02b920
 > sleepq_block() at netbsd:sleepq_block+0x97
 > cv_timedwait() at netbsd:cv_timedwait+0xa9
 > bbusy() at netbsd:bbusy+0x7b
 > getblk() at netbsd:getblk+0x5a
 > bio_doread() at netbsd:bio_doread+0x1d
 > bread() at netbsd:bread+0x1a
 > ffs_update.part.3() at netbsd:ffs_update.part.3+0x112
 > ffs_truncate() at netbsd:ffs_truncate+0xd91
 > ufs_truncate_retry() at netbsd:ufs_truncate_retry+0x79
 > ufs_inactive() at netbsd:ufs_inactive+0x1ac
 > VOP_INACTIVE() at netbsd:VOP_INACTIVE+0x33
 > vrelel() at netbsd:vrelel+0x168
 > ufs_remove() at netbsd:ufs_remove+0xab
 > VOP_REMOVE() at netbsd:VOP_REMOVE+0x37
 > do_sys_unlinkat.isra.5() at netbsd:do_sys_unlinkat.isra.5+0x1eb
 > syscall() at netbsd:syscall+0x1bc
 > --- syscall (number 10) ---
 > 7a93d4312a7a:
 >
 > and:
 >
 > db{0}> bt /a ffffe403ccf032c0
 > trace: pid 22820 lid 1 at 0xffffe4011de34820
 > sleepq_block() at netbsd:sleepq_block+0x97
 > cv_timedwait() at netbsd:cv_timedwait+0xa9
 > bbusy() at netbsd:bbusy+0x7b
 > getblk() at netbsd:getblk+0x5a
 > bio_doread() at netbsd:bio_doread+0x1d
 > bread() at netbsd:bread+0x1a
 > ffs_alloccg() at netbsd:ffs_alloccg+0xcc
 > ffs_hashalloc() at netbsd:ffs_hashalloc+0x28
 > ffs_alloc() at netbsd:ffs_alloc+0x11e
 > ffs_balloc() at netbsd:ffs_balloc+0x570
 > ufs_mkdir() at netbsd:ufs_mkdir+0x22b
 > VOP_MKDIR() at netbsd:VOP_MKDIR+0x3b
 > do_sys_mkdirat.isra.7.constprop.12() at netbsd:do_sys_mkdirat.isra.7.constprop.1
 > 2+0x167
 > syscall() at netbsd:syscall+0x1bc
 > --- syscall (number 136) ---
 > 78c2024a686a:
 >
 This reminds me of the pool page problem on erlite where not all the 
 memory was
 available as direct map (and therefore PMAP_MAP_POOLPAGEable) meaning that
 in low memory situations the pool wouldn't grow. A direct map page never 
 became
 available.
 
 I fixed this by making all erlite memory available as direct map via xkseg
 
 
 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/mips/mips/pmap_machdep.c.diff?r1=1.20&r2=1.21
 
 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/mips/include/vmparam.h.diff?r1=1.59&r2=1.60
 
 Nick