Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: dave.hansen at intel.com (Dave Hansen)
Subject: [PATCH v10 04/12] mm, arm64: untag user pointers passed to memory syscalls
Date: Fri, 22 Feb 2019 15:07:45 -0800	[thread overview]
Message-ID: <81ea4e77-90a4-4fd9-2bc8-135e0da30044@intel.com> (raw)
In-Reply-To: <3875fa863b755d8cb43afa7bb0fe543e5fd05a5d.1550839937.git.andreyknvl@google.com>

On 2/22/19 4:53 AM, Andrey Konovalov wrote:
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@ -578,6 +578,7 @@ static int do_mprotect_pkey(unsigned long start, size_t len,
>  SYSCALL_DEFINE3(mprotect, unsigned long, start, size_t, len,
>  		unsigned long, prot)
>  {
> +	start = untagged_addr(start);
>  	return do_mprotect_pkey(start, len, prot, -1);
>  }
>  
> @@ -586,6 +587,7 @@ SYSCALL_DEFINE3(mprotect, unsigned long, start, size_t, len,
>  SYSCALL_DEFINE4(pkey_mprotect, unsigned long, start, size_t, len,
>  		unsigned long, prot, int, pkey)
>  {
> +	start = untagged_addr(start);
>  	return do_mprotect_pkey(start, len, prot, pkey);
>  }

This seems to have taken the approach of going as close as possible to
the syscall boundary and untagging the pointer there.  I guess that's
OK, but it does lead to more churn than necessary.  For instance, why
not just do the untagging in do_mprotect_pkey()?

I think that's an overall design question.  I kinda asked the same thing
about patching call sites vs. VMA lookup functions.

WARNING: multiple messages have this Message-ID (diff)
From: dave.hansen@intel.com (Dave Hansen)
Subject: [PATCH v10 04/12] mm, arm64: untag user pointers passed to memory syscalls
Date: Fri, 22 Feb 2019 15:07:45 -0800	[thread overview]
Message-ID: <81ea4e77-90a4-4fd9-2bc8-135e0da30044@intel.com> (raw)
Message-ID: <20190222230745.G2VEauQ3n1q3xDY5LS8lwtFubR7lPLKQcyU86Crey90@z> (raw)
In-Reply-To: <3875fa863b755d8cb43afa7bb0fe543e5fd05a5d.1550839937.git.andreyknvl@google.com>

On 2/22/19 4:53 AM, Andrey Konovalov wrote:
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@ -578,6 +578,7 @@ static int do_mprotect_pkey(unsigned long start, size_t len,
>  SYSCALL_DEFINE3(mprotect, unsigned long, start, size_t, len,
>  		unsigned long, prot)
>  {
> +	start = untagged_addr(start);
>  	return do_mprotect_pkey(start, len, prot, -1);
>  }
>  
> @@ -586,6 +587,7 @@ SYSCALL_DEFINE3(mprotect, unsigned long, start, size_t, len,
>  SYSCALL_DEFINE4(pkey_mprotect, unsigned long, start, size_t, len,
>  		unsigned long, prot, int, pkey)
>  {
> +	start = untagged_addr(start);
>  	return do_mprotect_pkey(start, len, prot, pkey);
>  }

This seems to have taken the approach of going as close as possible to
the syscall boundary and untagging the pointer there.  I guess that's
OK, but it does lead to more churn than necessary.  For instance, why
not just do the untagging in do_mprotect_pkey()?

I think that's an overall design question.  I kinda asked the same thing
about patching call sites vs. VMA lookup functions.

  parent reply	other threads:[~2019-02-22 23:07 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-22 12:53 [PATCH v10 00/12] arm64: untag user pointers passed to the kernel andreyknvl
2019-02-22 12:53 ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 01/12] uaccess: add untagged_addr definition for other arches andreyknvl
2019-02-22 12:53   ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 02/12] arm64: untag user pointers in access_ok and __uaccess_mask_ptr andreyknvl
2019-02-22 12:53   ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 03/12] lib, arm64: untag user pointers in strn*_user andreyknvl
2019-02-22 12:53   ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 04/12] mm, arm64: untag user pointers passed to memory syscalls andreyknvl
2019-02-22 12:53   ` Andrey Konovalov
2019-02-22 23:07   ` dave.hansen [this message]
2019-02-22 23:07     ` Dave Hansen
2019-02-26 14:41     ` andreyknvl
2019-02-26 14:41       ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 05/12] mm, arm64: untag user pointers in mm/gup.c andreyknvl
2019-02-22 12:53   ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 06/12] fs, arm64: untag user pointers in copy_mount_options andreyknvl
2019-02-22 12:53   ` Andrey Konovalov
2019-02-22 23:03   ` dave.hansen
2019-02-22 23:03     ` Dave Hansen
2019-02-26 14:35     ` andreyknvl
2019-02-26 14:35       ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 07/12] fs, arm64: untag user pointers in fs/userfaultfd.c andreyknvl
2019-02-22 12:53   ` Andrey Konovalov
2019-02-22 23:05   ` dave.hansen
2019-02-22 23:05     ` Dave Hansen
2019-02-26 14:39     ` andreyknvl
2019-02-26 14:39       ` Andrey Konovalov
2019-03-01 16:59       ` catalin.marinas
2019-03-01 16:59         ` Catalin Marinas
2019-03-01 18:37         ` dave.hansen
2019-03-01 18:37           ` Dave Hansen
2019-03-05 17:47           ` andreyknvl
2019-03-05 17:47             ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 08/12] net, arm64: untag user pointers in tcp_zerocopy_receive andreyknvl
2019-02-22 12:53   ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 09/12] kernel, arm64: untag user pointers in prctl_set_mm* andreyknvl
2019-02-22 12:53   ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 10/12] tracing, arm64: untag user pointers in seq_print_user_ip andreyknvl
2019-02-22 12:53   ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 11/12] arm64: update Documentation/arm64/tagged-pointers.txt andreyknvl
2019-02-22 12:53   ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 12/12] selftests, arm64: add a selftest for passing tagged pointers to kernel andreyknvl
2019-02-22 12:53   ` Andrey Konovalov
2019-02-22 15:35 ` [PATCH v10 00/12] arm64: untag user pointers passed to the kernel Szabolcs.Nagy
2019-02-22 15:35   ` Szabolcs Nagy
2019-02-22 15:40   ` andreyknvl
2019-02-22 15:40     ` Andrey Konovalov
2019-02-22 16:10     ` Szabolcs.Nagy
2019-02-22 16:10       ` Szabolcs Nagy
2019-02-26 17:00       ` andreyknvl
2019-02-26 17:00         ` Andrey Konovalov
2019-02-22 22:54 ` dave.hansen
2019-02-22 22:54   ` Dave Hansen
2019-02-26 17:18   ` andreyknvl
2019-02-26 17:18     ` Andrey Konovalov
2019-02-26 17:35     ` dave.hansen
2019-02-26 17:35       ` Dave Hansen
2019-02-26 23:17     ` luc.vanoostenryck
2019-02-26 23:17       ` Luc Van Oostenryck

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=81ea4e77-90a4-4fd9-2bc8-135e0da30044@intel.com \
    --to=linux-kselftest@vger.kernel.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