On Tuesday 27 July 2004 06:51 pm, Robert Watson wrote: > 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 _at_ > > /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? The preemption case is very easy to test, just turn it off in machine/param.h and see if it goes away. -- John Baldwin <jhb_at_FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.orgReceived on Wed Jul 28 2004 - 02:27:33 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:03 UTC