[PATCH v3 1/3] mm/hugetlb: Make hugetlb_reserve_pages() return nr of entries updated

[Kasireddy, Vivek]

Hi Andrew,

> Subject: Re: [PATCH v3 1/3] mm/hugetlb: Make hugetlb_reserve_pages()
> return nr of entries updated
> 
> On Tue, 20 May 2025 22:19:35 -0700 Vivek Kasireddy
> <vivek.kasireddy at intel.com> wrote:
> 
> > Currently, hugetlb_reserve_pages() returns a bool to indicate whether
> > the reservation map update for the range [from, to] was successful or
> > not. This is not sufficient for the case where the caller needs to
> > determine how many entries were updated for the range.
> >
> > Therefore, have hugetlb_reserve_pages() return the number of entries
> > updated in the reservation map associated with the range [from, to].
> > Also, update the callers of hugetlb_reserve_pages() to handle the new
> > return value.
> 
> Everyone has forgotten, so please refresh, retest and resend after
> -rc1?
Sure, will do.

> 
> Also, patch [2/3] addresses a BUG which was introduced into 6.12.
> Presumably we want to backport the fix into -stable?  If so, it's
> better to present this as a standalone patch, including the cc:stable
> tag.  This is because I'd be looking to fast-track the fix into the
> 6.16-rcX cycle whereas less urgent things would be routed into
> 6.17-rc1.
Unless I merge patches #1 and #2, I don't think I can come up with a
standalone fix to address the BUG. So, I don't mind having this short
series deferred until 6.17-rc1.

> 
> Also, [2/3] has
> 
> 	Reported-by:
> syzbot+a504cb5bae4fe117ba94 at syzkaller.appspotmail.com
> 
> which is kind of annoying if one wishes to see the syzbot report.  OK,
> it takes takes 30 seconds of googling, but adding a Closes: link is
> nice.
Ok, no problem, I'll add the Closes link in the next version.

Thanks,
Vivek