public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jason Gunthorpe <[email protected]>
To: Pavel Begunkov <[email protected]>
Cc: Lorenzo Stoakes <[email protected]>,
	[email protected], [email protected],
	Andrew Morton <[email protected]>,
	Matthew Wilcox <[email protected]>,
	David Hildenbrand <[email protected]>,
	Jens Axboe <[email protected]>,
	[email protected]
Subject: Re: [PATCH 5/7] io_uring: rsrc: use FOLL_SAME_FILE on pin_user_pages()
Date: Tue, 18 Apr 2023 13:36:41 -0300	[thread overview]
Message-ID: <ZD7HGbdBt1XqIDX/@nvidia.com> (raw)
In-Reply-To: <[email protected]>

On Tue, Apr 18, 2023 at 05:25:08PM +0100, Pavel Begunkov wrote:
> On 4/17/23 13:56, Jason Gunthorpe wrote:
> > On Sat, Apr 15, 2023 at 12:27:45AM +0100, Lorenzo Stoakes wrote:
> > > Commit edd478269640 ("io_uring/rsrc: disallow multi-source reg buffers")
> > > prevents io_pin_pages() from pinning pages spanning multiple VMAs with
> > > permitted characteristics (anon/huge), requiring that all VMAs share the
> > > same vm_file.
> > 
> > That commmit doesn't really explain why io_uring is doing such a weird
> > thing.
> > 
> > What exactly is the problem with mixing struct pages from different
> > files and why of all the GUP users does only io_uring need to care
> > about this?
> 
> Simply because it doesn't seem sane to mix and register buffers of
> different "nature" as one. 

That is not a good reason. Once things are converted to struct pages
they don't need to care about their "nature"

> problem. We've been asked just recently to allow registering bufs
> provided mapped by some specific driver, or there might be DMA mapped
> memory in the future.

We already have GUP flags to deal with it, eg FOLL_PCI_P2PDMA

> Rejecting based on vmas might be too conservative, I agree and am all
> for if someone can help to make it right.

It is GUP's problem to deal with this, not the callers.

GUP is defined to return a list of normal CPU DRAM in struct page
format. The caller doesn't care where or what this memory is, it is
all interchangable - by API contract of GUP itself.

If you use FOLL_PCI_P2PDMA then the definition expands to allow struct
pages that are MMIO.

In future, if someone invents new memory or new struct pages with
special needs it is their job to ensure it is blocked from GUP - for
*everyone*. eg how the PCI_P2PDMA was blocked from normal GUP.

io_uring is not special, there are many users of GUP, they all need to
work consistently.

> > Also, why is it doing this?
> 
> There were problems with filesystem mappings, I believe.
> Jens may remember what it was.

Yes, I know about this, but as above, io_uring is not special, if we
want to block this GUP blocks it to protect all users, not io_uring
just protects itself..

Jason

  parent reply	other threads:[~2023-04-18 16:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <[email protected]>
2023-04-14 23:27 ` [PATCH 5/7] io_uring: rsrc: use FOLL_SAME_FILE on pin_user_pages() Lorenzo Stoakes
2023-04-17 12:56   ` Jason Gunthorpe
2023-04-17 13:19     ` Lorenzo Stoakes
2023-04-17 13:26       ` Jason Gunthorpe
2023-04-17 14:00         ` Lorenzo Stoakes
2023-04-17 14:15           ` Jason Gunthorpe
2023-04-17 15:20             ` Lorenzo Stoakes
2023-04-17 19:00         ` Lorenzo Stoakes
2023-04-17 19:24           ` Jason Gunthorpe
2023-04-17 19:45             ` Lorenzo Stoakes
2023-04-18 16:25     ` Pavel Begunkov
2023-04-18 16:35       ` Pavel Begunkov
2023-04-18 16:36       ` Jason Gunthorpe [this message]
2023-04-18 17:25         ` Pavel Begunkov
2023-04-18 18:19           ` Jason Gunthorpe
2023-04-14 23:27 ` [PATCH 6/7] mm/gup: remove vmas parameter from pin_user_pages() 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=ZD7HGbdBt1XqIDX/@nvidia.com \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox