From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id BDCE3C5B543 for ; Thu, 5 Jun 2025 08:41:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0435C6B00A4; Thu, 5 Jun 2025 04:41:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F34E26B00A6; Thu, 5 Jun 2025 04:41:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DD63A6B00A7; Thu, 5 Jun 2025 04:41:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B55FB6B00A4 for ; Thu, 5 Jun 2025 04:41:13 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4F6488DFB5 for ; Thu, 5 Jun 2025 08:41:13 +0000 (UTC) X-FDA: 83520702426.17.FF37829 Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by imf10.hostedemail.com (Postfix) with ESMTP id 36721C0007 for ; Thu, 5 Jun 2025 08:41:09 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=EaNAJJZJ; spf=pass (imf10.hostedemail.com: domain of hyesoo.yu@samsung.com designates 203.254.224.25 as permitted sender) smtp.mailfrom=hyesoo.yu@samsung.com; dmarc=pass (policy=none) header.from=samsung.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749112871; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tXa0SEBrPs7d/bo6iM0bCVitHbWYu8Xz1wgs6ZQqUaM=; b=b+KwGNdtgyqMTNnVUFQFnGde2WbzpBXCpSFU+HSfII0vbn+Po8FTQTTX5G2R+Pl0EBvFLh 3dfjZ3fzH2yZcA+SjGOKcX05UWQCBThcqV4K40a9Is5rPB/WWsLRSk+UecdCPm2Ru+F2v8 HUCdogyvakrry0qCRAlou9up77pBrJw= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=EaNAJJZJ; spf=pass (imf10.hostedemail.com: domain of hyesoo.yu@samsung.com designates 203.254.224.25 as permitted sender) smtp.mailfrom=hyesoo.yu@samsung.com; dmarc=pass (policy=none) header.from=samsung.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749112871; a=rsa-sha256; cv=none; b=BbUB/TW98bEqlCIZrsOsrt/wdyjh5mn5Jj1g/dd5Nyx0eoLnCIS7rDJxljAYZ+8uuaiOzr UPkPETRJo3wduVZp9674Ckc1/gBfD/ECvwGtNhTjI5aHDFgbO+z9q4mSooRshjkrGMcjA0 db3i3P1Ly3b8G10R/5KPrDEO195nRD8= Received: from epcas2p1.samsung.com (unknown [182.195.41.53]) by mailout2.samsung.com (KnoxPortal) with ESMTP id 20250605084106epoutp029a067043c8899878ad49836872c448ba~GGOKIKneH1769617696epoutp02d for ; Thu, 5 Jun 2025 08:41:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.samsung.com 20250605084106epoutp029a067043c8899878ad49836872c448ba~GGOKIKneH1769617696epoutp02d DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1749112866; bh=tXa0SEBrPs7d/bo6iM0bCVitHbWYu8Xz1wgs6ZQqUaM=; h=Date:From:To:Subject:In-Reply-To:References:From; b=EaNAJJZJZFUAmzmXFRn4FhfDFAEZXVfJRyHIfpjs4eqBTLj2XngJogS77RMqpDYME TF+hvfcnjAwDw8b1zGctMsxdIJ+ExFblv47lGlZPq/mYf7p+DzYtFfTVBk+CJLlLYc dg3Xddu/bZlZyC6iFgFOKtDrq0B6Sc085CdXB4bw= Received: from epsnrtp04.localdomain (unknown [182.195.42.156]) by epcas2p1.samsung.com (KnoxPortal) with ESMTPS id 20250605084105epcas2p1a8fb18def52d2d110fb7fa381d2ca513~GGOJp1GAS1962519625epcas2p1Q; Thu, 5 Jun 2025 08:41:05 +0000 (GMT) Received: from epcas2p3.samsung.com (unknown [182.195.36.102]) by epsnrtp04.localdomain (Postfix) with ESMTP id 4bCdFs2nRLz6B9m8; Thu, 5 Jun 2025 08:41:05 +0000 (GMT) Received: from epsmtip1.samsung.com (unknown [182.195.34.30]) by epcas2p1.samsung.com (KnoxPortal) with ESMTPA id 20250605084104epcas2p14d92d7acfa2efe7ead9fc8d8b9199cb8~GGOIe7tXd1729517295epcas2p1u; Thu, 5 Jun 2025 08:41:04 +0000 (GMT) Received: from tiffany (unknown [10.229.95.142]) by epsmtip1.samsung.com (KnoxPortal) with ESMTPA id 20250605084104epsmtip1f69b1bf62a3b89e8f0ec6b2de3d5eb6a~GGOIbKI9Q2345923459epsmtip1A; Thu, 5 Jun 2025 08:41:04 +0000 (GMT) Date: Thu, 5 Jun 2025 17:39:16 +0900 From: Hyesoo Yu To: janghyuck.kim@samsung.com, zhaoyang.huang@unisoc.com, jaewon31.kim@gmail.com, david@redhat.com, Andrew Morton , Jason Gunthorpe , John Hubbard , Peter Xu , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/1] mm: gup: avoid CMA page pinning by retrying migration if no migratable page Message-ID: <20250605083916.GA3770753@tiffany> MIME-Version: 1.0 In-Reply-To: <20250605080436.3764686-2-hyesoo.yu@samsung.com> X-CMS-MailID: 20250605084104epcas2p14d92d7acfa2efe7ead9fc8d8b9199cb8 X-Msg-Generator: CA Content-Type: multipart/mixed; boundary="----bfByJ-ZIY6BJv7sVO1BMUP1RgQAR8Q.m4BWNyUsw_2ev9GnZ=_34a75_" X-Sendblock-Type: AUTO_CONFIDENTIAL CMS-TYPE: 102P cpgsPolicy: CPGSC10-234,Y X-CFilter-Loop: Reflected X-CMS-RootMailID: 20250605080628epcas2p24220eeceef2ae38feeee9d2c18515800 References: <20250605080436.3764686-1-hyesoo.yu@samsung.com> <20250605080436.3764686-2-hyesoo.yu@samsung.com> X-Rspamd-Queue-Id: 36721C0007 X-Stat-Signature: grtrejd4xirc3f48wdea4i37ouek4jsb X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1749112869-590174 X-HE-Meta: U2FsdGVkX1/9FGRZGA+8ee95f45negGoUrpXCaomX8lBLb0ggNXIpdlaibU1AlDGRhcX0/SZuhB2lWEsNzdQxgxrpwT+HN3gU9z45p85zOKGzfSaDPddkXfcxXZ9GoY5V/jhT1D2OA6LpKs9ONtIxg7tMNRlQ3bqyMdax6kPPsLZeu3AoK5HPonWKXRT4YUlxSvO/cuVYkM6S55fwPswXmqZWSADwo1KNC+Jbsn1fQS58tEqmuAx/B5DrnDka/79o+e6CMlPmQHJe0oZZVQut+tahIzE/u51gxaD/nIKodbM1H4pEJThPGBs9xn23oWd9o1tW7E8n0oj0evo2z2XhkpCFi6kUNCroFf3GG4U2i+B+Dd1hbH5NdaDqdfZALNk/MNwWVMgCT9cm9F0cq81dKG5KL5rz8Bdge5QBAVqmUuT5/AFZa6RB+6BJkkqNcROmzS7gWHhWnIXPGuzYG3gKCFQkX8Ysx16/ysDcRhXbt/wBn+nxYfaGlpNKwdL0cHk8Pw6xYJarjpfs4lyzidNng55NJlczyDl5Vf5fKMh2zACZl0WTK4mdqMTFYsASI9lhFKiM5QC0TRsGLNp+dzID2xChfYCdX6VsPsYZIlPt9UF9ExsAoKb97ABkWF17PLqKMD58JQsrvhQzh1gIZEnEPPHXq4nkLivLxq1sL/UzXQrJm1zmhX8woeCV5ve5GXpuiWcCr+62KMRqgQircFkQ3bj40MxNkC+jSIQhZLkBiNJaOqa9gwvQPA7C0xC/GtJ4m3KLFP8HR5UI901jzHyXLPrzWnJxUT6q8hvUNrRWRWMGtkdKsWY+D7ULqstGMDWMqR8IQKc6gXDkWrvPfWwkPDIrls8d+RqFh0QWKLLWS+ZUM5uEOpSx5P8me+mxzymVok4lAHW3DS6MMSNK6klSIImpOGW6HS7luqBsxtehmnyMLe9CT8r2+jf90aRz104iTSIqS15Gp8i2ZL5itu 3RlZA3La Lv3Rmgt+18g1wtm/nI0ekcJt6Y0JiV81c2Y0fscMy1QEgHa5ZyBmnbY9KZOGuqZwsgRuns9KP5+HKIddprJ0ymQwmqf5YQ0jqIgjG8DUqJ5UidDz513kEy4lkR4Y6DaDhr2cVuhYljQjNW6nKX+7MTGN2VFF969eQwdpg2XdrOsxnlPKKa4sZVvO+Isd3H6FjiJwSgpyIZSsO7eFa4ZRuzg1ATOln7m7FY9UjU7lNdyXuiYqtrHnwDso1cAkA/T2SJ3kWhqQc75Ce4Ac= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: ------bfByJ-ZIY6BJv7sVO1BMUP1RgQAR8Q.m4BWNyUsw_2ev9GnZ=_34a75_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline On Thu, Jun 05, 2025 at 05:04:31PM +0900, Hyesoo Yu wrote: > Commit 1aaf8c122918 ("mm: gup: fix infinite loop within __get_longterm_locked") > introduced an issue where CMA pages could be pinned by longterm GUP requests. > This occurs when unpinnable pages are detected but the movable_page_list is empty; > the commit would return success without retrying, allowing unpinnable > pages (such as CMA) to become pinned. > > CMA pages may be temporarily off the LRU due to concurrent isolation, > for example when multiple longterm GUP requests are racing and therefore > not appear in movable_page_list. Before commit 1aaf8c, the kernel would > retry migration in such cases, which helped avoid accidental CMA pinning. > > The original intent of the commit was to support longterm GUP on non-LRU > CMA pages in out-of-tree use cases such as pKVM. However, allowing this > can lead to broader CMA pinning issues. > > To avoid this, the logic is restored to return -EAGAIN instead of success > when no folios could be collected but unpinnable pages were found. > This ensures that migration is retried until success, and avoids > inadvertently pinning unpinnable pages. > > Fixes: 1aaf8c122918 ("mm: gup: fix infinite loop within __get_longterm_locked") > Acked-by: David Hildenbrand > Signed-off-by: Hyesoo Yu > > --- > 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 longterm GUP failures > when repeatedly accessing the same VMA. Specifically, the first longterm GUP > call would pin a CMA page, and a second call on the same region > would fail the migration because the cma page was already pinned. > > After reverting commit 1aaf8c122918, the issue no longer reproduced. > > Therefore, this fix is important to ensure reliable behavior of longterm GUP > and CMA-backed memory, and should be backported to stable. > --- > mm/gup.c | 28 ++++++++++++++++++++++------ > 1 file changed, 22 insertions(+), 6 deletions(-) > > diff --git a/mm/gup.c b/mm/gup.c > index e065a49842a8..66193421c1d4 100644 > --- a/mm/gup.c > +++ b/mm/gup.c > @@ -2300,14 +2300,12 @@ static void pofs_unpin(struct pages_or_folios *pofs) > unpin_user_pages(pofs->pages, pofs->nr_entries); > } > > -/* > - * Returns the number of collected folios. Return value is always >= 0. > - */ > -static void collect_longterm_unpinnable_folios( > +static bool collect_longterm_unpinnable_folios( > struct list_head *movable_folio_list, > struct pages_or_folios *pofs) > { > struct folio *prev_folio = NULL; > + bool any_unpinnable = false; > bool drain_allow = true; > unsigned long i; > > @@ -2321,6 +2319,8 @@ static void collect_longterm_unpinnable_folios( > if (folio_is_longterm_pinnable(folio)) > continue; > > + any_unpinnable = true; > + > if (folio_is_device_coherent(folio)) > continue; > > @@ -2342,6 +2342,8 @@ static void collect_longterm_unpinnable_folios( > NR_ISOLATED_ANON + folio_is_file_lru(folio), > folio_nr_pages(folio)); > } > + > + return any_unpinnable; > } > > /* > @@ -2417,11 +2419,25 @@ migrate_longterm_unpinnable_folios(struct list_head *movable_folio_list, > static long > check_and_migrate_movable_pages_or_folios(struct pages_or_folios *pofs) > { > + bool any_unpinnable; > + > LIST_HEAD(movable_folio_list); > > - collect_longterm_unpinnable_folios(&movable_folio_list, pofs); > - if (list_empty(&movable_folio_list)) > + any_unpinnable = collect_longterm_unpinnable_folios(&movable_folio_list, pofs); > + Hi David, While re-reviewing the v3 patch, I realized that migrate_longterm_unpinnable_folios() should always be called whenever unpinnable folios are present, regardless of whether the movable_folio_list is empty. In collect_longterm_unpinnable_folios(), if folio_is_device_coherent() is true, the folio is not added to movable_folio_list. However, such device-coherent folios still need to be migrated later in migrate_longterm_unpinnable_folios(). I think the condition `list_empty(&movable_folio_list)` should be removed, and it might be better to revert commit 1aaf8c122918 rather than adding a new patch. What do you think? Thanks, Regards. > + if (list_empty(&movable_folio_list)) { > + /* > + * If we find any longterm unpinnable page that we failed to > + * isolated for migration, it might be because someone else > + * concurrently isolated it. Make the caller retry until it > + * succeeds. > + */ > + if (any_unpinnable) { > + pofs_unpin(pofs); > + return -EAGAIN; > + } > return 0; > + } > > return migrate_longterm_unpinnable_folios(&movable_folio_list, pofs); > } > -- > 2.49.0 > > ------bfByJ-ZIY6BJv7sVO1BMUP1RgQAR8Q.m4BWNyUsw_2ev9GnZ=_34a75_ Content-Type: text/plain; charset="utf-8" ------bfByJ-ZIY6BJv7sVO1BMUP1RgQAR8Q.m4BWNyUsw_2ev9GnZ=_34a75_--