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 09:56:34 -0300 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <17357dec04b32593b71e4fdf3c30a346020acf98.1681508038.git.lstoakes@gmail.com>
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?
If there is no justification then lets revert that commit instead.
> /* don't support file backed memory */
> - for (i = 0; i < nr_pages; i++) {
> - if (vmas[i]->vm_file != file) {
> - ret = -EINVAL;
> - break;
> - }
> - if (!file)
> - continue;
> - if (!vma_is_shmem(vmas[i]) && !is_file_hugepages(file)) {
> - ret = -EOPNOTSUPP;
> - break;
> - }
> - }
> + file = vma->vm_file;
> + if (file && !vma_is_shmem(vma) && !is_file_hugepages(file))
> + ret = -EOPNOTSUPP;
> +
Also, why is it doing this?
All GUP users don't work entirely right for any fops implementation
that assumes write protect is unconditionally possible. eg most
filesystems.
We've been ignoring blocking it because it is an ABI break and it does
sort of work in some cases.
I'd rather see something like FOLL_ALLOW_BROKEN_FILE_MAPPINGS than
io_uring open coding this kind of stuff.
Jason
next prev parent reply other threads:[~2023-04-17 12:56 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 [this message]
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
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