[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y52rllbXHMwbpJ8K@lucifer>
Date: Sat, 17 Dec 2022 11:44:22 +0000
From: Lorenzo Stoakes <lstoakes@...il.com>
To: Baoquan He <bhe@...hat.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, urezki@...il.com,
stephen.s.brennan@...cle.com, willy@...radead.org,
akpm@...ux-foundation.org, hch@...radead.org
Subject: Re: [PATCH v2 2/7] mm/vmalloc.c: add flags to mark vm_map_ram area
On Sat, Dec 17, 2022 at 09:54:30AM +0800, Baoquan He wrote:
> @@ -2229,8 +2236,12 @@ void vm_unmap_ram(const void *mem, unsigned int count)
> return;
> }
>
> - va = find_vmap_area(addr);
> + spin_lock(&vmap_area_lock);
> + va = __find_vmap_area((unsigned long)addr, &vmap_area_root);
> BUG_ON(!va);
> + if (va)
> + va->flags &= ~VMAP_RAM;
> + spin_unlock(&vmap_area_lock);
> debug_check_no_locks_freed((void *)va->va_start,
> (va->va_end - va->va_start));
> free_unmap_vmap_area(va);
Would it be better to perform the BUG_ON() after the lock is released? You
already check if va exists before unmasking so it's safe.
Also, do we want to clear VMAP_BLOCK here?
Powered by blists - more mailing lists