Subject: Re: HEADS UP: merging the newlock2 branch
To: Izumi Tsutsui <>
From: Andrew Doran <>
List: current-users
Date: 02/19/2007 02:41:59

On Fri, Feb 16, 2007 at 10:39:19PM +0900, Izumi Tsutsui wrote:

> wrote:
> > If you run into any problems, please do log them via send-pr.
> Today I got the following panic on macppc:
> ---
> mutex_enter with held simple_lock 0x4e7b74 CPU 0 ../../../../kern/vfs_syscalls.c:645
> 0xd5359c50: at mutex_vector_enter+0x1e0
> 0xd5359c90: at kauth_cred_free+0x24
> 0xd5359cb0: at nfs_reclaim+0x90
> 0xd5359cd0: at VOP_RECLAIM+0x30
> 0xd5359cf0: at vclean+0x10c
> 0xd5359d30: at vgonel+0x3c
> 0xd5359d50: at getcleanvnode+0x134
> 0xd5359da0: at getnewvnode+0xd8
> 0xd5359df0: at vfs_allocate_syncvnode+0x28
> 0xd5359e20: at dounmount+0x408
> 0xd5359e60: at sys_unmount+0x13c
> 0xd5359ee0: at syscall_plain+0x190
> 0xd5359f40: user SC trap #22 by 0xefeaa114: srr1=0xd032
>             r1=0xffffdad0 cr=0x24004042 xer=0 ctr=0xefeaa10c
> Stopped in pid 22884.1 (amd) at netbsd:cpu_Debugger+0x10:       lwz     r0, r1, 0x14

I think the fix here is to sort out the locking in dounmount() - I saw a
similar panic with fstrans recently. I had a go at that, but to be polite
about it, it wasn't easy. :). I'll try a different approach and see if I
can find a way to sort it tomorrow.