public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jason Gunthorpe <[email protected]>
To: Lorenzo Stoakes <[email protected]>
Cc: [email protected], [email protected],
	Andrew Morton <[email protected]>,
	Matthew Wilcox <[email protected]>,
	David Hildenbrand <[email protected]>,
	Jens Axboe <[email protected]>,
	Pavel Begunkov <[email protected]>,
	[email protected]
Subject: Re: [PATCH 5/7] io_uring: rsrc: use FOLL_SAME_FILE on pin_user_pages()
Date: Mon, 17 Apr 2023 10:26:09 -0300	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On Mon, Apr 17, 2023 at 02:19:16PM +0100, Lorenzo Stoakes wrote:

> > I'd rather see something like FOLL_ALLOW_BROKEN_FILE_MAPPINGS than
> > io_uring open coding this kind of stuff.
> >
> 
> How would the semantics of this work? What is broken? It is a little
> frustrating that we have FOLL_ANON but hugetlb as an outlying case, adding
> FOLL_ANON_OR_HUGETLB was another consideration...

It says "historically this user has accepted file backed pages and we
we think there may actually be users doing that, so don't break the
uABI"

Without the flag GUP would refuse to return file backed pages that can
trigger kernel crashes or data corruption.

Eg we'd want most places to not specify the flag and the few that do
to have some justification.

We should consdier removing FOLL_ANON, I'm not sure it really makes
sense these days for what proc is doing with it. All that proc stuff
could likely be turned into a kthread_use_mm() and a simple
copy_to/from user?

I suspect that eliminates the need to check for FOLL_ANON?

Jason

  reply	other threads:[~2023-04-17 13:26 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 [this message]
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
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 \
    [email protected] \
    [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