All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Andrey Konovalov <andreyknvl@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Will Deacon <will.deacon@arm.com>,
	Linux Memory Management List <linux-mm@kvack.org>,
	"open list:KERNEL SELFTEST FRAMEWORK"
	<linux-kselftest@vger.kernel.org>,
	Chintan Pandya <cpandya@codeaurora.org>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Shuah Khan <shuah@kernel.org>, Ingo Molnar <mingo@kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Jacob Bramley <Jacob.Bramley@arm.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Evgenii Stepanov <eugenis@google.com>,
	Kees Cook <keescook@chromium.org>,
	Ruben Ayrapetyan <Ruben.Ayrapetyan@arm.com>,
	Lee Smith <Lee.Smith@arm.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [RFC][PATCH 0/3] arm64 relaxed ABI
Date: Tue, 18 Dec 2018 17:59:38 +0000	[thread overview]
Message-ID: <20181218175938.GD20197@arrakis.emea.arm.com> (raw)
In-Reply-To: <CAAeHK+zxYJDJ7DJuDAOuOMgGvckFwMAoVUTDJzb6MX3WsXhRTQ@mail.gmail.com>

On Tue, Dec 18, 2018 at 04:03:38PM +0100, Andrey Konovalov wrote:
> On Wed, Dec 12, 2018 at 4:02 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
> > The summary of our internal discussions (mostly between kernel
> > developers) is that we can't properly describe a user ABI that covers
> > future syscalls or syscall extensions while not all syscalls accept
> > tagged pointers. So we tweaked the requirements slightly to only allow
> > tagged pointers back into the kernel *if* the originating address is
> > from an anonymous mmap() or below sbrk(0). This should cover some of the
> > ioctls or getsockopt(TCP_ZEROCOPY_RECEIVE) where the user passes a
> > pointer to a buffer obtained via mmap() on the device operations.
> >
> > (sorry for not being clear on what Vincenzo's proposal implies)
> 
> OK, I see. So I need to make the following changes to my patchset AFAIU.
> 
> 1. Make sure that we only allow tagged user addresses that originate
> from an anonymous mmap() or below sbrk(0). How exactly should this
> check be performed?

I don't think we should perform such checks. That's rather stating that
the kernel only guarantees that the tagged pointers work if they
originated from these memory ranges.

> 2. Allow tagged addressed passed to memory syscalls (as long as (1) is
> satisfied). Do I understand correctly that this means that I need to
> locate all find_vma() callers outside of mm/ and fix them up as well?

Yes (unless anyone as a better idea or objections to this approach).

BTW, I'll be off until the new year, so won't be able to follow up.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Andrey Konovalov <andreyknvl@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Will Deacon <will.deacon@arm.com>,
	Linux Memory Management List <linux-mm@kvack.org>,
	"open list:KERNEL SELFTEST FRAMEWORK"
	<linux-kselftest@vger.kernel.org>,
	Chintan Pandya <cpandya@codeaurora.org>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Shuah Khan <shuah@kernel.org>, Ingo Molnar <mingo@kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Jacob Bramley <Jacob.Bramley@arm.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Evgenii Stepanov <eugenis@google.com>,
	Kees Cook <keescook@chromium.org>,
	Ruben Ayrapetyan <Ruben.Ayrapetyan@arm.com>,
	Lee Smith <Lee.Smith@arm.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Kostya Serebryany <kcc@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Subject: Re: [RFC][PATCH 0/3] arm64 relaxed ABI
Date: Tue, 18 Dec 2018 17:59:38 +0000	[thread overview]
Message-ID: <20181218175938.GD20197@arrakis.emea.arm.com> (raw)
Message-ID: <20181218175938.0QtJnzo1t0LXeR4NXZNLSwlrgGGPs9G1iPmTaubxCQA@z> (raw)
In-Reply-To: <CAAeHK+zxYJDJ7DJuDAOuOMgGvckFwMAoVUTDJzb6MX3WsXhRTQ@mail.gmail.com>

On Tue, Dec 18, 2018 at 04:03:38PM +0100, Andrey Konovalov wrote:
> On Wed, Dec 12, 2018 at 4:02 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
> > The summary of our internal discussions (mostly between kernel
> > developers) is that we can't properly describe a user ABI that covers
> > future syscalls or syscall extensions while not all syscalls accept
> > tagged pointers. So we tweaked the requirements slightly to only allow
> > tagged pointers back into the kernel *if* the originating address is
> > from an anonymous mmap() or below sbrk(0). This should cover some of the
> > ioctls or getsockopt(TCP_ZEROCOPY_RECEIVE) where the user passes a
> > pointer to a buffer obtained via mmap() on the device operations.
> >
> > (sorry for not being clear on what Vincenzo's proposal implies)
> 
> OK, I see. So I need to make the following changes to my patchset AFAIU.
> 
> 1. Make sure that we only allow tagged user addresses that originate
> from an anonymous mmap() or below sbrk(0). How exactly should this
> check be performed?

I don't think we should perform such checks. That's rather stating that
the kernel only guarantees that the tagged pointers work if they
originated from these memory ranges.

> 2. Allow tagged addressed passed to memory syscalls (as long as (1) is
> satisfied). Do I understand correctly that this means that I need to
> locate all find_vma() callers outside of mm/ and fix them up as well?

Yes (unless anyone as a better idea or objections to this approach).

BTW, I'll be off until the new year, so won't be able to follow up.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas at arm.com (Catalin Marinas)
Subject: [RFC][PATCH 0/3] arm64 relaxed ABI
Date: Tue, 18 Dec 2018 17:59:38 +0000	[thread overview]
Message-ID: <20181218175938.GD20197@arrakis.emea.arm.com> (raw)
In-Reply-To: <CAAeHK+zxYJDJ7DJuDAOuOMgGvckFwMAoVUTDJzb6MX3WsXhRTQ@mail.gmail.com>

On Tue, Dec 18, 2018 at 04:03:38PM +0100, Andrey Konovalov wrote:
> On Wed, Dec 12, 2018 at 4:02 PM Catalin Marinas <catalin.marinas at arm.com> wrote:
> > The summary of our internal discussions (mostly between kernel
> > developers) is that we can't properly describe a user ABI that covers
> > future syscalls or syscall extensions while not all syscalls accept
> > tagged pointers. So we tweaked the requirements slightly to only allow
> > tagged pointers back into the kernel *if* the originating address is
> > from an anonymous mmap() or below sbrk(0). This should cover some of the
> > ioctls or getsockopt(TCP_ZEROCOPY_RECEIVE) where the user passes a
> > pointer to a buffer obtained via mmap() on the device operations.
> >
> > (sorry for not being clear on what Vincenzo's proposal implies)
> 
> OK, I see. So I need to make the following changes to my patchset AFAIU.
> 
> 1. Make sure that we only allow tagged user addresses that originate
> from an anonymous mmap() or below sbrk(0). How exactly should this
> check be performed?

I don't think we should perform such checks. That's rather stating that
the kernel only guarantees that the tagged pointers work if they
originated from these memory ranges.

> 2. Allow tagged addressed passed to memory syscalls (as long as (1) is
> satisfied). Do I understand correctly that this means that I need to
> locate all find_vma() callers outside of mm/ and fix them up as well?

Yes (unless anyone as a better idea or objections to this approach).

BTW, I'll be off until the new year, so won't be able to follow up.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas@arm.com (Catalin Marinas)
Subject: [RFC][PATCH 0/3] arm64 relaxed ABI
Date: Tue, 18 Dec 2018 17:59:38 +0000	[thread overview]
Message-ID: <20181218175938.GD20197@arrakis.emea.arm.com> (raw)
Message-ID: <20181218175938.piIAmPRH4r-Z-z1PPx4mpQDPiX-Dn7BXFGy1kcLkfyI@z> (raw)
In-Reply-To: <CAAeHK+zxYJDJ7DJuDAOuOMgGvckFwMAoVUTDJzb6MX3WsXhRTQ@mail.gmail.com>

On Tue, Dec 18, 2018@04:03:38PM +0100, Andrey Konovalov wrote:
> On Wed, Dec 12, 2018@4:02 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
> > The summary of our internal discussions (mostly between kernel
> > developers) is that we can't properly describe a user ABI that covers
> > future syscalls or syscall extensions while not all syscalls accept
> > tagged pointers. So we tweaked the requirements slightly to only allow
> > tagged pointers back into the kernel *if* the originating address is
> > from an anonymous mmap() or below sbrk(0). This should cover some of the
> > ioctls or getsockopt(TCP_ZEROCOPY_RECEIVE) where the user passes a
> > pointer to a buffer obtained via mmap() on the device operations.
> >
> > (sorry for not being clear on what Vincenzo's proposal implies)
> 
> OK, I see. So I need to make the following changes to my patchset AFAIU.
> 
> 1. Make sure that we only allow tagged user addresses that originate
> from an anonymous mmap() or below sbrk(0). How exactly should this
> check be performed?

I don't think we should perform such checks. That's rather stating that
the kernel only guarantees that the tagged pointers work if they
originated from these memory ranges.

> 2. Allow tagged addressed passed to memory syscalls (as long as (1) is
> satisfied). Do I understand correctly that this means that I need to
> locate all find_vma() callers outside of mm/ and fix them up as well?

Yes (unless anyone as a better idea or objections to this approach).

BTW, I'll be off until the new year, so won't be able to follow up.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Andrey Konovalov <andreyknvl@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Will Deacon <will.deacon@arm.com>,
	Kostya Serebryany <kcc@google.com>,
	"open list:KERNEL SELFTEST FRAMEWORK"
	<linux-kselftest@vger.kernel.org>,
	Chintan Pandya <cpandya@codeaurora.org>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Shuah Khan <shuah@kernel.org>, Ingo Molnar <mingo@kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Jacob Bramley <Jacob.Bramley@arm.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Evgenii Stepanov <eugenis@google.com>,
	Kees Cook <keescook@chromium.org>,
	Ruben Ayrapetyan <Ruben.Ayrapetyan@arm.com>,
	Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
	Lee Smith <Lee.Smith@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Robin Murphy <robin.murphy@arm.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [RFC][PATCH 0/3] arm64 relaxed ABI
Date: Tue, 18 Dec 2018 17:59:38 +0000	[thread overview]
Message-ID: <20181218175938.GD20197@arrakis.emea.arm.com> (raw)
In-Reply-To: <CAAeHK+zxYJDJ7DJuDAOuOMgGvckFwMAoVUTDJzb6MX3WsXhRTQ@mail.gmail.com>

On Tue, Dec 18, 2018 at 04:03:38PM +0100, Andrey Konovalov wrote:
> On Wed, Dec 12, 2018 at 4:02 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
> > The summary of our internal discussions (mostly between kernel
> > developers) is that we can't properly describe a user ABI that covers
> > future syscalls or syscall extensions while not all syscalls accept
> > tagged pointers. So we tweaked the requirements slightly to only allow
> > tagged pointers back into the kernel *if* the originating address is
> > from an anonymous mmap() or below sbrk(0). This should cover some of the
> > ioctls or getsockopt(TCP_ZEROCOPY_RECEIVE) where the user passes a
> > pointer to a buffer obtained via mmap() on the device operations.
> >
> > (sorry for not being clear on what Vincenzo's proposal implies)
> 
> OK, I see. So I need to make the following changes to my patchset AFAIU.
> 
> 1. Make sure that we only allow tagged user addresses that originate
> from an anonymous mmap() or below sbrk(0). How exactly should this
> check be performed?

I don't think we should perform such checks. That's rather stating that
the kernel only guarantees that the tagged pointers work if they
originated from these memory ranges.

> 2. Allow tagged addressed passed to memory syscalls (as long as (1) is
> satisfied). Do I understand correctly that this means that I need to
> locate all find_vma() callers outside of mm/ and fix them up as well?

Yes (unless anyone as a better idea or objections to this approach).

BTW, I'll be off until the new year, so won't be able to follow up.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2018-12-18 17:59 UTC|newest]

Thread overview: 173+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-10 12:50 [PATCH v9 0/8] arm64: untag user pointers passed to the kernel Andrey Konovalov
2018-12-10 12:50 ` Andrey Konovalov
2018-12-10 12:50 ` Andrey Konovalov
2018-12-10 12:50 ` andreyknvl
2018-12-10 12:50 ` [PATCH v9 1/8] arm64: add type casts to untagged_addr macro Andrey Konovalov
2018-12-10 12:50   ` Andrey Konovalov
2018-12-10 12:50   ` Andrey Konovalov
2018-12-10 12:50   ` andreyknvl
2018-12-10 12:50 ` [PATCH v9 2/8] uaccess: add untagged_addr definition for other arches Andrey Konovalov
2018-12-10 12:50   ` Andrey Konovalov
2018-12-10 12:50   ` Andrey Konovalov
2018-12-10 12:50   ` andreyknvl
2018-12-10 12:51 ` [PATCH v9 3/8] arm64: untag user addresses in access_ok and __uaccess_mask_ptr Andrey Konovalov
2018-12-10 12:51   ` Andrey Konovalov
2018-12-10 12:51   ` Andrey Konovalov
2018-12-10 12:51   ` andreyknvl
2018-12-10 12:51   ` Andrey Konovalov
2018-12-10 12:51 ` [PATCH v9 4/8] mm, arm64: untag user addresses in mm/gup.c Andrey Konovalov
2018-12-10 12:51   ` Andrey Konovalov
2018-12-10 12:51   ` Andrey Konovalov
2018-12-10 12:51   ` andreyknvl
2018-12-10 12:51 ` [PATCH v9 5/8] lib, arm64: untag addrs passed to strncpy_from_user and strnlen_user Andrey Konovalov
2018-12-10 12:51   ` Andrey Konovalov
2018-12-10 12:51   ` Andrey Konovalov
2018-12-10 12:51   ` andreyknvl
2018-12-10 12:51 ` [PATCH v9 6/8] fs, arm64: untag user address in copy_mount_options Andrey Konovalov
2018-12-10 12:51   ` Andrey Konovalov
2018-12-10 12:51   ` Andrey Konovalov
2018-12-10 12:51   ` andreyknvl
2018-12-10 12:51 ` [PATCH v9 7/8] arm64: update Documentation/arm64/tagged-pointers.txt Andrey Konovalov
2018-12-10 12:51   ` Andrey Konovalov
2018-12-10 12:51   ` Andrey Konovalov
2018-12-10 12:51   ` andreyknvl
2018-12-10 12:51 ` [PATCH v9 8/8] selftests, arm64: add a selftest for passing tagged pointers to kernel Andrey Konovalov
2018-12-10 12:51   ` Andrey Konovalov
2018-12-10 12:51   ` Andrey Konovalov
2018-12-10 12:51   ` andreyknvl
2018-12-10 14:30 ` [RFC][PATCH 0/3] arm64 relaxed ABI Vincenzo Frascino
2018-12-10 14:30   ` Vincenzo Frascino
2018-12-10 14:30   ` Vincenzo Frascino
2018-12-10 14:30   ` vincenzo.frascino
2018-12-10 14:30   ` Vincenzo Frascino
2018-12-10 14:30   ` [RFC][PATCH 1/3] elf: Make AT_FLAGS arch configurable Vincenzo Frascino
2018-12-10 14:30     ` Vincenzo Frascino
2018-12-10 14:30     ` Vincenzo Frascino
2018-12-10 14:30     ` vincenzo.frascino
2018-12-10 14:30     ` Vincenzo Frascino
2018-12-10 14:30   ` [RFC][PATCH 2/3] arm64: Define Documentation/arm64/elf_at_flags.txt Vincenzo Frascino
2018-12-10 14:30     ` Vincenzo Frascino
2018-12-10 14:30     ` Vincenzo Frascino
2018-12-10 14:30     ` vincenzo.frascino
2018-12-10 14:30     ` Vincenzo Frascino
2018-12-12 17:34     ` Dave Martin
2018-12-12 17:34       ` Dave Martin
2018-12-12 17:34       ` Dave Martin
2018-12-12 17:34       ` Dave.Martin
2018-12-12 17:34       ` Dave Martin
2019-01-09 13:05       ` Vincenzo Frascino
2019-01-09 13:05         ` Vincenzo Frascino
2019-01-09 13:05         ` Vincenzo Frascino
2019-01-09 13:05         ` vincenzo.frascino
2019-01-09 13:05         ` Vincenzo Frascino
2018-12-10 14:30   ` [RFC][PATCH 3/3] arm64: elf: Advertise relaxed ABI Vincenzo Frascino
2018-12-10 14:30     ` Vincenzo Frascino
2018-12-10 14:30     ` Vincenzo Frascino
2018-12-10 14:30     ` vincenzo.frascino
2018-12-10 14:30     ` Vincenzo Frascino
2018-12-12 14:23   ` [RFC][PATCH 0/3] arm64 " Andrey Konovalov
2018-12-12 14:23     ` Andrey Konovalov
2018-12-12 14:23     ` Andrey Konovalov
2018-12-12 14:23     ` andreyknvl
2018-12-12 14:23     ` Andrey Konovalov
2018-12-12 15:02     ` Catalin Marinas
2018-12-12 15:02       ` Catalin Marinas
2018-12-12 15:02       ` Catalin Marinas
2018-12-12 15:02       ` catalin.marinas
2018-12-12 15:02       ` Catalin Marinas
2018-12-18 15:03       ` Andrey Konovalov
2018-12-18 15:03         ` Andrey Konovalov
2018-12-18 15:03         ` Andrey Konovalov
2018-12-18 15:03         ` andreyknvl
2018-12-18 15:03         ` Andrey Konovalov
2018-12-18 17:59         ` Catalin Marinas [this message]
2018-12-18 17:59           ` Catalin Marinas
2018-12-18 17:59           ` Catalin Marinas
2018-12-18 17:59           ` catalin.marinas
2018-12-18 17:59           ` Catalin Marinas
2018-12-19 12:52           ` Dave Martin
2018-12-19 12:52             ` Dave Martin
2018-12-19 12:52             ` Dave Martin
2018-12-19 12:52             ` Dave.Martin
2018-12-19 12:52             ` Dave Martin
2019-02-11 17:28             ` Kevin Brodsky
2019-02-11 17:28               ` Kevin Brodsky
2019-02-11 17:28               ` Kevin Brodsky
2019-02-11 17:28               ` kevin.brodsky
2019-02-11 17:28               ` Kevin Brodsky
2019-02-11 20:32               ` Evgenii Stepanov
2019-02-11 20:32                 ` Evgenii Stepanov
2019-02-11 20:32                 ` Evgenii Stepanov
2019-02-11 20:32                 ` eugenis
2019-02-11 20:32                 ` Evgenii Stepanov
2019-02-12 18:02                 ` Catalin Marinas
2019-02-12 18:02                   ` Catalin Marinas
2019-02-12 18:02                   ` Catalin Marinas
2019-02-12 18:02                   ` catalin.marinas
2019-02-12 18:02                   ` Catalin Marinas
2019-02-13 14:58                   ` Dave Martin
2019-02-13 14:58                     ` Dave Martin
2019-02-13 14:58                     ` Dave Martin
2019-02-13 14:58                     ` Dave.Martin
2019-02-13 14:58                     ` Dave Martin
2019-02-13 16:42                     ` Kevin Brodsky
2019-02-13 16:42                       ` Kevin Brodsky
2019-02-13 16:42                       ` Kevin Brodsky
2019-02-13 16:42                       ` kevin.brodsky
2019-02-13 16:42                       ` Kevin Brodsky
2019-02-13 16:42                       ` Kevin Brodsky
2019-02-13 17:43                       ` Dave Martin
2019-02-13 17:43                         ` Dave Martin
2019-02-13 17:43                         ` Dave Martin
2019-02-13 17:43                         ` Dave.Martin
2019-02-13 17:43                         ` Dave Martin
2019-02-13 21:41                         ` Evgenii Stepanov
2019-02-13 21:41                           ` Evgenii Stepanov
2019-02-13 21:41                           ` Evgenii Stepanov
2019-02-13 21:41                           ` eugenis
2019-02-13 21:41                           ` Evgenii Stepanov
2019-02-14 11:22                           ` Kevin Brodsky
2019-02-14 11:22                             ` Kevin Brodsky
2019-02-14 11:22                             ` Kevin Brodsky
2019-02-14 11:22                             ` kevin.brodsky
2019-02-14 11:22                             ` Kevin Brodsky
2019-02-19 18:38                   ` Szabolcs Nagy
2019-02-19 18:38                     ` Szabolcs Nagy
2019-02-19 18:38                     ` Szabolcs Nagy
2019-02-19 18:38                     ` Szabolcs.Nagy
2019-02-19 18:38                     ` Szabolcs Nagy
2019-02-25 16:57                     ` Catalin Marinas
2019-02-25 16:57                       ` Catalin Marinas
2019-02-25 16:57                       ` Catalin Marinas
2019-02-25 16:57                       ` catalin.marinas
2019-02-25 16:57                       ` Catalin Marinas
2019-02-25 18:02                       ` Szabolcs Nagy
2019-02-25 18:02                         ` Szabolcs Nagy
2019-02-25 18:02                         ` Szabolcs Nagy
2019-02-25 18:02                         ` Szabolcs.Nagy
2019-02-25 18:02                         ` Szabolcs Nagy
2019-02-26 17:30                         ` Kevin Brodsky
2019-02-26 17:30                           ` Kevin Brodsky
2019-02-26 17:30                           ` Kevin Brodsky
2019-02-26 17:30                           ` kevin.brodsky
2019-02-26 17:30                           ` Kevin Brodsky
2018-12-12 17:01 ` [PATCH v9 0/8] arm64: untag user pointers passed to the kernel Dave Martin
2018-12-12 17:01   ` Dave Martin
2018-12-12 17:01   ` Dave Martin
2018-12-12 17:01   ` Dave.Martin
2018-12-12 17:01   ` Dave Martin
2018-12-18 17:17   ` Andrey Konovalov
2018-12-18 17:17     ` Andrey Konovalov
2018-12-18 17:17     ` Andrey Konovalov
2018-12-18 17:17     ` andreyknvl
2018-12-18 17:17     ` Andrey Konovalov
2019-02-11 11:35   ` Catalin Marinas
2019-02-11 11:35     ` Catalin Marinas
2019-02-11 11:35     ` Catalin Marinas
2019-02-11 11:35     ` catalin.marinas
2019-02-11 11:35     ` Catalin Marinas
2019-02-11 17:02     ` Dave Martin
2019-02-11 17:02       ` Dave Martin
2019-02-11 17:02       ` Dave Martin
2019-02-11 17:02       ` Dave.Martin
2019-02-11 17:02       ` Dave Martin

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=20181218175938.GD20197@arrakis.emea.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=Jacob.Bramley@arm.com \
    --cc=Lee.Smith@arm.com \
    --cc=Ruben.Ayrapetyan@arm.com \
    --cc=andreyknvl@google.com \
    --cc=cpandya@codeaurora.org \
    --cc=dvyukov@google.com \
    --cc=eugenis@google.com \
    --cc=keescook@chromium.org \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@kernel.org \
    --cc=shuah@kernel.org \
    --cc=vincenzo.frascino@arm.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will.deacon@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.