From patchwork Tue Nov 14 07:00:44 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Kasireddy, Vivek" X-Patchwork-Id: 13454907 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 5EF93C4167B for ; Tue, 14 Nov 2023 07:25:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 83EC76B029F; Tue, 14 Nov 2023 02:25:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7EDD26B02A1; Tue, 14 Nov 2023 02:25:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 68E6D6B02B4; Tue, 14 Nov 2023 02:25:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 5323D6B029F for ; Tue, 14 Nov 2023 02:25:24 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 254BC1CB519 for ; Tue, 14 Nov 2023 07:25:24 +0000 (UTC) X-FDA: 81455724168.15.1F0F4AF Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) by imf26.hostedemail.com (Postfix) with ESMTP id 05E7C14001C for ; Tue, 14 Nov 2023 07:25:20 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=QeCP9wap; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf26.hostedemail.com: domain of vivek.kasireddy@intel.com designates 192.198.163.8 as permitted sender) smtp.mailfrom=vivek.kasireddy@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699946721; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=BewSgWNbl4Gg7Wg9eJhtkI5wudli3h0dwRy5Su18LEE=; b=ACegvndZDmBEipKG9H6IRhYw3fDQy9IQCjABf2Nl6qtzJUX4kwg/TOvkSrnoz1lKkfBdVD vy4Uc21n6B6K57SfPVb0R5ANeoYfuliLHiJ17vHTdB0k7u37h9YLMfEo9TMpg/xuv15Ung CT2+WK7wxi4UOoi7s4TGgjhU0jAyQas= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=QeCP9wap; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf26.hostedemail.com: domain of vivek.kasireddy@intel.com designates 192.198.163.8 as permitted sender) smtp.mailfrom=vivek.kasireddy@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699946721; a=rsa-sha256; cv=none; b=qvbBC8Aew6Lql5hZbIWtKH2cmQHHuei+EehfL3tQKV9xsINXuu1UfEvjTvPtglZu2lKjsi NnfYZ3vw4Txjpgi9JeJZyQFSNTMdCEzPlCfQ6S23rr6GV3UCjvKQZdiEyDy5CAwO5Rngcs pX/Kydem6QwIaB8bYLv38Dxq3ku26/I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1699946720; x=1731482720; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=tAXwuNZ3/tYubJQ1opn4NWyvGa5Nh5vwg3awbeugb6E=; b=QeCP9wapI+5UPTKSOCrWg+1QKNKyhc1eHFy7hJFJy5oh49Bm5VQZcZ53 hYi27tExvQk8XTQDFpPUdSLvJ4bwRqKIDFU5+Vlxgw2alM4i4HejkZuh3 niJv4AUn3tPYVGX/+9R3cgqGJtna54ULVIQvI2DEe8yMSJkMewktlFK0U r4Ya42qD5cWYnBJ0cZgQU01UofLM61s18xTPPhKDnb7GrqwpWOOY1b77W 5fZu5EtFYnXX76oS3JIqiXIhnYR784YsIEy+/GCnxvNvvp0kcOp0CbwAj CAd8wsfS6dBnA7V6yvnURSu8xHbH7jWpj+dw5f3HBftE5zL1Edf7FLY0U g==; X-IronPort-AV: E=McAfee;i="6600,9927,10893"; a="3655229" X-IronPort-AV: E=Sophos;i="6.03,301,1694761200"; d="scan'208";a="3655229" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Nov 2023 23:25:18 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.03,301,1694761200"; d="scan'208";a="5918441" Received: from vkasired-desk2.fm.intel.com ([10.105.128.132]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Nov 2023 23:25:19 -0800 From: Vivek Kasireddy To: dri-devel@lists.freedesktop.org, linux-mm@kvack.org Cc: Vivek Kasireddy , David Hildenbrand , Daniel Vetter , Mike Kravetz , Hugh Dickins , Peter Xu , Gerd Hoffmann , Dongwon Kim , Junxiao Chang , Jason Gunthorpe Subject: [PATCH] mm/gup: Introduce pin_user_pages_fd() for pinning shmem/hugetlbfs file pages (v3) Date: Mon, 13 Nov 2023 23:00:44 -0800 Message-Id: <20231114070044.464451-1-vivek.kasireddy@intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <0f05cade-c75e-4605-8e22-9fb916c622b0@redhat.com> References: <0f05cade-c75e-4605-8e22-9fb916c622b0@redhat.com> MIME-Version: 1.0 X-Rspamd-Queue-Id: 05E7C14001C X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: b7g6mkzdikor5rrto59xg9gm8a68k3dr X-HE-Tag: 1699946720-278096 X-HE-Meta: U2FsdGVkX1/HjytVXjjPPOdl+t8Is1aJyKYAvlIuAXxV4kBoMzr1+Tuk7VDFgVzwpTKFnMuKRPFXxyn95HP+LNXMs0y0GUmencOLaDRw82Y988embi622WjtcjWGkYf67KTY2XTrLK0T+Q2Fe8jE6+Qr80lFsjIj/IUvcD33p/ceRfSXXRq2QCsvtF+h/BSaUcr3PO8018VWCAVce2z5BkWv9vWU4ta6pzp5uh9g6utgHarlVzI7ohHMHqswIdxVyr1ZV8PebXia00nkA9IxgNnpPuFgDB5fE1fP4AjNIe+fE4Vg0ZKM/MrO5FrPJ2S2Bw2vYBHesLCeFOjRWpXWzUYNW5Ho5zpyMbSfCiYf25sGhfy9ymU/QfOvHIyWytBroUCrwRslP5xkBiMKtV1hhhHRcQLIa/vWubL29m/nvUHVnqWcqO4RTK+gjV4ejZ699OUmwQj6D4kWgA0hEOCVOgsKtR2ObrlS1BNyze1u39V/wHNsd4ok4Wi9gdqugFGN7j56Hk9lXw33Eru/JOGbWItaYsu/kHkipH41olVE/qcwiXI/rqXBOTel3LvZ3YS38yFaGIqIptKj4gC5hrLFsbVgpA0ylf7ZEoLHHdqoV9vuvPTgqHBy6cpcs9vxnX60jLQLxJ3ZIbPSJ/iHxa0SlDUXocahj+/iA9tcoN0rYuRcJxlJEwz9uzXmZUHUjKZXsf1NrGon3blo2BXe/GU/PSAP4CAC7q4UkKqwKlVLNK4vKj8PPUra4VpJGexPNDcJpWTU/rwkp8oBCCfD1M6Xoh1db5gFJpHZu0QevlG5+YwT94N2b7HDKbq1H2tXFXnWr0r/GNqus5YqQynqof/C2wwPybsMIinoGqtZVm1nBLKaEj4zJWlUiQocG06G294S3mKpQNU/gxICfyWK7EMlhML9luy+5gU9ScGlkIoXgF6Eez4W2krqAefj1q6myJ/Apt0nnppR3dsDNQ1om0C EHM1jaCl H4/WGceWyqcYokpktVdiJLH0bn3hbdm80g68vemIJaoT/qlgegCUsCStRbgIlR8rqnbxT6XWYiQU4IY26K2bnaMuP3b7/XC7npK6xgCKC7U3aNiWE3/I5tVZu5IPExuwe/vVye1UCSz7hLSZoNS7lR4DoPMEga6eUJQuKKMWmZXitCeI610JCGlNW2z6d5OaAdek5xum1eS+2OKQhlKeQEcXTl9WMEhucduQxW/66ouaPjd7eIK3VI8b/DqAYLz2GbOcePN3AFjM/xzsZi+GXFCm/Qq8VV3RdzxRFTmVqT5IZV/Y= 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: For drivers that would like to longterm-pin the pages associated with a file, the pin_user_pages_fd() API provides an option to not only pin the pages via FOLL_PIN but also to check and migrate them if they reside in movable zone or CMA block. This API currently works with files that belong to either shmem or hugetlbfs. Files belonging to other filesystems are rejected for now. The pages need to be located first before pinning them via FOLL_PIN. If they are found in the page cache, they can be immediately pinned. Otherwise, they need to be allocated using the filesystem specific APIs and then pinned. v2: - Drop gup_flags and improve comments and commit message (David) - Allocate a page if we cannot find in page cache for the hugetlbfs case as well (David) - Don't unpin pages if there is a migration related failure (David) - Drop the unnecessary nr_pages <= 0 check (Jason) - Have the caller of the API pass in file * instead of fd (Jason) v3: (David) - Enclose the huge page allocation code with #ifdef CONFIG_HUGETLB_PAGE (Build error reported by kernel test robot ) - Don't forget memalloc_pin_restore() on non-migration related errors - Improve the readability of the cleanup code associated with non-migration related errors - Augment the comments by describing FOLL_LONGTERM like behavior - Include the R-b tag from Jason Cc: David Hildenbrand Cc: Daniel Vetter Cc: Mike Kravetz Cc: Hugh Dickins Cc: Peter Xu Cc: Gerd Hoffmann Cc: Dongwon Kim Cc: Junxiao Chang Suggested-by: Jason Gunthorpe Reviewed-by: Jason Gunthorpe (v2) Signed-off-by: Vivek Kasireddy Reviewed-by: David Hildenbrand --- include/linux/mm.h | 2 + mm/gup.c | 109 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 111 insertions(+) diff --git a/include/linux/mm.h b/include/linux/mm.h index 418d26608ece..1b675fa35059 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -2472,6 +2472,8 @@ long get_user_pages_unlocked(unsigned long start, unsigned long nr_pages, struct page **pages, unsigned int gup_flags); long pin_user_pages_unlocked(unsigned long start, unsigned long nr_pages, struct page **pages, unsigned int gup_flags); +long pin_user_pages_fd(struct file *file, pgoff_t start, + unsigned long nr_pages, struct page **pages); int get_user_pages_fast(unsigned long start, int nr_pages, unsigned int gup_flags, struct page **pages); diff --git a/mm/gup.c b/mm/gup.c index 231711efa390..b3af967cdff1 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -3410,3 +3410,112 @@ long pin_user_pages_unlocked(unsigned long start, unsigned long nr_pages, &locked, gup_flags); } EXPORT_SYMBOL(pin_user_pages_unlocked); + +static struct page *alloc_file_page(struct file *file, pgoff_t idx) +{ +#ifdef CONFIG_HUGETLB_PAGE + struct page *page = ERR_PTR(-ENOMEM); + struct folio *folio; + int err; + + if (is_file_hugepages(file)) { + folio = alloc_hugetlb_folio_nodemask(hstate_file(file), + NUMA_NO_NODE, + NULL, + GFP_USER); + if (folio && folio_try_get(folio)) { + page = &folio->page; + err = hugetlb_add_to_page_cache(folio, + file->f_mapping, + idx); + if (err) { + folio_put(folio); + free_huge_folio(folio); + page = ERR_PTR(err); + } + } + return page; + } +#endif + return shmem_read_mapping_page(file->f_mapping, idx); +} + +/** + * pin_user_pages_fd() - pin user pages associated with a file + * @file: the file whose pages are to be pinned + * @start: starting file offset + * @nr_pages: number of pages from start to pin + * @pages: array that receives pointers to the pages pinned. + * Should be at-least nr_pages long. + * + * Attempt to pin pages associated with a file that belongs to either shmem + * or hugetlb. The pages are either found in the page cache or allocated if + * necessary. Once the pages are located, they are all pinned via FOLL_PIN. + * And, these pinned pages need to be released either using unpin_user_pages() + * or unpin_user_page(). + * + * It must be noted that the pages may be pinned for an indefinite amount + * of time. And, in most cases, the duration of time they may stay pinned + * would be controlled by the userspace. This behavior is effectively the + * same as using FOLL_LONGTERM with other GUP APIs. + * + * Returns number of pages pinned. This would be equal to the number of + * pages requested. If no pages were pinned, it returns -errno. + */ +long pin_user_pages_fd(struct file *file, pgoff_t start, + unsigned long nr_pages, struct page **pages) +{ + struct page *page; + unsigned int flags, i; + long ret; + + if (start < 0) + return -EINVAL; + + if (!file) + return -EINVAL; + + if (!shmem_file(file) && !is_file_hugepages(file)) + return -EINVAL; + + flags = memalloc_pin_save(); + do { + for (i = 0; i < nr_pages; i++) { + /* + * In most cases, we should be able to find the page + * in the page cache. If we cannot find it, we try to + * allocate one and add it to the page cache. + */ + page = find_get_page_flags(file->f_mapping, + start + i, + FGP_ACCESSED); + if (!page) { + page = alloc_file_page(file, start + i); + if (IS_ERR(page)) { + ret = PTR_ERR(page); + goto err; + } + } + ret = try_grab_page(page, FOLL_PIN); + if (unlikely(ret)) + goto err; + + pages[i] = page; + put_page(pages[i]); + } + + ret = check_and_migrate_movable_pages(nr_pages, pages); + } while (ret == -EAGAIN); + + memalloc_pin_restore(flags); + return ret ? ret : nr_pages; +err: + memalloc_pin_restore(flags); + while (i-- > 0) + if (pages[i]) + unpin_user_page(pages[i]); + + return ret; +} +EXPORT_SYMBOL_GPL(pin_user_pages_fd); +