From: Jason Gunthorpe <jgg@nvidia.com>
To: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>,
Jens Axboe <axboe@kernel.dk>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@redhat.com>,
Pavel Begunkov <asml.silence@gmail.com>,
io-uring@vger.kernel.org
Subject: Re: [PATCH v4 4/6] io_uring: rsrc: avoid use of vmas parameter in pin_user_pages()
Date: Wed, 19 Apr 2023 20:22:51 -0300 [thread overview]
Message-ID: <ZEB3y0V2GSDcUMc2@nvidia.com> (raw)
In-Reply-To: <8bf0df41-27ef-4305-b424-e43045a6d68d@lucifer.local>
On Wed, Apr 19, 2023 at 07:45:06PM +0100, Lorenzo Stoakes wrote:
> For example, imagine if a user (yes it'd be weird) mlock'd some pages in a
> buffer and not others, then we'd break their use case. Also (perhaps?) more
> feasibly, a user might mix hugetlb and anon pages. So I think that'd be too
> restrictive here.
Yeah, I agree we should not add a broad single-vma restriction to
GUP. It turns any split of a VMA into a potentially uABI breaking
change and we just don't need that headache in the mm..
> I do like the idea of a FOLL_SINGLE_VMA for other use cases though, the
> majority of which want one and one page only. Perhaps worth taking the
> helper added in this series (get_user_page_vma_remote() from [1]) and
> replacing it with an a full GUP function which has an interface explicitly
> for this common single page/vma case.
Like I showed in another thread a function signature that can only do
one page and also returns the VMA would force it to be used properly
and we don't need a FOLL flag.
Jason
next prev parent reply other threads:[~2023-04-19 23:22 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-18 15:48 [PATCH v4 0/6] remove the vmas parameter from GUP APIs Lorenzo Stoakes
2023-04-18 15:49 ` [PATCH v4 1/6] mm/gup: remove unused vmas parameter from get_user_pages() Lorenzo Stoakes
2023-04-18 15:49 ` Lorenzo Stoakes
2023-04-18 15:49 ` Lorenzo Stoakes
2023-04-19 8:40 ` Christian König
2023-04-19 8:40 ` Christian König
2023-04-19 8:40 ` Christian König
2023-04-23 15:12 ` Jarkko Sakkinen
2023-04-23 15:12 ` Jarkko Sakkinen
2023-04-23 15:12 ` Jarkko Sakkinen
2023-04-18 15:49 ` [PATCH v4 2/6] mm/gup: remove unused vmas parameter from pin_user_pages_remote() Lorenzo Stoakes
2023-04-18 15:49 ` [PATCH v4 3/6] mm/gup: remove vmas parameter from get_user_pages_remote() Lorenzo Stoakes
2023-04-18 15:49 ` Lorenzo Stoakes
2023-04-19 12:05 ` Janosch Frank
2023-04-19 12:05 ` Janosch Frank
2023-04-18 15:49 ` [PATCH v4 4/6] io_uring: rsrc: avoid use of vmas parameter in pin_user_pages() Lorenzo Stoakes
2023-04-18 15:55 ` David Hildenbrand
2023-04-18 15:56 ` David Hildenbrand
2023-04-18 16:25 ` Lorenzo Stoakes
2023-04-19 16:35 ` Jens Axboe
2023-04-19 16:59 ` Jens Axboe
2023-04-19 17:23 ` Lorenzo Stoakes
2023-04-19 17:35 ` Jens Axboe
2023-04-19 17:47 ` Lorenzo Stoakes
2023-04-19 17:51 ` Jens Axboe
2023-04-19 18:18 ` Lorenzo Stoakes
2023-04-19 18:22 ` Jason Gunthorpe
2023-04-19 18:50 ` Lorenzo Stoakes
2023-04-19 18:23 ` Matthew Wilcox
2023-04-19 18:24 ` Jason Gunthorpe
2023-04-19 18:35 ` Matthew Wilcox
2023-04-19 18:45 ` Lorenzo Stoakes
2023-04-19 23:22 ` Jason Gunthorpe [this message]
2023-04-20 13:57 ` Lorenzo Stoakes
2023-04-20 13:36 ` Pavel Begunkov
2023-04-20 14:19 ` Lorenzo Stoakes
2023-04-20 15:31 ` Jason Gunthorpe
2023-04-19 20:15 ` Jens Axboe
2023-04-19 20:18 ` Jens Axboe
2023-04-20 13:37 ` Pavel Begunkov
2023-04-19 17:07 ` Lorenzo Stoakes
2023-04-18 15:49 ` [PATCH v4 5/6] mm/gup: remove vmas parameter from pin_user_pages() Lorenzo Stoakes
2023-04-18 15:49 ` Lorenzo Stoakes
2023-04-18 15:49 ` [PATCH v4 6/6] mm/gup: remove vmas array from internal GUP functions Lorenzo Stoakes
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=ZEB3y0V2GSDcUMc2@nvidia.com \
--to=jgg@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=david@redhat.com \
--cc=io-uring@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=willy@infradead.org \
/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.