[PATCH] vmalloc race fix
From: William Lee Irwin III <wli@holomorphy.com> The new vmalloc() semantics from 2.5.32 had a race window. As things stand, the presence of a vm_area in the vmlist protects from allocators other than the owner examining the ptes in that area. This puts an ordering constraint on unmapping, so that allocators are required to unmap areas before removing them from the list or otherwise dropping the lock. Currently, unmap_vm_area() is done outside the lock and after the area is removed, which as we've seen from Felix von Leitner's test is oopsable. The following patch folds calls to unmap_vm_area() into remove_vm_area() to reinstate what are essentially the 2.4.x semantics of vfree(). This renders a number of unmap_vm_area() calls unnecessary (and in fact oopsable since they wipe ptes from later allocations). It's an open question as to whether this is sufficiently performant, but it is the minimally invasive approach. The more performant alternative is to provide the right API hooks to wipe the vmalloc() area clean before removing them from the list, using the ownership of the area to eliminate holding the vmlist_lock for the duration of the unmapping. If it proves to be necessary wli is on standby to implement it.
Showing
Please register or sign in to comment