Date: Wed, 28 Jun 2000 21:30:02 -0700 (PDT) From: Gregory Bond <gnb@itga.com.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/19553: "panic: zone: entry not free" in namei Message-ID: <200006290430.VAA70933@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/19553; it has been noted by GNATS. From: Gregory Bond <gnb@itga.com.au> To: Bruce Evans <bde@zeta.org.au> Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/19553: "panic: zone: entry not free" in namei Date: Thu, 29 Jun 2000 14:27:11 +1000 Actually, thinking about it some more the whole concept of invariants in the zone allocator is currently busted, because it relies on the fact that memory returned to zfree() will not have a certain bit pattern in the second longword. There is no way to guarantee that in general. About all you can usefully do is mark stuff as it goes on the free list and check it as it comes off, which will find some problems with the zone internal freelist mgmt, plus I guess find a fairly small proportion of use-after-zfree() problems (where the subsequent use changes the second longword). But you can't reliably find zfree()-after-zfree() or failure-to-zfree() or zfree()-to-the- wrong-zone or zfree()-after-malloc() or or or or.... So perhaps we orta either ditch the invariants in vm_zone.[ch] altogether. Or change the zone implementation to use a hidden longword at the start of each zalloc'd chunk. This longword would either be the next free entry (for free chunks) or a pointer to the owning vm_zone object (for allocated chunks). The downside here is of course size - a couple hundred K of kernel memory on my fairly unloaded system (I have ~30k zone chunks active according to "sysctl vm.zone"). If people think this is reasonable, I can put something together, but I suspect the cost is too high. Greg. 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?200006290430.VAA70933>