Date: Thu, 27 Sep 2001 13:22:22 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Douglas Swarin <doug@staff.texas.net> Cc: hackers@freebsd.org, tmoestl@gmx.net, bp@freebsd.org Subject: Re: more on Re: Please review: bugfix for vinvalbuf() Message-ID: <200109272022.f8RKMMo22244@earth.backplane.com> References: <20010711003926.B8799@crow.dom2ip.de> <200107110643.f6B6hTB24707@earth.backplane.com> <20010926204333.A15865@staff.texas.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I totally forgot about that one. Your fix looks good, I'll start testing
it.
The bigger picture here is that vinvalbuf() is not typically called
while a vnode is still active. NFS calls it on active vnodes in order
to invalidate the cache when the client detects that the file mtime
has been changed by someone else (ugly ugly ugly). So this sort of
crash can occur if one client is mmap()ing a file another another
client (or the server) writes to the file.
-Matt
:I recently mentioned on freebsd-stable in message
:
: <20010923124824.A16392@staff.texas.net>
:
:a recurring rslock panic which I believe has been caused by the below
:mentioned problem in vinvalbuf(). I have worked up a patch for -STABLE
:(which should also apply to -CURRENT if there have not been major changes
:to this code). The patch is appended to this message for review.
:
:Data from the crash dump revealed the following:
:
:SMP 2 cpus
:IdlePTD 3555328
:initial pcb at 2cf280
:panicstr: rslock: cpu: 0, addr: 0xd7be66ec, lock: 0x00000001
:panic messages:
:---
:panic: rslock: cpu: 0, addr: 0xd7be66ec, lock: 0x00000001
:mp_lock = 00000001; cpuid = 0; lapic.id = 01000000
:boot() called on cpu#0
:
:---
:
:#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:473
:#1 0xc016cf8f in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:313
:#2 0xc016d3a9 in panic (fmt=0xc025bcce "rslock: cpu: %d, addr: 0x%08x, lock: 0x%08x")
: at /usr/src/sys/kern/kern_shutdown.c:581
:#3 0xc025bcce in bsl1 ()
:#4 0xc021eeac in _unlock_things (fs=0xd7a6dec4, dealloc=0)
: at /usr/src/sys/vm/vm_fault.c:147
:#5 0xc021f8c7 in vm_fault (map=0xd7a6bf40, vaddr=673968128, fault_type=1 '\001',
: fault_flags=0) at /usr/src/sys/vm/vm_fault.c:826
:#6 0xc025d016 in trap_pfault (frame=0xd7a6dfa8, usermode=1, eva=673972223)
: at /usr/src/sys/i386/i386/trap.c:829
:#7 0xc025ca8b in trap (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 99049,
: tf_esi = 0, tf_ebp = -1077937884, tf_isp = -676929580, tf_ebx = 48110729,
: tf_edx = 0, tf_ecx = 1835007, tf_eax = 672137216, tf_trapno = 12, tf_err = 4,
: tf_eip = 134517190, tf_cs = 31, tf_eflags = 66070, tf_esp = -1077937940,
: tf_ss = 47})
: at /usr/src/sys/i386/i386/trap.c:359
:#8 0x80491c6 in ?? ()
:#9 0x8048d9e in ?? ()
:#10 0x804a078 in ?? ()
:#11 0x8048b45 in ?? ()
:
:---
:
:A quick review of processes revealed a process stuck in vmopar:
:
:(kgdb) ps
:...
:46479 d7ffc560 d806e000 235886 1 46394 004006 3 tail vmopar c09120c8
:...
:
:which was sleeping in vm_object_page_remove() in vinvalbuf():
:
:(kgdb) btp 46479
: frame 0 at 0xd806fc8c: ebp d806fcb8, eip 0xc0170051 <tsleep+429>: mov 0x141(%ebx),%al
: frame 1 at 0xd806fcb8: ebp d806fce0, eip 0xc02262e8 <vm_object_page_remove+268>: add $0x10,%esp
: frame 2 at 0xd806fce0: ebp d806fd2c, eip 0xc019a667 <vinvalbuf+803>: add $0x10,%esp
: frame 3 at 0xd806fd2c: ebp d806fd60, eip 0xc01d0aa0 <nfs_vinvalbuf+264>: add $0x18,%esp
: frame 4 at 0xd806fd60: ebp d806fe2c, eip 0xc01cf5d8 <nfs_bioread+540>: mov %eax,0xffffff74(%ebp)
: frame 5 at 0xd806fe2c: ebp d806fe44, eip 0xc01f6842 <nfs_read+30>: jmp 0xc01f6849 <nfs_read+37>
: frame 6 at 0xd806fe44: ebp d806fe78, eip 0xc01a22cc <vn_read+280>: mov %eax,0xffffffe8(%ebp)
: frame 7 at 0xd806fe78: ebp d806fef4, eip 0xc017b690 <dofileread+176>: mov %eax,%esi
: frame 8 at 0xd806fef4: ebp d806ff28, eip 0xc017b556 <read+54>: mov %eax,%esi
: frame 9 at 0xd806ff28: ebp d806ffa0, eip 0xc025d745 <syscall2+537>: mov %eax,0xffffffb8(%ebp)
:
:
:The patch is below, against vfs_subr.c 1.249.2.11 2001/09/11
:
:--- vfs_subr.c Tue Sep 11 04:49:53 2001
:+++ vfs_subr.c.new Wed Sep 26 15:23:09 2001
:@@ -721,9 +721,9 @@
: }
: }
:
:- while (vp->v_numoutput > 0) {
:- vp->v_flag |= VBWAIT;
:- tsleep(&vp->v_numoutput, PVM, "vnvlbv", 0);
:+ if (VOP_GETVOBJECT(vp, &object) == 0) {
:+ while (object->paging_in_progress)
:+ vm_object_pip_sleep(object, "vnvlbv");
: }
:
: splx(s);
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200109272022.f8RKMMo22244>