On 6/11/25 6:13 AM, David Hildenbrand wrote:
After commit 1aaf8c122918 ("mm: gup: fix infinite loop within __get_longterm_locked") we are able to longterm pin folios that are not supposed to get longterm pinned, simply because they temporarily have the LRU flag cleared (esp. temporarily isolated).
For example, two __get_longterm_locked() callers can race, or __get_longterm_locked() can race with anything else that temporarily isolates folios.
The introducing commit mentions the use case of a driver that uses vm_ops->fault to insert pages allocated through cma_alloc() into the page tables, assuming they can later get longterm pinned. These pages/ folios would never have the LRU flag set and consequently cannot get isolated. There is no known in-tree user making use of that so far, fortunately.
To handle that in the future -- and avoid retrying forever to isolate/migrate them -- we will need a different mechanism for the CMA area *owner* to indicate that it actually already allocated the page and is fine with longterm pinning it. The LRU flag is not suitable for that.
Probably we can lookup the relevant CMA area and query the bitmap; we only have have to care about some races, probably. If already allocated, we could just allow longterm pinning)
Anyhow, let's fix the "must not be longterm pinned" problem first by reverting the original commit.
Really great commit description, I appreciate the time and effort spent summarizing what happened here.
Fixes: 1aaf8c122918 ("mm: gup: fix infinite loop within __get_longterm_locked") Closes: https://lore.kernel.org/all/20250522092755.GA3277597@tiffany/ Reported-by: Hyesoo Yu hyesoo.yu@samsung.com Cc: Stable@vger.kernel.org Cc: Andrew Morton akpm@linux-foundation.org Cc: Jason Gunthorpe jgg@ziepe.ca Cc: Peter Xu peterx@redhat.com Cc: Zhaoyang Huang zhaoyang.huang@unisoc.com Cc: Aijun Sun aijun.sun@unisoc.com Cc: Alistair Popple apopple@nvidia.com Cc: John Hubbard jhubbard@nvidia.com Signed-off-by: David Hildenbrand david@redhat.com
mm/gup.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
I've verified that this is an exact revert of 1aaf8c122918, yes.
Reviewed-by: John Hubbard jhubbard@nvidia.com
thanks,