On 04/13/2018 05:03 PM, Chintan Pandya wrote: > Client can call vunmap with some intermediate 'addr' > which may not be the start of the VM area. Entire > unmap code works with vm->vm_start which is proper > but debug object API is called with 'addr'. This > could be a problem within debug objects. > > Pass proper start address into debug object API. > > Signed-off-by: Chintan Pandya <cpandya@xxxxxxxxxxxxxx> > --- > mm/vmalloc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 9ff21a1..28034c55 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -1526,8 +1526,8 @@ static void __vunmap(const void *addr, int deallocate_pages) > return; > } > > - debug_check_no_locks_freed(addr, get_vm_area_size(area)); > - debug_check_no_obj_freed(addr, get_vm_area_size(area)); > + debug_check_no_locks_freed(area->addr, get_vm_area_size(area)); > + debug_check_no_obj_freed(area->addr, get_vm_area_size(area)); This kind of makes sense to me but I am not sure. We also have another instance of this inside the function vm_unmap_ram() where we call for debug on locks without even finding the vmap_area first. But it is true that in both these functions the vmap_area gets freed eventually. Hence the entire mapping [va->va_start --> va->va_end] gets unmapped. Sounds like these debug functions should have the entire range as argument. But I am not sure and will seek Michal's input on this.
