From: Lorenzo Stoakes <lstoakes@gmail.com>
To: Baoquan He <bhe@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
urezki@gmail.com, stephen.s.brennan@oracle.com,
willy@infradead.org, akpm@linux-foundation.org,
hch@infradead.org
Subject: Re: [PATCH v2 2/7] mm/vmalloc.c: add flags to mark vm_map_ram area
Date: Sat, 17 Dec 2022 11:44:22 +0000 [thread overview]
Message-ID: <Y52rllbXHMwbpJ8K@lucifer> (raw)
In-Reply-To: <20221217015435.73889-3-bhe@redhat.com>
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?
next prev parent reply other threads:[~2022-12-17 11:44 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-17 1:54 [PATCH v2 0/7] mm/vmalloc.c: allow vread() to read out vm_map_ram areas Baoquan He
2022-12-17 1:54 ` [PATCH v2 1/7] mm/vmalloc.c: add used_map into vmap_block to track space of vmap_block Baoquan He
2022-12-17 1:54 ` [PATCH v2 2/7] mm/vmalloc.c: add flags to mark vm_map_ram area Baoquan He
2022-12-17 11:44 ` Lorenzo Stoakes [this message]
2022-12-19 8:01 ` Baoquan He
2022-12-19 9:09 ` Lorenzo Stoakes
2022-12-19 12:24 ` Baoquan He
2022-12-19 13:01 ` Lorenzo Stoakes
2022-12-20 12:14 ` Baoquan He
2022-12-20 12:42 ` Lorenzo Stoakes
2022-12-20 16:55 ` Uladzislau Rezki
2022-12-23 4:14 ` Baoquan He
2023-01-13 3:55 ` Baoquan He
2023-01-16 17:54 ` Uladzislau Rezki
2023-01-18 3:09 ` Baoquan He
2023-01-18 12:20 ` Uladzislau Rezki
2022-12-17 1:54 ` [PATCH v2 3/7] mm/vmalloc.c: allow vread() to read out vm_map_ram areas Baoquan He
2022-12-17 4:10 ` kernel test robot
2022-12-17 6:41 ` kernel test robot
2022-12-17 9:46 ` Baoquan He
2022-12-17 12:06 ` Lorenzo Stoakes
2023-01-04 8:01 ` Baoquan He
2023-01-04 20:20 ` Lorenzo Stoakes
2023-01-09 4:35 ` Baoquan He
2023-01-09 7:12 ` Lorenzo Stoakes
2023-01-09 12:49 ` Baoquan He
2022-12-17 1:54 ` [PATCH v2 4/7] mm/vmalloc: explicitly identify vm_map_ram area when shown in /proc/vmcoreinfo Baoquan He
2022-12-17 1:54 ` [PATCH v2 5/7] mm/vmalloc: skip the uninitilized vmalloc areas Baoquan He
2022-12-17 12:07 ` Lorenzo Stoakes
2022-12-19 7:16 ` Baoquan He
2022-12-17 1:54 ` [PATCH v2 6/7] powerpc: mm: add VM_IOREMAP flag to the vmalloc area Baoquan He
2022-12-17 1:54 ` Baoquan He
2022-12-17 1:54 ` [PATCH v2 7/7] sh: mm: set " Baoquan He
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y52rllbXHMwbpJ8K@lucifer \
--to=lstoakes@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=stephen.s.brennan@oracle.com \
--cc=urezki@gmail.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.