| Message ID | 20230704101942.2819426-1-liushixin2@huawei.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | bootmem: remove the vmemmap pages from kmemleak in free_bootmem_page | expand |
On Tue, Jul 4, 2023 at 5:23 PM Liu Shixin <liushixin2@huawei.com> wrote: > > commit dd0ff4d12dd2 ("bootmem: remove the vmemmap pages from kmemleak in > put_page_bootmem") fix an overlaps existing problem of kmemleak. But the > problem still existed when HAVE_BOOTMEM_INFO_NODE is disabled, because in > this case, free_bootmem_page() will call free_reserved_page() directly. > > Fix the problem by adding kmemleak_free_part() in free_bootmem_page() > when HAVE_BOOTMEM_INFO_NODE is disabled. > > Fixes: f41f2ed43ca5 ("mm: hugetlb: free the vmemmap pages associated with each HugeTLB page") > Signed-off-by: Liu Shixin <liushixin2@huawei.com> Acked-by: Muchun Song <songmuchun@bytedance.com> Thanks.
On Tue, 4 Jul 2023 18:19:42 +0800 Liu Shixin <liushixin2@huawei.com> wrote: > commit dd0ff4d12dd2 ("bootmem: remove the vmemmap pages from kmemleak in > put_page_bootmem") fix an overlaps existing problem of kmemleak. But the > problem still existed when HAVE_BOOTMEM_INFO_NODE is disabled, because in > this case, free_bootmem_page() will call free_reserved_page() directly. So I take it that with CONFIG_HAVE_BOOTMEM_INFO_NODE=n, the issue described in dd0ff4d12dd2 still occurs? That kmemleak reports an error and stops working? So we want a cc:stable on this fix, yes? > Fix the problem by adding kmemleak_free_part() in free_bootmem_page() > when HAVE_BOOTMEM_INFO_NODE is disabled. > > Fixes: f41f2ed43ca5 ("mm: hugetlb: free the vmemmap pages associated with each HugeTLB page") > ...
On 2023/7/5 0:28, Andrew Morton wrote: > On Tue, 4 Jul 2023 18:19:42 +0800 Liu Shixin <liushixin2@huawei.com> wrote: > >> commit dd0ff4d12dd2 ("bootmem: remove the vmemmap pages from kmemleak in >> put_page_bootmem") fix an overlaps existing problem of kmemleak. But the >> problem still existed when HAVE_BOOTMEM_INFO_NODE is disabled, because in >> this case, free_bootmem_page() will call free_reserved_page() directly. > So I take it that with CONFIG_HAVE_BOOTMEM_INFO_NODE=n, the issue > described in dd0ff4d12dd2 still occurs? That kmemleak reports an error > and stops working? Yes, you're right. > > So we want a cc:stable on this fix, yes? Yes. > >> Fix the problem by adding kmemleak_free_part() in free_bootmem_page() >> when HAVE_BOOTMEM_INFO_NODE is disabled. >> >> Fixes: f41f2ed43ca5 ("mm: hugetlb: free the vmemmap pages associated with each HugeTLB page") >> ... > . >
diff --git a/include/linux/bootmem_info.h b/include/linux/bootmem_info.h index cc35d010fa94..e1a3c9c9754c 100644 --- a/include/linux/bootmem_info.h +++ b/include/linux/bootmem_info.h @@ -3,6 +3,7 @@ #define __LINUX_BOOTMEM_INFO_H #include <linux/mm.h> +#include <linux/kmemleak.h> /* * Types for free bootmem stored in page->lru.next. These have to be in @@ -59,6 +60,7 @@ static inline void get_page_bootmem(unsigned long info, struct page *page, static inline void free_bootmem_page(struct page *page) { + kmemleak_free_part(page_to_virt(page), PAGE_SIZE); free_reserved_page(page); } #endif
commit dd0ff4d12dd2 ("bootmem: remove the vmemmap pages from kmemleak in put_page_bootmem") fix an overlaps existing problem of kmemleak. But the problem still existed when HAVE_BOOTMEM_INFO_NODE is disabled, because in this case, free_bootmem_page() will call free_reserved_page() directly. Fix the problem by adding kmemleak_free_part() in free_bootmem_page() when HAVE_BOOTMEM_INFO_NODE is disabled. Fixes: f41f2ed43ca5 ("mm: hugetlb: free the vmemmap pages associated with each HugeTLB page") Signed-off-by: Liu Shixin <liushixin2@huawei.com> --- include/linux/bootmem_info.h | 2 ++ 1 file changed, 2 insertions(+)