Re: [PATCH] alloc_tag: Handle incomplete bulk allocations in vm_module_tags_populate

[T.J. Mercier]

On Wed, Apr 9, 2025 at 2:57 PM Kent Overstreet
<kent.overstreet@xxxxxxxxx> wrote:
>
> On Wed, Apr 09, 2025 at 02:51:18PM -0700, T.J. Mercier wrote:
> > On Wed, Apr 9, 2025 at 2:11 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > On Wed, 9 Apr 2025 14:08:48 -0700 Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > > On Wed,  9 Apr 2025 19:54:47 +0000 "T.J. Mercier" <tjmercier@xxxxxxxxxx> wrote:
> > > >
> > > > > alloc_pages_bulk_node may partially succeed and allocate fewer than the
> > > > > requested nr_pages. There are several conditions under which this can
> > > > > occur, but we have encountered the case where CONFIG_PAGE_OWNER is
> > > > > enabled causing all bulk allocations to always fallback to single page
> > > > > allocations due to commit 187ad460b841 ("mm/page_alloc: avoid page
> > > > > allocator recursion with pagesets.lock held").
> > > > >
> > > > > Currently vm_module_tags_populate immediately fails when
> > > > > alloc_pages_bulk_node returns fewer than the requested number of pages.
> > > > > This patch causes vm_module_tags_populate to retry bulk allocations for
> > > > > the remaining memory instead.
> > > >
> > > > Please describe the userspace-visible runtime effects of this change.  In a way
> > > > which permits a user who is experiencing some problem can recognize that this
> > > > patch will address that problem.
> > > >
> > > > ...
> > > >
> > > > Reported-by: Janghyuck Kim <janghyuck.kim@xxxxxxxxxxx>
> > >
> > > A Closes: link will presumably help with the above info.  checkpatch
> > > now warns about the absence of a Closes:
> >
> > Hi Andrew, This was reported on our internal bug tracker so there is
> > no public link I can provide here. If it's better not to add a
> > Reported-by in this case, then I will do that in the future.
>
> In that case perhaps cut and paste the info from your internal bug
> tracker?
>
> Commit messages can include quite a bit more than just a short
> description of the commit, when it's relevant - e.g. I try to include
> the literal log of the oops being fixed when appropriate.
>
> It really helps when looking at things weeks or months later and trying
> to remember "ok, exactly what was that code path I need to watch out
> for?"

Agreed, it would have been better to include this. I think the
modprobe errors I followed up with would be good to append to the
commit message.

Shall I send a v2?