Re: Re: [RFC PATCH] mm/hugetlb: fix resv_map memory leak in __mmap_region error path

[王明煜]

Hi Muchun and David,

Thanks a lot for taking the time to review!

> At least for me, it is not good name to distinguish it from error_hook.
> abort_mmap_prepare? I am not sure if it is a good solution, Cc other
> MM maintainers as well.

I completely agree. `abort_mmap_prepare` is indeed much clearer and more specific to its purpose. I will update the naming in the v2 patch.

> Please use ./scripts/get_maintainer.pl to get full mail list for Cc/To since
> it is not only related to HugeTLB subsystem.

I apologize for the missing CCs. I did generate the full list using `get_maintainer.pl`, but the SMTP server of Xidian University drops emails with too many foreign recipients due to strict anti-spam policies. I had to heavily trim the CC list just to get the RFC patch delivered. I will try to use an alternative email or chunk the CCs to ensure all relevant authors are included in the next version.

I will hold off on sending the v2 patch until Lorenzo shares his thoughts on whether this architectural approach is the right way to go.

Best regards,
Mingyu


> -----原始邮件-----
> 发件人: "David Hildenbrand (Arm)" <david@xxxxxxxxxx>
> 发送时间:2026-04-27 16:17:23 (星期一)
> 收件人: "Muchun Song" <muchun.song@xxxxxxxxx>, "Mingyu Wang" <25181214217@xxxxxxxxxxxxxxxxx>
> 抄送: Liam.Howlett@xxxxxxxxxx, akpm@xxxxxxxxxxxxxxxxxxxx, linux-mm@xxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, ljs@xxxxxxxxxx, vbabka@xxxxxxxxxx, jannh@xxxxxxxxxx, pfalcato@xxxxxxx, osalvador@xxxxxxx
> 主题: Re: [RFC PATCH] mm/hugetlb: fix resv_map memory leak in __mmap_region error path
> 
> 
> >> 	/*
> >> 	 * We cannot permit the rmap finding this VMA in the time
> >> 	 * between the VMA being inserted into the VMA tree and the
> >> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> >> index a308e2c23b82..9320f6699fa9 100644
> >> --- a/include/linux/mm_types.h
> >> +++ b/include/linux/mm_types.h
> >> @@ -861,6 +861,8 @@ struct mmap_action {
> >> * it is not valid to clear the error here.
> >> */
> >> 	int (*error_hook)(int err);
> >> + 
> >> + 	void (*abort_hook)(struct vm_area_desc *desc);
> > 
> > At least for me, it is not good name to distinguish it from error_hook.
> > abort_mmap_prepare? I am not sure if it is a good solution, Cc other
> > MM maintainers as well.
> >
> 
> I'm sure Lorenzo will provide feedback here :)
> 
> -- 
> Cheers,
> 
> David