Re: [PATCH v2 2/2] mm: gup: avoid CMA page pinning by retrying migration if no migratable page

[Hyesoo Yu <hyesoo.yu@samsung.com>]

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

On Wed, Jun 04, 2025 at 10:24:00PM -0700, Andrew Morton wrote:
> On Thu, 5 Jun 2025 14:11:31 +0900 Hyesoo Yu <hyesoo.yu@samsung.com> wrote:
> 
> > We have confirmed that this regression causes CMA pages to be pinned
> > in our kernel 6.12-based environment.
> > 
> > In addition to CMA allocation failures, we also observed GUP longterm
> > failures in cases where the same VMA was accessed repeatedly.
> > 
> > Specifically, the first GUP longterm call would pin a CMA page, and a second
> > call on the same region would fail the migration due to the cma page already
> > being pinned.
> > 
> > After reverting commit 1aaf8c122918, the issue no longer reproduced.
> > 
> > Therefore, this fix is important to ensure reliable behavior of GUP longterm
> > and CMA-backed memory, and should be backported to stable.
> 
> Great, thanks.  Please add this to the patch's changelog.
> 
> 
> The problem is, this series combines a non-urgent cleanup with an
> important, backportable regression fix.  We shouldn't backport the
> cleanup into earlier kernels - that just adds undesirable noise.
> 
> So can I ask you to prepare a single standalone fix for the regression
> against current -linus and to later propose the cleanup patch for
> 6.17-rc1?
> 
> In other words, pleas reverse the patching order, send the patches
> separately and test the regression fix without the presence of the
> cleanup?
> 
> (I could do these manipulations locally but then what I have for the
> regression fix wasn't standalone tested by yourself).
> 
> Thanks.
> 

Thanks for the clarification. I'll prepare a standalone v3 patch with just the fix,
and send the cleanup separately for 6.17-rc1 as suggested.

Thanks,
Regards.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]