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: <20250604222400.63203f9b10ae5b4c25f6de0b@linux-foundation.org>
Date: Wed, 4 Jun 2025 22:24:00 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Hyesoo Yu <hyesoo.yu@...sung.com>
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 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.