From: Peter Xu <peterx@redhat.com>
To: Axel Rasmussen <axelrasmussen@google.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Hugh Dickins <hughd@google.com>, Jan Kara <jack@suse.cz>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Matthew Wilcox <willy@infradead.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
Mike Rapoport <rppt@kernel.org>,
Muchun Song <muchun.song@linux.dev>,
Nadav Amit <namit@vmware.com>, Shuah Khan <shuah@kernel.org>,
James Houghton <jthoughton@google.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v3 4/5] mm: userfaultfd: don't separate addr + len arguments
Date: Mon, 6 Mar 2023 20:19:56 -0500 [thread overview]
Message-ID: <ZAaRPCntR94hGBL2@x1n> (raw)
In-Reply-To: <20230306225024.264858-5-axelrasmussen@google.com>
On Mon, Mar 06, 2023 at 02:50:23PM -0800, Axel Rasmussen wrote:
> We have a lot of functions which take an address + length pair,
> currently passed as separate arguments. However, in our userspace API we
> already have struct uffdio_range, which is exactly this pair, and this
> is what we get from userspace when ioctls are called.
>
> Instead of splitting the struct up into two separate arguments, just
> plumb the struct through to the functions which use it (once we get to
> the mfill_atomic_pte level, we're dealing with single (huge)pages, so we
> don't need both parts).
>
> Relatedly, for waking, just re-use this existing structure instead of
> defining a new "struct uffdio_wake_range".
>
> Signed-off-by: Axel Rasmussen <axelrasmussen@google.com>
> ---
> fs/userfaultfd.c | 107 +++++++++++++---------------------
> include/linux/userfaultfd_k.h | 17 +++---
> mm/userfaultfd.c | 92 ++++++++++++++---------------
> 3 files changed, 96 insertions(+), 120 deletions(-)
>
> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> index b8e328123b71..984b63b0fc75 100644
> --- a/fs/userfaultfd.c
> +++ b/fs/userfaultfd.c
> @@ -95,11 +95,6 @@ struct userfaultfd_wait_queue {
> bool waken;
> };
>
> -struct userfaultfd_wake_range {
> - unsigned long start;
> - unsigned long len;
> -};
Would there still be a difference on e.g. 32 bits systems?
[...]
> static __always_inline int validate_range(struct mm_struct *mm,
> - __u64 start, __u64 len)
> + const struct uffdio_range *range)
> {
> __u64 task_size = mm->task_size;
>
> - if (start & ~PAGE_MASK)
> + if (range->start & ~PAGE_MASK)
> return -EINVAL;
> - if (len & ~PAGE_MASK)
> + if (range->len & ~PAGE_MASK)
> return -EINVAL;
> - if (!len)
> + if (!range->len)
> return -EINVAL;
> - if (start < mmap_min_addr)
> + if (range->start < mmap_min_addr)
> return -EINVAL;
> - if (start >= task_size)
> + if (range->start >= task_size)
> return -EINVAL;
> - if (len > task_size - start)
> + if (range->len > task_size - range->start)
> return -EINVAL;
> return 0;
> }
Personally I don't like a lot on such a change. :( It avoids one parameter
being passed over but it can add a lot indirections.
Do you strongly suggest this? Shall we move on without this so to not
block the last patch (which I assume is the one you're looking for)?
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2023-03-07 1:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-06 22:50 [PATCH v3 0/5] mm: userfaultfd: refactor and add UFFDIO_CONTINUE_MODE_WP Axel Rasmussen
2023-03-06 22:50 ` [PATCH v3 1/5] mm: userfaultfd: rename functions for clarity + consistency Axel Rasmussen
2023-03-07 1:03 ` Peter Xu
2023-03-06 22:50 ` [PATCH v3 2/5] mm: userfaultfd: don't pass around both mm and vma Axel Rasmussen
2023-03-07 1:03 ` Peter Xu
2023-03-07 1:44 ` Nadav Amit
2023-03-08 15:08 ` Peter Xu
2023-03-06 22:50 ` [PATCH v3 3/5] mm: userfaultfd: combine 'mode' and 'wp_copy' arguments Axel Rasmussen
2023-03-07 1:00 ` Peter Xu
2023-03-07 23:27 ` Axel Rasmussen
2023-03-08 15:17 ` Peter Xu
2023-03-07 1:54 ` Nadav Amit
2023-03-06 22:50 ` [PATCH v3 4/5] mm: userfaultfd: don't separate addr + len arguments Axel Rasmussen
2023-03-07 1:19 ` Peter Xu [this message]
2023-03-07 1:29 ` Nadav Amit
2023-03-08 9:51 ` kernel test robot
2023-03-08 18:48 ` Axel Rasmussen
2023-03-06 22:50 ` [PATCH v3 5/5] mm: userfaultfd: add UFFDIO_CONTINUE_MODE_WP to install WP PTEs Axel Rasmussen
2023-03-07 1:23 ` Peter Xu
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=ZAaRPCntR94hGBL2@x1n \
--to=peterx@redhat.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=jthoughton@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=muchun.song@linux.dev \
--cc=namit@vmware.com \
--cc=rppt@kernel.org \
--cc=shuah@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).