Date: Mon, 14 Aug 2000 21:20:04 -0700 (PDT) From: Tor.Egge@fast.no To: freebsd-bugs@FreeBSD.org Subject: Re: kern/20609: panic: vm_fault: fault on nofault entry, addr: cc4b3000 Message-ID: <200008150420.VAA59345@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/20609; it has been noted by GNATS.
From: Tor.Egge@fast.no
To: tegge@not.trondheim.fast.no
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/20609: panic: vm_fault: fault on nofault entry, addr: cc4b3000
Date: Tue, 15 Aug 2000 06:12:03 +0200
defining buffer_map as a system map is not sufficient.
It's still possible to get a Fatal trap 12: page fault while in kernel mode.
dump of kernel_map's vm map entries:
[...]
map c031844c entry d6050990 start dcf25000 end dcf26000
map c031844c entry d6053a20 start dcf26000 end dcf27000
map c031844c entry d604e300 start ce7e6000 end dcf27000
^^^^^^^^ bogus
map c031844c entry d6054b40 start dcf27000 end dcf28000
map c031844c entry d6056d80 start dcf28000 end dcf29000
map c031844c entry d60550c0 start dcf29000 end dcf2a000
map c031844c entry d604a750 start dcf2a000 end dcf2b000
map c031844c entry d6054150 start dcf2b000 end dcf2c000
map c031844c entry d6055150 start dcf2c000 end dcf2d000
map c031844c entry d6054870 start dcf2d000 end dcf2e000
map c031844c entry d604fa50 start dcf2e000 end dcf2f000
map c031844c entry d6051180 start dcf2f000 end dcf30000
map c031844c entry d6050930 start dcf30000 end dcf31000
map c031844c entry d60561b0 start dcf31000 end dcf32000
map c031844c entry d604f540 start ce96e000 end dcf33000
^^^^^^^^ bogus
map c031844c entry d6053210 start dcf33000 end dcf34000
The bogus start addresses are locations inside buffer_map.
This indicates yet another race condition.
vm_map_entry_create should probably use zalloci when allocating elements
from kmapentzone. Otherwise, a malloc() call inside an interrupt could
cause inconsistent allocation of vm_map_entries from kmapentzone.
Since these problem occur on an SMP machine, another race condition
is also present. By forcing a panic when multiple processes were
manipulating buffer_map at the same time, I found the following
stack trace:
#0 mi_switch () at machine/globals.h:119
#1 0xc016cca9 in tsleep (ident=0xc033c398, priority=4,
wmesg=0xc02d032b "vmwait", timo=0) at ../../kern/kern_synch.c:470
#2 0xc025fa8f in vm_wait () at ../../vm/vm_page.c:896
#3 0xc0260249 in vm_page_grab (object=0xc03185e0, pindex=118761,
allocflags=131) at ../../vm/vm_page.c:1479
#4 0xc0258ee5 in kmem_alloc (map=0xc031854c, size=4096)
at ../../vm/vm_kern.c:200
#5 0xc0262ffe in _zget (z=0xc03186c0) at ../../vm/vm_zone.c:344
#6 0xc0262e71 in zalloci (z=0xc03186c0) at ../../vm/vm_zone.h:85
#7 0xc025d84b in vm_object_allocate (type=0, size=32)
at ../../vm/vm_object.c:224
#8 0xc0259e88 in _vm_map_clip_end (map=0xc0318408, entry=0xd604ede0,
end=3460128768) at ../../vm/vm_map.c:848
#9 0xc025afaf in vm_map_delete (map=0xc0318408, start=3460096000,
end=3460128768) at ../../vm/vm_map.c:1799
#10 0xc0192fea in bfreekva (bp=0xcb5c2380) at ../../kern/vfs_bio.c:422
#11 0xc01946ba in getnewbuf (slpflag=0, slptimeo=0, size=32768, maxsize=32768)
at ../../kern/vfs_bio.c:1639
#12 0xc0195485 in getblk (vp=0xdca96180, blkno=151606, size=32768, slpflag=0,
slptimeo=0) at ../../kern/vfs_bio.c:2236
#13 0xc01974aa in cluster_read (vp=0xdca96180, filesize=5242880000,
lblkno=151606, size=32768, cred=0x0, totread=29696, seqcount=0,
bpp=0xdcb05e44) at ../../kern/vfs_cluster.c:120
#14 0xc024cf3a in ffs_read (ap=0xdcb05e68) at ../../ufs/ufs/ufs_readwrite.c:266
#15 0xc01a32d8 in vn_read (fp=0xc3699c00, uio=0xdcb05ed8, cred=0xc3656700,
flags=1, p=0xd7b3d1e0) at vnode_if.h:334
#16 0xc017b594 in dofileread (p=0xd7b3d1e0, fp=0xc3699c00, fd=3,
buf=0x814e400, nbyte=512, offset=4967854592, flags=1)
at ../../sys/file.h:141
#17 0xc017b4d4 in pread (p=0xd7b3d1e0, uap=0xdcb05f80)
at ../../kern/sys_generic.c:136
#18 0xc028ae35 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 512, tf_esi = 1, tf_ebp = -1090519644, tf_isp = -592420908,
tf_ebx = 1498383852, tf_edx = 1, tf_ecx = 134520321, tf_eax = 198,
tf_trapno = 7, tf_err = 2, tf_eip = 1498088260, tf_cs = 31,
tf_eflags = 514, tf_esp = -1090519704, tf_ss = 47})
at ../../i386/i386/trap.c:1174
#19 0xc027612b in Xint0x80_syscall ()
Blocking, waiting for an object to be available, will cause an inconsistent
buffer map.
using lockmgr calls (i.e. Alternative 1 in previous message) might
cause deadlock problems if the thread holding the buffer_map lock
blocks waiting for memory to be freed while the pager blocks waiting
for a buffer to be available.
Perhaps various vm_map operations need to check a flag in the vm map
and avoid allocating vm objects for some maps, e.g. buffer_map.
- Tor Egge
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008150420.VAA59345>