All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sooyong Suk" <s.suk@samsung.com>
To: "'Jaewon Kim'" <jaewon31.kim@gmail.com>,
	"'Christoph Hellwig'" <hch@infradead.org>
Cc: <viro@zeniv.linux.org.uk>, <linux-kernel@vger.kernel.org>,
	<akpm@linux-foundation.org>, <linux-mm@kvack.org>,
	<spssyr@gmail.com>, <axboe@kernel.dk>,
	<linux-block@vger.kernel.org>, <dhavale@google.com>,
	<surenb@google.com>
Subject: RE: [RFC PATCH] block, fs: use FOLL_LONGTERM as gup_flags for direct IO
Date: Fri, 7 Mar 2025 11:07:08 +0900	[thread overview]
Message-ID: <848301db8f05$a1d79430$e586bc90$@samsung.com> (raw)
In-Reply-To: <CAJrd-UuLvOPLC2Xr=yOzZYvOw9k8qwbNa0r9oNjne31x8Pmnhw@mail.gmail.com>

> On Fri, Mar 7, 2025 at 12:26 AM Christoph Hellwig <hch@infradead.org>
> wrote:
> >
> > On Thu, Mar 06, 2025 at 04:40:56PM +0900, Sooyong Suk wrote:
> > > There are GUP references to pages that are serving as direct IO
> buffers.
> > > Those pages can be allocated from CMA pageblocks despite they can be
> > > pinned until the DIO is completed.
> >
> > direct I/O is eactly the case that is not FOLL_LONGTERM and one of the
> > reasons to even have the flag.  So big fat no to this.
> >
> 

Understood.

> Hello, thank you for your comment.
> We, Sooyong and I, wanted to get some opinions about this FOLL_LONGTERM
> for direct I/O as CMA memory got pinned pages which had been pinned from
> direct io.
> 
> > You also completely failed to address the relevant mailinglist and
> > maintainers.
> 
> I added block maintainer Jens Axboe and the block layer maillinst here,
> and added Suren and Sandeep, too.

Then, what do you think of using PF_MEMALLOC_PIN for this context as below?
This will only remove __GFP_MOVABLE from its allocation flag.
Since __bio_iov_iter_get_pages() indicates that it will pin user or kernel pages,
there seems to be no reason not to use this process flag.

block/bio.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/block/bio.c b/block/bio.c
index 65c796ecb..671e28966 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -1248,6 +1248,7 @@ static int __bio_iov_iter_get_pages(struct bio *bio, struct iov_iter *iter)
 	unsigned len, i = 0;
 	size_t offset;
 	int ret = 0;
+	unsigned int flags;
 
 	/*
 	 * Move page array up in the allocated memory for the bio vecs as far as
@@ -1267,9 +1268,11 @@ static int __bio_iov_iter_get_pages(struct bio *bio, struct iov_iter *iter)
 	 * result to ensure the bio's total size is correct. The remainder of
 	 * the iov data will be picked up in the next bio iteration.
 	 */
+	flags = memalloc_pin_save();
 	size = iov_iter_extract_pages(iter, &pages,
 				      UINT_MAX - bio->bi_iter.bi_size,
 				      nr_pages, extraction_flags, &offset);
+	memalloc_pin_restore(flags);
 	if (unlikely(size <= 0))
 		return size ? size : -EFAULT;



  reply	other threads:[~2025-03-07  2:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20250306074101epcas1p4b24ac546f93df2c7fe3176607b20e47f@epcas1p4.samsung.com>
2025-03-06  7:40 ` [RFC PATCH] block, fs: use FOLL_LONGTERM as gup_flags for direct IO Sooyong Suk
2025-03-06 15:26   ` Christoph Hellwig
2025-03-06 23:28     ` Jaewon Kim
2025-03-07  2:07       ` Sooyong Suk [this message]
2025-03-07  2:28         ` Suren Baghdasaryan
2025-03-07  6:38           ` Sooyong Suk
2025-03-12 15:17           ` Christoph Hellwig
2025-03-12 15:20             ` Suren Baghdasaryan
2025-03-12 15:25               ` Christoph Hellwig
2025-03-12 15:38                 ` Suren Baghdasaryan
2025-03-12 15:52                   ` Christoph Hellwig
2025-03-12 16:03                     ` Bart Van Assche
2025-03-12 16:06                     ` Suren Baghdasaryan
2025-03-12 16:21                       ` Christoph Hellwig
2025-03-07 20:23     ` Matthew Wilcox
2025-03-07 21:37       ` Suren Baghdasaryan
2025-03-12 15:21       ` Christoph Hellwig
2025-03-13 22:49         ` David Hildenbrand
2025-03-15  1:04           ` John Hubbard
2025-03-15 23:00             ` David Hildenbrand
2025-03-15 23:09               ` Zi Yan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='848301db8f05$a1d79430$e586bc90$@samsung.com' \
    --to=s.suk@samsung.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=dhavale@google.com \
    --cc=hch@infradead.org \
    --cc=jaewon31.kim@gmail.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=spssyr@gmail.com \
    --cc=surenb@google.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.