Date: Tue, 27 Jul 2004 18:51:33 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Willem Jan Withagen <wjw@withagen.nl> Cc: jhb@FreeBSD.ORG Subject: Re: Fatal LOR: PV ENTRY (UMA zone) @ /home2/src/sys/vm/uma_core.c:2033 Message-ID: <Pine.NEB.3.96L.1040727184919.3788J-100000@fledge.watson.org> In-Reply-To: <022801c47429$b8957420$471b3dd4@digiware.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 28 Jul 2004, Willem Jan Withagen wrote: > Running on amd64: > <snip> <unsnip> > And right followed by.... > > panic: lock (sleep mutex) Giant not locked @ /home2/src/sys/kern/vfs_syscalls.c: > 959 > cpuid = 0; > KDB: stack backtrace: > kdb_backtrace() at kdb_backtrace+0x34 > panic() at panic+0x1d2 > witness_unlock() at witness_unlock+0xdd > _mtx_unlock_flags() at _mtx_unlock_flags+0x68 > kern_open() at kern_open+0x128 > open() at open+0x18 > syscall() at syscall+0x330 > Xfast_syscall() at Xfast_syscall+0xa8 > --- syscall (5, FreeBSD ELF64, open), rip = 0x76d75c, rsp = 0x7fffffffe088, rbp > = 0x7fffffffe0c0 --- > KDB: enter: panic > [thread 100316] > Stopped at kdb_enter+0x2e: nop I've seen several reports of "mysterious" panics where Giant isn't held on return from namei() or other points following a name lookup. Kris Kenneway reported this on the package build cluster, for example. I'm wondering if something handling a page fault hit by namei() during a string copy in from user space if resulting in Giant not being held where it should be. In Kris's case, we tried pushing around GIANT_REQUIRED some because I thought maybe the caller wasn't holding Giant when it should, but that turned out not to be it. So maybe we have some sort of preemption/VM/locking issue? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040727184919.3788J-100000>