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 A5DB9C3271E for ; Fri, 5 Jul 2024 20:48:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2A2376B009D; Fri, 5 Jul 2024 16:48:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 252BC6B009E; Fri, 5 Jul 2024 16:48:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 11B626B009F; Fri, 5 Jul 2024 16:48:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E6A916B009D for ; Fri, 5 Jul 2024 16:48:37 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 92D6A1402E2 for ; Fri, 5 Jul 2024 20:48:37 +0000 (UTC) X-FDA: 82306887474.13.24AA118 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf30.hostedemail.com (Postfix) with ESMTP id 527A680028 for ; Fri, 5 Jul 2024 20:48:33 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=JAbNq0Vi; spf=pass (imf30.hostedemail.com: domain of sj@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720212502; 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=1lAI62TXFqm2T8PsJx6CSJRECl6f4IIXWbxf0bL6/lQ=; b=soGkjlKXHOAtkRkIzRsTlun3u5cAGdlroPuCEwelpaaticYBCGt1IPNTPtNBGHx8sDDPpW lCnvLtoT6JRr5bFIFI1p9V8AubP9c6DYU1dYSnwYYBDRrTa8YAV3bRCUs3lrrACYva7PHu 1xjazmtc2+DDtnD21Eh+vFjn/peFpyo= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=JAbNq0Vi; spf=pass (imf30.hostedemail.com: domain of sj@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720212502; a=rsa-sha256; cv=none; b=SAq0/Xhm22222iqOmABtQw2EyEtjPtGRUeElZyy2okT2acmQpAQtDeAElTnqoToT5O3mHg haRFr3GQppt2HmhRWT5a1uJzIBdPAsNvEO1LriB5SF3TxvSCOIDUIvNAfzzTSQJzZyYLY2 jMRi/tCf01p3ogAT9nUVVlB4tAqjzz0= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 9C170CE3EFA; Fri, 5 Jul 2024 20:48:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B458FC4AF0A; Fri, 5 Jul 2024 20:48:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1720212508; bh=emKAb+tft4K0foCSYr6sbq2VPkioj9JnikHXC08E3Ec=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JAbNq0ViVhr+cccjh6Gzx0zT7EFBDA6vCNo7U0ZIHH4rNpWtw+x2/+S1XuyTdq691 bnN+ju+K2EIsD7acjjiz7NyueF/8av7nMH2npVqQr0qr6j9V+Hq+4/6XoJbnTIPI4H i3g0rauvRfdqpzA2FxU25RP2mr5fqX3tjDSccGhzNE491868IIb2BCbWJR1I/SOfe8 r5eH7LnSA13ninCr9W/FBMqTLrBNk1CPvIBy6LuMip3asVVvdtQkEc9j0se0GTpU9I ywWcWHRBWWo3UNdmJnzY1ZTjzVrWdfM8f2eyxc90E1TP8NdepfntOUV2+BVNUjT5e5 uoh2AgtMF7S9w== From: SeongJae Park To: Vivek Kasireddy Cc: SeongJae Park , dri-devel@lists.freedesktop.org, linux-mm@kvack.org, David Hildenbrand , Matthew Wilcox , Christoph Hellwig , Daniel Vetter , Hugh Dickins , Peter Xu , Gerd Hoffmann , Dongwon Kim , Junxiao Chang , Jason Gunthorpe , Christoph Hellwig , Dave Airlie , Andrew Morton Subject: Re: [PATCH v16 3/9] mm/gup: Introduce memfd_pin_folios() for pinning memfd folios Date: Fri, 5 Jul 2024 13:48:25 -0700 Message-Id: <20240705204825.109189-1-sj@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240624063952.1572359-4-vivek.kasireddy@intel.com> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 527A680028 X-Stat-Signature: kcbswysjd8ehcu39q5kkrrz3etcqwqfg X-HE-Tag: 1720212513-735824 X-HE-Meta: U2FsdGVkX1+J7b/h7TKSsFCmJdHOJ8gnV8JcMxIZfUyZGDX0+6TwMa+WbwUUZAACEZuPlJwi8l7DFFO+CuOe3VBWeYzLzvlCca858GVbA1WZmF/HS/Don9YdW7/5PPj3Jepj8DeDqBv2SlilGx3SnUiZ/ZW9qFL+LwY838hXFk3SEGi877p+pC+4zKATX0SUu+c6qD60engeXl/KE4kpHboF+cSar8M9fY+Xrro7ZDQ8AJhDLo/owly8lNf6deaDSyVPCD/zgkkW3vt+lRNflHgUHNgN3s4DlXdPijJDKj/vZsh+JQSogkIOxyynYu17CwSVe3J2qG8vayIdEJbq7DLivzcV4tt9DsVwPRU3UNwqsOZtufJxkrJ/yOtO5dRkM/F1wRUuZEctdgBMyLEq7CD43mdPY6r1G5LtRlJf5KUbK6Hp2RnF/jG/l/6RwR1ep/eNQaJZRl2DmJzHYrAfcS4Y5NpZGXoxO8joB4Cj+cF7gdy0CEVvJrt2phk3XkBMtv7B+j9hD7Fqi0rpc2nYXj2vkhJwkQzkQeL9dWNdum8vpSPG0Ka4p1f+hUcP6WtWvB2ZJxHA7MREEtUwwyffotuCsU9pP6iNWBqy1IjsXHvfbXN48IP4urkcr76QGCStYBaITwBSY16Wqf9QojXPCxOEqVzdHAjVTqfY1zrn63GclVVCC/Kn1mXa2W9iT4aAHXAkYJBsfwekjvLPEtXo7Hd9exg+9RSiQlc8f4Oy3O8/LjurM5SBVxumxQmWDbZ9uHY9KtYQdYA2xjNYfIPKeLbWALQiFGHaPZOFfVyZ9r5lhRtMc6XWrkp+HXZlUzciBfghooYSmgtuWutQd7ptpUmGVtJtsr83LfAjnX2UQmwwKNrZsLy0OI+6eCSf2BnacbKRBMPXL/iBgdX5J7C8XgLVo117angjZZZ9o/Mhix1JOIV+vdgoWDEsGpiXA2fLoi+xs4kFGSln9yN/ZpU Ih9TPg1J Drg2O5ViGO1Qz9/GzLk9r4P4PKWrnL73e32Dvv6+Y4ibRAECHu7lHqs8hty6hxYCaIEQWdMueXDqRZ0C0CxDIaInO4T1oiWzGD8AEYw6zPRxF93QHIQJIpUEOyBLPpnyspZy+sopY0uUjShyRUXCRKSo4Cl1va5C6yMezcU2WsuJQuYzey48+sglZOvJq1IXJkYt2qBhjv7A+JoB3xUoFAX7ydeDcMgXW2lxCSzCtoM5pLWV7jElqacfsexsuSHwG+RbjPZhZkfrDFFR6GXo0yJLFxMY18mtKeusA6bDGzse/pjAvuPXvwnmjy4KiFQLT/L/xQPrRFj4i924Jcoi1jCPkg0NkPmgUx9ummY6FuzjlIyrMVu2Khn/wpuO4/wwFeA++ 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: Hello Vivek and Andrew, On Sun, 23 Jun 2024 23:36:11 -0700 Vivek Kasireddy wrote: > For drivers that would like to longterm-pin the folios associated > with a memfd, the memfd_pin_folios() API provides an option to > not only pin the folios via FOLL_PIN but also to check and migrate > them if they reside in movable zone or CMA block. This API > currently works with memfds but it should work with any files > that belong to either shmemfs or hugetlbfs. Files belonging to > other filesystems are rejected for now. > > The folios 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. > > Cc: David Hildenbrand > Cc: Matthew Wilcox (Oracle) > Cc: Christoph Hellwig > Cc: Daniel Vetter > Cc: Hugh Dickins > Cc: Peter Xu > Cc: Gerd Hoffmann > Cc: Dongwon Kim > Cc: Junxiao Chang > Suggested-by: Jason Gunthorpe > Reviewed-by: Jason Gunthorpe (v2) > Reviewed-by: David Hildenbrand (v3) > Reviewed-by: Christoph Hellwig (v6) > Acked-by: Dave Airlie > Acked-by: Gerd Hoffmann > Signed-off-by: Vivek Kasireddy > --- > include/linux/memfd.h | 5 ++ > include/linux/mm.h | 3 + > mm/gup.c | 137 ++++++++++++++++++++++++++++++++++++++++++ > mm/memfd.c | 45 ++++++++++++++ > 4 files changed, 190 insertions(+) > [...] > diff --git a/mm/gup.c b/mm/gup.c > index a88e19c78730..94160abbf499 100644 > --- a/mm/gup.c > +++ b/mm/gup.c [...] > @@ -3747,3 +3749,138 @@ long pin_user_pages_unlocked(unsigned long start, unsigned long nr_pages, > &locked, gup_flags); > } > EXPORT_SYMBOL(pin_user_pages_unlocked); > + > +/** > + * memfd_pin_folios() - pin folios associated with a memfd [...] > + for (i = 0; i < nr_found; i++) { > + /* > + * As there can be multiple entries for a > + * given folio in the batch returned by > + * filemap_get_folios_contig(), the below > + * check is to ensure that we pin and return a > + * unique set of folios between start and end. > + */ > + if (next_idx && > + next_idx != folio_index(fbatch.folios[i])) > + continue; > + > + folio = try_grab_folio(&fbatch.folios[i]->page, > + 1, FOLL_PIN); > + if (!folio) { > + folio_batch_release(&fbatch); > + ret = -EINVAL; > + goto err; > + } I found this patch is applied on mm-unstable as commit 7618d1ff59ef ("mm/gup: introduce memfd_pin_folios() for pinning memfd folios"). Somehow, however, the commit has changd the above try_grab_folio() call to try_grab_folio_fast() call. As a result, building kernel without CONFIG_MMU fais as below: CC mm/gup.o mm/gup.c: In function 'memfd_pin_folios': mm/gup.c:3862:41: error: implicit declaration of function 'try_grab_folio_fast'; did you mean 'try_grab_folio'? [-Werror=implicit-function-declaration] 3862 | folio = try_grab_folio_fast(&fbatch.folios[i]->page, | ^~~~~~~~~~~~~~~~~~~ | try_grab_folio mm/gup.c:3862:39: warning: assignment to 'struct folio *' from 'int' makes pointer from integer without a cast [-Wint-conversion] 3862 | folio = try_grab_folio_fast(&fbatch.folios[i]->page, | ^ But simply changing the call back to try_grab_folio() causes another failure: CC mm/gup.o mm/gup.c: In function 'memfd_pin_folios': mm/gup.c:3862:56: error: passing argument 1 of 'try_grab_folio' from incompatible pointer type [-Werror=incompatible-pointer-types] 3862 | folio = try_grab_folio(&fbatch.folios[i]->page, | ^~~~~~~~~~~~~~~~~~~~~~~ | | | struct page * mm/gup.c:141:47: note: expected 'struct folio *' but argument is of type 'struct page *' 141 | int __must_check try_grab_folio(struct folio *folio, int refs, | ~~~~~~~~~~~~~~^~~~~ mm/gup.c:3862:39: warning: assignment to 'struct folio *' from 'int' makes pointer from integer without a cast [-Wint-conversion] 3862 | folio = try_grab_folio(&fbatch.folios[i]->page, | ^ Maybe the change has made to fix conflict with another mm-unstable commit 02a2d55767d1 ("mm: gup: stop abusing try_grab_folio"), but forgot the CONFIG_MMU unset case? I confirmed the failure disappears after further cleanup like below: diff --git a/mm/gup.c b/mm/gup.c index 46a266ed84f7..9f4902425070 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -3859,9 +3859,9 @@ long memfd_pin_folios(struct file *memfd, loff_t start, loff_t end, next_idx != folio_index(fbatch.folios[i])) continue; - folio = try_grab_folio_fast(&fbatch.folios[i]->page, - 1, FOLL_PIN); - if (!folio) { + folio = page_folio(&fbatch.folios[i]->page); + + if (try_grab_folio(folio, 1, FOLL_PIN)) { folio_batch_release(&fbatch); ret = -EINVAL; goto err; I didn't look deep into the patch, so unsure if that's a valid fix, though. May I ask your thoughts? Thanks, SJ [...]