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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250605065959.GA3678683@tiffany>
Date: Thu, 5 Jun 2025 15:59:59 +0900
From: Hyesoo Yu <hyesoo.yu@...sung.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: janghyuck.kim@...sung.com, zhaoyang.huang@...soc.com,
	jaewon31.kim@...il.com, david@...hat.com, Jason Gunthorpe <jgg@...pe.ca>,
	John Hubbard <jhubbard@...dia.com>, Peter Xu <peterx@...hat.com>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] mm: gup: avoid CMA page pinning by retrying
 migration if no migratable page

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@...sung.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.