vm_page_remove() panic

This e-mail was previously posted on freebsd-stable. I recently received a panic in vm_page_remove() which got me looking for similar panics in the past for other people. From this search, I came across a change that was made to fix a similar problem and was quickly reverted afterwards. My system

Re: valgrind on 5.3BETA1

> --- coregrind/vg_proxylwp.c~ Mon Aug 23 15:47:33 2004 > +++ coregrind/vg_proxylwp.c Mon Aug 23 15:48:42 2004 > @@ -596,6 +596,8 @@ > static const vki_kstack_t ss = { .ss_flags = VKI_SS_DISABLE }; > > #if __FreeBSD__ == 5 > + VG_(message)(Vg_UserMsg, "Locking#1 mutex %p/%p", &px->mutex

Re: use after free bugs

Julian Elischer wrote: Ted Unangst wrote: these are results from running Coverity's analysis over Freebsd 4.10 kernel. two improper loops: if_ef.c:566 and atapi-all.c ng_socket.c: possible double free of resp 815 and 870, depending on caller context. is this possible? I'm not seeing it.. Can

Re: use after free bugs

M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> Ted Unangst <[EMAIL PROTECTED]> writes: : aha_isa.c: aha_isa_attach: aha_free free "aha", can't use it : afterwards, lots of examples. aha_free doesn't actually free the aha, it just tears down the dma for the device. So the stur