public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jens Axboe <[email protected]>
To: Lorenzo Stoakes <[email protected]>,
	[email protected], [email protected],
	Andrew Morton <[email protected]>
Cc: Matthew Wilcox <[email protected]>,
	David Hildenbrand <[email protected]>,
	Pavel Begunkov <[email protected]>,
	[email protected]
Subject: Re: [PATCH v4 4/6] io_uring: rsrc: avoid use of vmas parameter in pin_user_pages()
Date: Wed, 19 Apr 2023 10:35:12 -0600	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <956f4fc2204f23e4c00e9602ded80cb4e7b5df9b.1681831798.git.lstoakes@gmail.com>

On 4/18/23 9:49?AM, Lorenzo Stoakes wrote:
> We are shortly to remove pin_user_pages(), and instead perform the required
> VMA checks ourselves. In most cases there will be a single VMA so this
> should caues no undue impact on an already slow path.
> 
> Doing this eliminates the one instance of vmas being used by
> pin_user_pages().

First up, please don't just send single patches from a series. It's
really annoying when you are trying to get the full picture. Just CC the
whole series, so reviews don't have to look it up separately.

So when you're doing a respin for what I'll mention below and the issue
that David found, please don't just show us patch 4+5 of the series.

> diff --git a/io_uring/rsrc.c b/io_uring/rsrc.c
> index 7a43aed8e395..3a927df9d913 100644
> --- a/io_uring/rsrc.c
> +++ b/io_uring/rsrc.c
> @@ -1138,12 +1138,37 @@ static int io_buffer_account_pin(struct io_ring_ctx *ctx, struct page **pages,
>  	return ret;
>  }
>  
> +static int check_vmas_locked(unsigned long addr, unsigned long len)
> +{
> +	struct file *file;
> +	VMA_ITERATOR(vmi, current->mm, addr);
> +	struct vm_area_struct *vma = vma_next(&vmi);
> +	unsigned long end = addr + len;
> +
> +	if (WARN_ON_ONCE(!vma))
> +		return -EINVAL;
> +
> +	file = vma->vm_file;
> +	if (file && !is_file_hugepages(file))
> +		return -EOPNOTSUPP;
> +
> +	/* don't support file backed memory */
> +	for_each_vma_range(vmi, vma, end) {
> +		if (vma->vm_file != file)
> +			return -EINVAL;
> +
> +		if (file && !vma_is_shmem(vma))
> +			return -EOPNOTSUPP;
> +	}
> +
> +	return 0;
> +}

I really dislike this naming. There's no point to doing locked in the
naming here, it just makes people think it's checking whether the vmas
are locked. Which is not at all what it does. Because what else would we
think, there's nothing else in the name that suggests what it is
actually checking.

Don't put implied locking in the naming, the way to do that is to do
something ala:

lockdep_assert_held_read(&current->mm->mmap_lock);

though I don't think it's needed here at all, as there's just one caller
and it's clearly inside. You could even just make a comment instead.

So please rename this to indicate what it's ACTUALLY checking.

-- 
Jens Axboe


  parent reply	other threads:[~2023-04-19 16:35 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <[email protected]>
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 [this message]
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
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

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] \
    /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