On Fri, 8 May 2015, Dave Hansen wrote: > The comment pretty much says it all. > > I wrote a test program that does lots of random allocations > and forces bounds tables to be created. It came up with a > layout like this: > > .... | BOUNDS DIRECTORY ENTRY COVERS | .... > | BOUNDS TABLE COVERS | > | BOUNDS TABLE | REAL ALLOC | BOUNDS TABLE | > > Unmapping "REAL ALLOC" should have been able to free the > bounds table "covering" the "REAL ALLOC" because it was the > last real user. But, the neighboring VMA bounds tables were > found, considered as real neighbors, and we declined to free > the bounds table covering the area. > > Doing this over and over left a small but significant number > of these orphans. Handling them is fairly straighforward. > All we have to do is walk the VMAs and skip all of the MPX > ones when looking for neighbors. > > Signed-off-by: Dave Hansen <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
