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 E96C3C54E65 for ; Thu, 22 May 2025 09:29:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5226A6B0083; Thu, 22 May 2025 05:29:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D2E76B0085; Thu, 22 May 2025 05:29:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 40FEB6B0088; Thu, 22 May 2025 05:29:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 231B76B0083 for ; Thu, 22 May 2025 05:29:57 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D3EF61D353A for ; Thu, 22 May 2025 09:29:54 +0000 (UTC) X-FDA: 83470021908.25.8A1BD55 Received: from mailout4.samsung.com (mailout4.samsung.com [203.254.224.34]) by imf13.hostedemail.com (Postfix) with ESMTP id 12DE320006 for ; Thu, 22 May 2025 09:29:50 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=hx+rXTaa; spf=pass (imf13.hostedemail.com: domain of hyesoo.yu@samsung.com designates 203.254.224.34 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=1747906192; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=XwKQT3z58lh9GYCQdXUdh9e0pWYJJWCFk3kfbrfxkOc=; b=fXvQBniy+eXyqSBdCqMXHvejTpEGOEN10uHhHg5p3wLecnv/Oi0ndxYQ8vAZmoTLKeuDpH KQsmX0qVgDmusopRvW3n3H0XCB1xFow0YCrQeoafVvb/Azp21DpEgmqGD+gpeWJ0DPGrVj GsUPBNbSHh4gPd0WAjjID3a2z+2g2uY= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=hx+rXTaa; spf=pass (imf13.hostedemail.com: domain of hyesoo.yu@samsung.com designates 203.254.224.34 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=1747906192; a=rsa-sha256; cv=none; b=hKZ92jwNKhArcViW/Nc+V6VypT54/IgysOieAGq4ZJVs+NVX4bFUa9W7DXi7P4E2gkOyjW 8NacU/KW/KvHg83MhKpHD5zAeSSeEgYM0WULnuyp4J2EDZdtRks9hSJJsm6U16GyxMyXXo YfQQ7GoKAaaCMDhzRhRFa1TAlJURljQ= Received: from epcas2p1.samsung.com (unknown [182.195.41.53]) by mailout4.samsung.com (KnoxPortal) with ESMTP id 20250522092945epoutp041e2a1397389f836c24f01e528487d591~Bz2pQslC02900929009epoutp04E for ; Thu, 22 May 2025 09:29:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout4.samsung.com 20250522092945epoutp041e2a1397389f836c24f01e528487d591~Bz2pQslC02900929009epoutp04E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1747906185; bh=XwKQT3z58lh9GYCQdXUdh9e0pWYJJWCFk3kfbrfxkOc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=hx+rXTaa0H5dq7Mp5J6MoHqM2Kk/RGqpadAXDBrFZUOEf48Otcm0dpxSHhQgAAgRB vTheHlynXacPOy9UuOxsLjVh7LN77i8UGdGMBqh83pzeQdecQH1lu+15VfzqQWldes 3rUlN1nZJ5c6h/Wy28ly4RMN4KL0R3udp4lhjIB8= Received: from epsnrtp03.localdomain (unknown [182.195.42.155]) by epcas2p1.samsung.com (KnoxPortal) with ESMTPS id 20250522092945epcas2p16acde5e880918afc6662a790124ee814~Bz2pDlcce1925119251epcas2p1z; Thu, 22 May 2025 09:29:45 +0000 (GMT) Received: from epcas2p1.samsung.com (unknown [182.195.36.69]) by epsnrtp03.localdomain (Postfix) with ESMTP id 4b330T0gTsz3hhTC; Thu, 22 May 2025 09:29:45 +0000 (GMT) Received: from epsmtrp1.samsung.com (unknown [182.195.40.13]) by epcas2p1.samsung.com (KnoxPortal) with ESMTPA id 20250522092944epcas2p1ca46168564555aad6d9880bda26ec8de~Bz2oAYHwF1925119251epcas2p1u; Thu, 22 May 2025 09:29:44 +0000 (GMT) Received: from epsmgms1p1new.samsung.com (unknown [182.195.42.41]) by epsmtrp1.samsung.com (KnoxPortal) with ESMTP id 20250522092944epsmtrp19aab46a95f2e3aa7755f51553533d3f8~Bz2n-q_340938409384epsmtrp1a; Thu, 22 May 2025 09:29:44 +0000 (GMT) X-AuditID: b6c32a29-55afd7000000223e-13-682eee8803eb Received: from epsmtip2.samsung.com ( [182.195.34.31]) by epsmgms1p1new.samsung.com (Symantec Messaging Gateway) with SMTP id 65.4D.08766.88EEE286; Thu, 22 May 2025 18:29:44 +0900 (KST) Received: from tiffany (unknown [10.229.95.142]) by epsmtip2.samsung.com (KnoxPortal) with ESMTPA id 20250522092944epsmtip203bc70b0bc52bee696d0e695ecddced9~Bz2n32Gnl2568125681epsmtip2s; Thu, 22 May 2025 09:29:44 +0000 (GMT) Date: Thu, 22 May 2025 18:27:55 +0900 From: Hyesoo Yu To: John Hubbard Cc: David Hildenbrand , Jaewon Kim , zhaoyang.huang@unisoc.com, surenb@google.com, linux-mm@kvack.org Subject: Re: [RFC] pin_user_pages_fast failure count increased Message-ID: <20250522092755.GA3277597@tiffany> MIME-Version: 1.0 In-Reply-To: <2aa1cafb-bb9a-4540-9552-7f56bf1fb911@nvidia.com> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsWy7bCSvG7HO70Mg8+P5C2+rv/FbNG9eSaj xcani9gt7q35z2ox+dICNotJLT3MDmweO2fdZfdYsKnUY9OnSewevc3v2Dze77vK5nG4/Sx7 AFsUl01Kak5mWWqRvl0CV8bS2yfZC7YLVjx7f5ulgfEjbxcjJ4eEgIlE2912pi5GLg4hgd2M EstuNbNCJCQlZn0+yQRhC0vcbznCClH0mFHizaLNjF2MHBwsAqoSpz4HgNSwCahLnNiyjBHE FhFQk3jz5iU7iM0sMJlR4up/sGXCAnYSVzfdYgaxeQX0JH61tbJDzHzDKNF36jEbREJQ4uTM JywQzeoSf+ZdYgbZxSwgLbH8HwdEWF6ieetssDmcQDN/vZ/ENIFRcBaS7llIumchdM9C0r2A kWUVo2RqQXFuem6xYYFhXmq5XnFibnFpXrpecn7uJkZwbGhp7mDcvuqD3iFGJg7GQ4wSHMxK IrxHn+llCPGmJFZWpRblxxeV5qQWH2KU5mBREucVf9GbIiSQnliSmp2aWpBaBJNl4uCUamDy bRDcOavc9ayn6Zkw/mKHhLiARaFvn2cuOH00/nJuZClDS+PMzqDe/T3KNaHLSgVF3AQmtRyf 1tRSFfScfWLg81mrRC4Yptv8rrdnn2b1Xsyy1rDn+wHRAxd3qy9IuSejx/Fw2h87k6wZiz3c w8Q02O7pfdquLu31ryDl4sVpOq8OnXXxvJSc/mqWalJ3SVLA5OoIjQ9uHVm/m3g8kw/FmM+w rzm4VMInmEX9s3nMlekzN3uaixQG7d8qLx31cIW6m0pDaEhj4UVn72/SyfrCcm6ZOfN1/W1m xbdc1rt7bqE90+LDamuXbjfvVU3ZGND0iHt1oZXTRvZbr6w7t9em72H4OPWC4+RZ0UI5SizF GYmGWsxFxYkARPFdBfwCAAA= X-CMS-MailID: 20250522092944epcas2p1ca46168564555aad6d9880bda26ec8de X-Msg-Generator: CA Content-Type: multipart/mixed; boundary="----.cKlolkxedMLVDWcgmrm8Gdt3k.eYqjXC2h.qDwGQioKViW9=_98506_" X-Sendblock-Type: AUTO_CONFIDENTIAL CMS-TYPE: 102P cpgsPolicy: CPGSC10-234,Y X-CFilter-Loop: Reflected X-CMS-RootMailID: 20250522092944epcas2p1ca46168564555aad6d9880bda26ec8de References: <3d0b8c8b-b707-4a49-99f9-09aadfc27432@redhat.com> <2aa1cafb-bb9a-4540-9552-7f56bf1fb911@nvidia.com> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 12DE320006 X-Stat-Signature: 3tnipakpq8j3zi475zskqmt4qie5xwid X-Rspam-User: X-HE-Tag: 1747906190-687865 X-HE-Meta: U2FsdGVkX1+dchFua+AlTr8T7cwpuy/1ZJIlv9Dbuv2Bj7iULkElkZEF8e0RgOt8qIWjNUVvYlMeJ9kJx9Q7ZyJ9vX+x3gDPZGAY5CXC9M+COjjonOuJjh88BYcQN90t19XOJ7ybkULvJOd6DTW620IdedVaBs2bGOrZ5z89sphiR0Eg0ks4RWpmVRmRY9n8l+LyGxfH+5kSGytljgvmZU9/LSWRy8omyiFpqYEMJPX620OgfsltzD6e52q1yLQjHWxyL9auZTC/3I5koLkbzayjdkCwqTzKfLpNHgWq2Ay/tZIfbfzwalLASjUK1QCixyA2sDMVZQd9dhqXbrBamMkSb7+AwsAQjrZe6hc8XS+uWzOXhYp25L2r0tNPEPLl4GTI+GtrDIgP9I1tny0gr9izXepwezzRU/SgvUsJfBt8+1EwxWTbfjcHiQSYWY2OWoeAZCcbhxXWmr9oc0+qnOW93oBxfnTfwJRO16N2vKKD8q/8OUyD8zTcCL9B6hA3Ce55W3sck2nUS+yx66V+FBK3qvav4p3A8c5CMmTF8NVhCVioIBZ/cSrW+VbhrA7W5N3sqHxeXXKUDpgDixZqlxkNRj4oBzW5ARaoKF4PeNyRMBAi4XegFsrdI8mm/9iK2oHyD+QiUsI8L7hyofDGBwh1BvgBH6+uE2i490A8ejLkBs4Jjjl9y8ms1FYBljF00crIqt+FlB8Gy0vxAhN5xws2JD8ySU1vkUdxu2ZQzuuGuxPDnzw6CjXxRPCXuF5Og8twyA1fBZ+lY91Uo7hfLnCrJd6yI52MqAOUQ6VmE9TV+Ik7isGZ5CRkVFucYJcLKvFsvUmUxhXoxmd1FrX8lnDAw0fTGwKwF22phTwVYA8FrZxBMLBPdZyxR9oIk5WkofNWOd9O4eOsZaI91mA9Gbwot/InsfAy25FZEJ6JBOPfSfHobnex5QyqeoM4X4wY0MJMIf/YmwswzqUWvxt zfmMjrOX i6BqZM3A1Zh+IyfzwH4oufIoBBYcK8jLImVUcCUlOy7WEK/R7/gMn/aEyDLGCTmyfsUJob6P1vVsftg7Hej9mFcKNuBOj+ChmtZsYh6+2C2LRN/Oc+M8XWBLvrMhVUQSFgiA5ZYWuW5hwbVfZyXc3g1fk2GjtkQTgtmBPi9JKhaFp+aUIFucXhMUyeQyBTtRWkU+uyNueC+Ns3FzCGc5W1mtLc8zGrV2ZQtqao+yvziFiwx/7aK1ALy2ZNv8eI6oe+xA0nI1WefQPeIFeBVz3OvYoNcVagRgzNKxvunDP8FjKzv/FyWNAco7MRg== 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: ------.cKlolkxedMLVDWcgmrm8Gdt3k.eYqjXC2h.qDwGQioKViW9=_98506_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Disposition: inline On Mon, Apr 28, 2025 at 02:12:57PM -0700, John Hubbard wrote: > On 4/28/25 1:56 PM, David Hildenbrand wrote: > > On 28.04.25 22:14, John Hubbard wrote: > > > On 4/28/25 8:17 AM, Jaewon Kim wrote: > > > > Hi > > > > > > > > If pin_user_pages_fast does not pin all the requested number of pages, > > > > then drivers calling to pin_user_pages_fast should retry until the gup > > > > pins all? > > > > > > > > > > Approaches vary, for handling partial success of pin_user_pages(). > > > > > > * Many drivers unpin everything and either bail out entirely, or retry > > > pinning the entire original range. > > > > Hm, unpinning + trying to repin the entire range can easily result in an > > endless loop on persistent errors IIRC? > > > > I vaguely recall a limited number of retries, yes. > > thanks, > -- > John Hubbard > > Hi, I'd like to report a potential issue introduced by a recent change in 1aaf8c122918 mm: gup: fix infinite loop within __get_longterm_locked Previously, the call to migrate_longterm_unpinnable_folio() was guarded by the collected variable. This meant that if a CMA page was temporarily held in the pagevec and failed LRU isolation, it wouldn't be added to the movable_page_list, but the collected counter would still be incremented. As a result, migrate_longterm_unpinnable_folio() would return -EAGAIN, and the process would be retried until migration of the CMA page succeeded. However, in the recent patch merged into mainline, the logic now only checks whether movable_page_list is empty, and no longer relies on the collected count. This can cause CMA pages that fail isolation to bypass retry logic and remain pinned. Effectively,long-term pinning is now possible for CMA pages — something that previously would have been avoided through repeated attempts. We've observed this behavior in practice, which has led to issues such as CMA allocation failures under memory pressure. This may indicate a regression in the logic that prevents pinning of unmovable CMA pages. I believe this warrants further discussion or possibly a fix to restore the intended retry behavior for pages that fail LRU isolation. Thanks, Hyesoo Yu. ------.cKlolkxedMLVDWcgmrm8Gdt3k.eYqjXC2h.qDwGQioKViW9=_98506_ Content-Type: text/plain; charset="utf-8" ------.cKlolkxedMLVDWcgmrm8Gdt3k.eYqjXC2h.qDwGQioKViW9=_98506_--