Date: Wed, 27 Mar 2002 19:40:36 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: Alfred Perlstein <bright@mu.org> Cc: jeff@freebsd.org, <hackers@freebsd.org> Subject: Re: uma and double free detection? Message-ID: <20020327193305.D16840-100000@mail.chesapeake.net> In-Reply-To: <20020328002957.GQ93885@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 Mar 2002, Alfred Perlstein wrote: > > Oh! Thanks for pointing this out. Originally it could, but with the per > > cpu buckets it lost the ability to until the data was really freed. What > > I will do is disable per cpu buckets if INVARIANTS is on. The reason for > > this is that you have to lock the zone and look at the slabs to do double > > free detection. > > That's really not a good idea, how is one supposed to debug problems > with the per-cpu stuff if INVARIANTS disables them? > > Why don't you look at how the old malloc(9) did it, it will show you > how to do it with minimum performance impact (i think). > > -Alfred > Given the structure of UMA it is much more complicated than the original malloc. No matter how you do it you'll have to grab the zone lock to check for double frees. Which means that the per cpu free lists will have to be drained so that you know the item isn't already in one of those. Which means the operation can not really use the per cpu queues unless you just search them all without really retiring the memory. So I have two options. The first, which I already suggested, and which requires the least code, is to disable per cpu queues. You can have it excercise most of the code paths by just forcing all bucket allocation to fail. Or, the second approach, I can write a significant amount of new code in both the allocation and free routines that is only executed when invariants is on. It would effectively execute all of the code paths in the per cpu queues but you would have to lock the zone to verify an address and then lock each per cpu queue to make sure it does not reoccur. I favor the first solution because it has less risk. What you end up with is the ability to debug UMA or users of UMA, but not both at the same time. I think this is acceptable. Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020327193305.D16840-100000>