From: Catalin Marinas <catalin.marinas@arm.com>
To: Dave Martin <Dave.Martin@arm.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>,
Mark Rutland <mark.rutland@arm.com>,
kvm@vger.kernel.org, Christian Koenig <Christian.Koenig@amd.com>,
Szabolcs Nagy <Szabolcs.Nagy@arm.com>,
Will Deacon <will.deacon@arm.com>,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
Lee Smith <Lee.Smith@arm.com>,
linux-kselftest@vger.kernel.org,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Jacob Bramley <Jacob.Bramley@arm.com>,
Leon Romanovsky <leon@kernel.org>,
linux-rdma@vger.kernel.org, amd-gfx@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org,
Evgeniy Stepanov <eugenis@google.com>,
linux-media@vger.kernel.org, Kees Cook <keescook@chromium.org>,
Ruben Ayrapetyan <Ruben.Ayrapetyan@arm.com>,
Andrey Konovalov <andreyknvl@google.com>,
Kevin Brodsky <kevin.brodsky@arm.c>
Subject: Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel
Date: Thu, 23 May 2019 17:57:09 +0100 [thread overview]
Message-ID: <20190523165708.q6ru7xg45aqfjzpr@mbp> (raw)
In-Reply-To: <20190523104256.GX28398@e103592.cambridge.arm.com>
On Thu, May 23, 2019 at 11:42:57AM +0100, Dave P Martin wrote:
> On Wed, May 22, 2019 at 09:20:52PM -0300, Jason Gunthorpe wrote:
> > On Wed, May 22, 2019 at 02:49:28PM +0100, Dave Martin wrote:
> > > If multiple people will care about this, perhaps we should try to
> > > annotate types more explicitly in SYSCALL_DEFINEx() and ABI data
> > > structures.
> > >
> > > For example, we could have a couple of mutually exclusive modifiers
> > >
> > > T __object *
> > > T __vaddr * (or U __vaddr)
> > >
> > > In the first case the pointer points to an object (in the C sense)
> > > that the call may dereference but not use for any other purpose.
> >
> > How would you use these two differently?
> >
> > So far the kernel has worked that __user should tag any pointer that
> > is from userspace and then you can't do anything with it until you
> > transform it into a kernel something
>
> Ultimately it would be good to disallow casting __object pointers execpt
> to compatible __object pointer types, and to make get_user etc. demand
> __object.
>
> __vaddr pointers / addresses would be freely castable, but not to
> __object and so would not be dereferenceable even indirectly.
I think it gets too complicated and there are ambiguous cases that we
may not be able to distinguish. For example copy_from_user() may be used
to copy a user data structure into the kernel, hence __object would
work, while the same function may be used to copy opaque data to a file,
so __vaddr may be a better option (unless I misunderstood your
proposal).
We currently have T __user * and I think it's a good starting point. The
prior attempt [1] was shut down because it was just hiding the cast
using __force. We'd need to work through those cases again and rather
start changing the function prototypes to avoid unnecessary casting in
the callers (e.g. get_user_pages(void __user *) or come up with a new
type) while changing the explicit casting to a macro where it needs to
be obvious that we are converting a user pointer, potentially typed
(tagged), to an untyped address range. We may need a user_ptr_to_ulong()
macro or similar (it seems that we have a u64_to_user_ptr, wasn't aware
of it).
It may actually not be far from what you suggested but I'd keep the
current T __user * to denote possible dereference.
[1] https://lore.kernel.org/lkml/5d54526e5ff2e5ad63d0dfdd9ab17cf359afa4f2.1535629099.git.andreyknvl@google.com/
--
Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Dave Martin <Dave.Martin@arm.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>,
Mark Rutland <mark.rutland@arm.com>,
kvm@vger.kernel.org, Christian Koenig <Christian.Koenig@amd.com>,
Szabolcs Nagy <Szabolcs.Nagy@arm.com>,
Will Deacon <will.deacon@arm.com>,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
Lee Smith <Lee.Smith@arm.com>,
linux-kselftest@vger.kernel.org,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Jacob Bramley <Jacob.Bramley@arm.com>,
Leon Romanovsky <leon@kernel.org>,
linux-rdma@vger.kernel.org, amd-gfx@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org,
Evgeniy Stepanov <eugenis@google.com>,
linux-media@vger.kernel.org, Kees Cook <keescook@chromium.org>,
Ruben Ayrapetyan <Ruben.Ayrapetyan@arm.com>,
Andrey Konovalov <andreyknvl@google.com>,
Kevin Brodsky <kevin.brodsky@arm.com>,
Alex Williamson <alex.williamson@redhat.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Dmitry Vyukov <dvyukov@google.com>,
Kostya Serebryany <kcc@google.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Felix Kuehling <Felix.Kuehling@amd.com>,
linux-kernel@vger.kernel.org,
Jens Wiklander <jens.wiklander@linaro.org>,
Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>,
Alexander Deucher <Alexander.Deucher@amd.com>,
Andrew Morton <akpm@linux-foundation.org>,
Robin Murphy <robin.murphy@arm.com>,
Yishai Hadas <yishaih@mellanox.com>,
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Subject: Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel
Date: Thu, 23 May 2019 17:57:09 +0100 [thread overview]
Message-ID: <20190523165708.q6ru7xg45aqfjzpr@mbp> (raw)
In-Reply-To: <20190523104256.GX28398@e103592.cambridge.arm.com>
On Thu, May 23, 2019 at 11:42:57AM +0100, Dave P Martin wrote:
> On Wed, May 22, 2019 at 09:20:52PM -0300, Jason Gunthorpe wrote:
> > On Wed, May 22, 2019 at 02:49:28PM +0100, Dave Martin wrote:
> > > If multiple people will care about this, perhaps we should try to
> > > annotate types more explicitly in SYSCALL_DEFINEx() and ABI data
> > > structures.
> > >
> > > For example, we could have a couple of mutually exclusive modifiers
> > >
> > > T __object *
> > > T __vaddr * (or U __vaddr)
> > >
> > > In the first case the pointer points to an object (in the C sense)
> > > that the call may dereference but not use for any other purpose.
> >
> > How would you use these two differently?
> >
> > So far the kernel has worked that __user should tag any pointer that
> > is from userspace and then you can't do anything with it until you
> > transform it into a kernel something
>
> Ultimately it would be good to disallow casting __object pointers execpt
> to compatible __object pointer types, and to make get_user etc. demand
> __object.
>
> __vaddr pointers / addresses would be freely castable, but not to
> __object and so would not be dereferenceable even indirectly.
I think it gets too complicated and there are ambiguous cases that we
may not be able to distinguish. For example copy_from_user() may be used
to copy a user data structure into the kernel, hence __object would
work, while the same function may be used to copy opaque data to a file,
so __vaddr may be a better option (unless I misunderstood your
proposal).
We currently have T __user * and I think it's a good starting point. The
prior attempt [1] was shut down because it was just hiding the cast
using __force. We'd need to work through those cases again and rather
start changing the function prototypes to avoid unnecessary casting in
the callers (e.g. get_user_pages(void __user *) or come up with a new
type) while changing the explicit casting to a macro where it needs to
be obvious that we are converting a user pointer, potentially typed
(tagged), to an untyped address range. We may need a user_ptr_to_ulong()
macro or similar (it seems that we have a u64_to_user_ptr, wasn't aware
of it).
It may actually not be far from what you suggested but I'd keep the
current T __user * to denote possible dereference.
[1] https://lore.kernel.org/lkml/5d54526e5ff2e5ad63d0dfdd9ab17cf359afa4f2.1535629099.git.andreyknvl@google.com/
--
Catalin
WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas at arm.com (Catalin Marinas)
Subject: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel
Date: Thu, 23 May 2019 17:57:09 +0100 [thread overview]
Message-ID: <20190523165708.q6ru7xg45aqfjzpr@mbp> (raw)
In-Reply-To: <20190523104256.GX28398@e103592.cambridge.arm.com>
On Thu, May 23, 2019 at 11:42:57AM +0100, Dave P Martin wrote:
> On Wed, May 22, 2019 at 09:20:52PM -0300, Jason Gunthorpe wrote:
> > On Wed, May 22, 2019 at 02:49:28PM +0100, Dave Martin wrote:
> > > If multiple people will care about this, perhaps we should try to
> > > annotate types more explicitly in SYSCALL_DEFINEx() and ABI data
> > > structures.
> > >
> > > For example, we could have a couple of mutually exclusive modifiers
> > >
> > > T __object *
> > > T __vaddr * (or U __vaddr)
> > >
> > > In the first case the pointer points to an object (in the C sense)
> > > that the call may dereference but not use for any other purpose.
> >
> > How would you use these two differently?
> >
> > So far the kernel has worked that __user should tag any pointer that
> > is from userspace and then you can't do anything with it until you
> > transform it into a kernel something
>
> Ultimately it would be good to disallow casting __object pointers execpt
> to compatible __object pointer types, and to make get_user etc. demand
> __object.
>
> __vaddr pointers / addresses would be freely castable, but not to
> __object and so would not be dereferenceable even indirectly.
I think it gets too complicated and there are ambiguous cases that we
may not be able to distinguish. For example copy_from_user() may be used
to copy a user data structure into the kernel, hence __object would
work, while the same function may be used to copy opaque data to a file,
so __vaddr may be a better option (unless I misunderstood your
proposal).
We currently have T __user * and I think it's a good starting point. The
prior attempt [1] was shut down because it was just hiding the cast
using __force. We'd need to work through those cases again and rather
start changing the function prototypes to avoid unnecessary casting in
the callers (e.g. get_user_pages(void __user *) or come up with a new
type) while changing the explicit casting to a macro where it needs to
be obvious that we are converting a user pointer, potentially typed
(tagged), to an untyped address range. We may need a user_ptr_to_ulong()
macro or similar (it seems that we have a u64_to_user_ptr, wasn't aware
of it).
It may actually not be far from what you suggested but I'd keep the
current T __user * to denote possible dereference.
[1] https://lore.kernel.org/lkml/5d54526e5ff2e5ad63d0dfdd9ab17cf359afa4f2.1535629099.git.andreyknvl at google.com/
--
Catalin
WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas@arm.com (Catalin Marinas)
Subject: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel
Date: Thu, 23 May 2019 17:57:09 +0100 [thread overview]
Message-ID: <20190523165708.q6ru7xg45aqfjzpr@mbp> (raw)
Message-ID: <20190523165709.GF50m0vVUKfzicfzp5CYRKZZRybnBuxbIMnd6idSkhs@z> (raw)
In-Reply-To: <20190523104256.GX28398@e103592.cambridge.arm.com>
On Thu, May 23, 2019@11:42:57AM +0100, Dave P Martin wrote:
> On Wed, May 22, 2019@09:20:52PM -0300, Jason Gunthorpe wrote:
> > On Wed, May 22, 2019@02:49:28PM +0100, Dave Martin wrote:
> > > If multiple people will care about this, perhaps we should try to
> > > annotate types more explicitly in SYSCALL_DEFINEx() and ABI data
> > > structures.
> > >
> > > For example, we could have a couple of mutually exclusive modifiers
> > >
> > > T __object *
> > > T __vaddr * (or U __vaddr)
> > >
> > > In the first case the pointer points to an object (in the C sense)
> > > that the call may dereference but not use for any other purpose.
> >
> > How would you use these two differently?
> >
> > So far the kernel has worked that __user should tag any pointer that
> > is from userspace and then you can't do anything with it until you
> > transform it into a kernel something
>
> Ultimately it would be good to disallow casting __object pointers execpt
> to compatible __object pointer types, and to make get_user etc. demand
> __object.
>
> __vaddr pointers / addresses would be freely castable, but not to
> __object and so would not be dereferenceable even indirectly.
I think it gets too complicated and there are ambiguous cases that we
may not be able to distinguish. For example copy_from_user() may be used
to copy a user data structure into the kernel, hence __object would
work, while the same function may be used to copy opaque data to a file,
so __vaddr may be a better option (unless I misunderstood your
proposal).
We currently have T __user * and I think it's a good starting point. The
prior attempt [1] was shut down because it was just hiding the cast
using __force. We'd need to work through those cases again and rather
start changing the function prototypes to avoid unnecessary casting in
the callers (e.g. get_user_pages(void __user *) or come up with a new
type) while changing the explicit casting to a macro where it needs to
be obvious that we are converting a user pointer, potentially typed
(tagged), to an untyped address range. We may need a user_ptr_to_ulong()
macro or similar (it seems that we have a u64_to_user_ptr, wasn't aware
of it).
It may actually not be far from what you suggested but I'd keep the
current T __user * to denote possible dereference.
[1] https://lore.kernel.org/lkml/5d54526e5ff2e5ad63d0dfdd9ab17cf359afa4f2.1535629099.git.andreyknvl at google.com/
--
Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Dave Martin <Dave.Martin@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
kvm@vger.kernel.org, Szabolcs Nagy <Szabolcs.Nagy@arm.com>,
Will Deacon <will.deacon@arm.com>,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
linux-kselftest@vger.kernel.org,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Jacob Bramley <Jacob.Bramley@arm.com>,
Leon Romanovsky <leon@kernel.org>,
linux-rdma@vger.kernel.org, amd-gfx@lists.freedesktop.org,
Jason Gunthorpe <jgg@ziepe.ca>,
Dmitry Vyukov <dvyukov@google.com>,
Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>,
Evgeniy Stepanov <eugenis@google.com>,
linux-media@vger.kernel.org, Kees Cook <keescook@chromium.org>,
Ruben Ayrapetyan <Ruben.Ayrapetyan@arm.com>,
Andrey Konovalov <andreyknvl@google.com>,
Kevin Brodsky <kevin.brodsky@arm.com>,
Alex Williamson <alex.williamson@redhat.com>,
Yishai Hadas <yishaih@mellanox.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Kostya Serebryany <kcc@google.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Felix Kuehling <Felix.Kuehling@amd.com>,
linux-kernel@vger.kernel.org,
Jens Wiklander <jens.wiklander@linaro.org>,
Lee Smith <Lee.Smith@arm.com>,
Alexander Deucher <Alexander.Deucher@amd.com>,
Andrew Morton <akpm@linux-foundation.org>,
Robin Murphy <robin.murphy@arm.com>,
Christian Koenig <Christian.Koenig@amd.com>,
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Subject: Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel
Date: Thu, 23 May 2019 17:57:09 +0100 [thread overview]
Message-ID: <20190523165708.q6ru7xg45aqfjzpr@mbp> (raw)
In-Reply-To: <20190523104256.GX28398@e103592.cambridge.arm.com>
On Thu, May 23, 2019 at 11:42:57AM +0100, Dave P Martin wrote:
> On Wed, May 22, 2019 at 09:20:52PM -0300, Jason Gunthorpe wrote:
> > On Wed, May 22, 2019 at 02:49:28PM +0100, Dave Martin wrote:
> > > If multiple people will care about this, perhaps we should try to
> > > annotate types more explicitly in SYSCALL_DEFINEx() and ABI data
> > > structures.
> > >
> > > For example, we could have a couple of mutually exclusive modifiers
> > >
> > > T __object *
> > > T __vaddr * (or U __vaddr)
> > >
> > > In the first case the pointer points to an object (in the C sense)
> > > that the call may dereference but not use for any other purpose.
> >
> > How would you use these two differently?
> >
> > So far the kernel has worked that __user should tag any pointer that
> > is from userspace and then you can't do anything with it until you
> > transform it into a kernel something
>
> Ultimately it would be good to disallow casting __object pointers execpt
> to compatible __object pointer types, and to make get_user etc. demand
> __object.
>
> __vaddr pointers / addresses would be freely castable, but not to
> __object and so would not be dereferenceable even indirectly.
I think it gets too complicated and there are ambiguous cases that we
may not be able to distinguish. For example copy_from_user() may be used
to copy a user data structure into the kernel, hence __object would
work, while the same function may be used to copy opaque data to a file,
so __vaddr may be a better option (unless I misunderstood your
proposal).
We currently have T __user * and I think it's a good starting point. The
prior attempt [1] was shut down because it was just hiding the cast
using __force. We'd need to work through those cases again and rather
start changing the function prototypes to avoid unnecessary casting in
the callers (e.g. get_user_pages(void __user *) or come up with a new
type) while changing the explicit casting to a macro where it needs to
be obvious that we are converting a user pointer, potentially typed
(tagged), to an untyped address range. We may need a user_ptr_to_ulong()
macro or similar (it seems that we have a u64_to_user_ptr, wasn't aware
of it).
It may actually not be far from what you suggested but I'd keep the
current T __user * to denote possible dereference.
[1] https://lore.kernel.org/lkml/5d54526e5ff2e5ad63d0dfdd9ab17cf359afa4f2.1535629099.git.andreyknvl@google.com/
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-05-23 16:57 UTC|newest]
Thread overview: 558+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-06 16:30 [PATCH v15 00/17] arm64: untag user pointers passed to the kernel Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` andreyknvl
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` [PATCH v15 01/17] uaccess: add untagged_addr definition for other arches Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` andreyknvl
2019-05-06 16:30 ` Andrey Konovalov
2019-05-29 14:49 ` Khalid Aziz
2019-05-29 14:49 ` Khalid Aziz
2019-05-29 14:49 ` Khalid Aziz
2019-05-29 14:49 ` khalid.aziz
2019-05-29 14:49 ` Khalid Aziz
2019-05-06 16:30 ` [PATCH v15 02/17] arm64: untag user pointers in access_ok and __uaccess_mask_ptr Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` andreyknvl
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` [PATCH v15 03/17] lib, arm64: untag user pointers in strn*_user Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` andreyknvl
2019-05-06 16:30 ` Andrey Konovalov
2019-05-22 10:41 ` Catalin Marinas
2019-05-22 10:41 ` Catalin Marinas
2019-05-22 10:41 ` Catalin Marinas
2019-05-22 10:41 ` catalin.marinas
2019-05-22 10:41 ` Catalin Marinas
2019-05-06 16:30 ` [PATCH v15 04/17] mm: add ksys_ wrappers to memory syscalls Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` andreyknvl
2019-05-06 16:30 ` Andrey Konovalov
2019-05-22 10:56 ` Catalin Marinas
2019-05-22 10:56 ` Catalin Marinas
2019-05-22 10:56 ` Catalin Marinas
2019-05-22 10:56 ` catalin.marinas
2019-05-22 10:56 ` Catalin Marinas
2019-05-06 16:30 ` [PATCH v15 05/17] arms64: untag user pointers passed " Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` andreyknvl
2019-05-06 16:30 ` Andrey Konovalov
2019-05-22 11:49 ` Catalin Marinas
2019-05-22 11:49 ` Catalin Marinas
2019-05-22 11:49 ` Catalin Marinas
2019-05-22 11:49 ` catalin.marinas
2019-05-22 11:49 ` Catalin Marinas
2019-05-22 21:16 ` Evgenii Stepanov
2019-05-22 21:16 ` Evgenii Stepanov
2019-05-22 21:16 ` Evgenii Stepanov
2019-05-22 21:16 ` Evgenii Stepanov
2019-05-22 21:16 ` eugenis
2019-05-22 21:16 ` Evgenii Stepanov
2019-05-23 9:04 ` Catalin Marinas
2019-05-23 9:04 ` Catalin Marinas
2019-05-23 9:04 ` Catalin Marinas
2019-05-23 9:04 ` Catalin Marinas
2019-05-23 9:04 ` catalin.marinas
2019-05-23 9:04 ` Catalin Marinas
2019-05-24 4:23 ` Evgenii Stepanov
2019-05-24 4:23 ` Evgenii Stepanov
2019-05-24 4:23 ` Evgenii Stepanov
2019-05-24 4:23 ` Evgenii Stepanov
2019-05-24 4:23 ` eugenis
2019-05-24 4:23 ` Evgenii Stepanov
2019-05-24 15:41 ` Andrew Murray
2019-05-24 15:41 ` Andrew Murray
2019-05-24 15:41 ` Andrew Murray
2019-05-24 15:41 ` andrew.murray
2019-05-24 15:41 ` Andrew Murray
2019-05-25 9:57 ` Catalin Marinas
2019-05-25 9:57 ` Catalin Marinas
2019-05-25 9:57 ` Catalin Marinas
2019-05-25 9:57 ` catalin.marinas
2019-05-25 9:57 ` Catalin Marinas
2019-05-27 9:42 ` Catalin Marinas
2019-05-27 9:42 ` Catalin Marinas
2019-05-27 9:42 ` Catalin Marinas
2019-05-27 9:42 ` catalin.marinas
2019-05-27 9:42 ` Catalin Marinas
2019-05-27 14:37 ` Catalin Marinas
2019-05-27 14:37 ` Catalin Marinas
2019-05-27 14:37 ` Catalin Marinas
2019-05-27 14:37 ` catalin.marinas
2019-05-27 14:37 ` Catalin Marinas
2019-05-28 14:54 ` Andrew Murray
2019-05-28 14:54 ` Andrew Murray
2019-05-28 14:54 ` Andrew Murray
2019-05-28 14:54 ` andrew.murray
2019-05-28 14:54 ` Andrew Murray
2019-05-28 15:40 ` Catalin Marinas
2019-05-28 15:40 ` Catalin Marinas
2019-05-28 15:40 ` Catalin Marinas
2019-05-28 15:40 ` catalin.marinas
2019-05-28 15:40 ` Catalin Marinas
2019-05-28 15:56 ` Dave Martin
2019-05-28 15:56 ` Dave Martin
2019-05-28 15:56 ` Dave Martin
2019-05-28 15:56 ` Dave.Martin
2019-05-28 15:56 ` Dave Martin
2019-05-28 16:34 ` Catalin Marinas
2019-05-28 16:34 ` Catalin Marinas
2019-05-28 16:34 ` Catalin Marinas
2019-05-28 16:34 ` catalin.marinas
2019-05-28 16:34 ` Catalin Marinas
2019-05-29 12:42 ` Dave Martin
2019-05-29 12:42 ` Dave Martin
2019-05-29 12:42 ` Dave Martin
2019-05-29 12:42 ` Dave.Martin
2019-05-29 12:42 ` Dave Martin
2019-05-29 13:23 ` Catalin Marinas
2019-05-29 13:23 ` Catalin Marinas
2019-05-29 13:23 ` Catalin Marinas
2019-05-29 13:23 ` catalin.marinas
2019-05-29 13:23 ` Catalin Marinas
2019-05-29 15:18 ` Dave Martin
2019-05-29 15:18 ` Dave Martin
2019-05-29 15:18 ` Dave Martin
2019-05-29 15:18 ` Dave.Martin
2019-05-29 15:18 ` Dave Martin
2019-05-28 23:33 ` Khalid Aziz
2019-05-28 23:33 ` Khalid Aziz
2019-05-28 23:33 ` Khalid Aziz
2019-05-28 23:33 ` khalid.aziz
2019-05-28 23:33 ` Khalid Aziz
2019-05-29 14:20 ` Catalin Marinas
2019-05-29 14:20 ` Catalin Marinas
2019-05-29 14:20 ` Catalin Marinas
2019-05-29 14:20 ` catalin.marinas
2019-05-29 14:20 ` Catalin Marinas
2019-05-29 19:16 ` Khalid Aziz
2019-05-29 19:16 ` Khalid Aziz
2019-05-29 19:16 ` Khalid Aziz
2019-05-29 19:16 ` khalid.aziz
2019-05-29 19:16 ` Khalid Aziz
2019-05-30 15:11 ` Catalin Marinas
2019-05-30 15:11 ` Catalin Marinas
2019-05-30 15:11 ` Catalin Marinas
2019-05-30 15:11 ` catalin.marinas
2019-05-30 15:11 ` Catalin Marinas
2019-05-30 16:05 ` Khalid Aziz
2019-05-30 16:05 ` Khalid Aziz
2019-05-30 16:05 ` Khalid Aziz
2019-05-30 16:05 ` khalid.aziz
2019-05-30 16:05 ` Khalid Aziz
2019-05-30 16:57 ` Catalin Marinas
2019-05-30 16:57 ` Catalin Marinas
2019-05-30 16:57 ` Catalin Marinas
2019-05-30 16:57 ` catalin.marinas
2019-05-30 16:57 ` Catalin Marinas
2019-05-28 13:05 ` Catalin Marinas
2019-05-28 13:05 ` Catalin Marinas
2019-05-28 13:05 ` Catalin Marinas
2019-05-28 13:05 ` catalin.marinas
2019-05-28 13:05 ` Catalin Marinas
2019-05-06 16:30 ` [PATCH v15 06/17] mm: untag user pointers in do_pages_move Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` andreyknvl
2019-05-06 16:30 ` Andrey Konovalov
2019-05-22 11:51 ` Catalin Marinas
2019-05-22 11:51 ` Catalin Marinas
2019-05-22 11:51 ` Catalin Marinas
2019-05-22 11:51 ` catalin.marinas
2019-05-22 11:51 ` Catalin Marinas
2019-05-06 16:30 ` [PATCH v15 07/17] mm, arm64: untag user pointers in mm/gup.c Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` andreyknvl
2019-05-06 16:30 ` Andrey Konovalov
2019-05-22 11:56 ` Catalin Marinas
2019-05-22 11:56 ` Catalin Marinas
2019-05-22 11:56 ` Catalin Marinas
2019-05-22 11:56 ` catalin.marinas
2019-05-22 11:56 ` Catalin Marinas
2019-05-06 16:30 ` [PATCH v15 08/17] mm, arm64: untag user pointers in get_vaddr_frames Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` andreyknvl
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` [PATCH v15 09/17] fs, arm64: untag user pointers in copy_mount_options Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` andreyknvl
2019-05-06 16:30 ` Andrey Konovalov
2019-05-22 12:09 ` Catalin Marinas
2019-05-22 12:09 ` Catalin Marinas
2019-05-22 12:09 ` Catalin Marinas
2019-05-22 12:09 ` catalin.marinas
2019-05-22 12:09 ` Catalin Marinas
2019-05-06 16:30 ` [PATCH v15 10/17] fs, arm64: untag user pointers in fs/userfaultfd.c Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` andreyknvl
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` [PATCH v15 11/17] drm/amdgpu, arm64: untag user pointers Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` andreyknvl
2019-05-06 16:30 ` Andrey Konovalov
2019-05-07 16:43 ` Kuehling, Felix
2019-05-07 16:43 ` Kuehling, Felix
2019-05-07 16:43 ` Kuehling, Felix
2019-05-07 16:43 ` Kuehling, Felix
2019-05-07 16:43 ` Felix.Kuehling
2019-05-07 16:43 ` Kuehling, Felix
2019-05-06 16:30 ` [PATCH v15 12/17] drm/radeon, arm64: untag user pointers in radeon_gem_userptr_ioctl Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` andreyknvl
2019-05-06 16:30 ` Andrey Konovalov
[not found] ` <03fe9d923db75cf72678f3ce103838e67390751a.1557160186.git.andreyknvl-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2019-05-07 16:44 ` Kuehling, Felix
2019-05-07 16:44 ` Kuehling, Felix
2019-05-07 16:44 ` Kuehling, Felix
2019-05-07 16:44 ` Kuehling, Felix
2019-05-07 16:44 ` Felix.Kuehling
2019-05-07 16:44 ` Kuehling, Felix
2019-05-06 16:30 ` [PATCH v15 13/17] IB, arm64: untag user pointers in ib_uverbs_(re)reg_mr() Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 16:30 ` andreyknvl
2019-05-06 16:30 ` Andrey Konovalov
2019-05-06 19:50 ` Jason Gunthorpe
2019-05-06 19:50 ` Jason Gunthorpe
2019-05-06 19:50 ` Jason Gunthorpe
2019-05-06 19:50 ` jgg
2019-05-06 19:50 ` Jason Gunthorpe
2019-05-07 6:33 ` Leon Romanovsky
2019-05-07 6:33 ` Leon Romanovsky
2019-05-07 6:33 ` Leon Romanovsky
2019-05-07 6:33 ` leon
2019-05-07 6:33 ` Leon Romanovsky
2019-05-06 16:31 ` [PATCH v15 14/17] media/v4l2-core, arm64: untag user pointers in videobuf_dma_contig_user_get Andrey Konovalov
2019-05-06 16:31 ` Andrey Konovalov
2019-05-06 16:31 ` Andrey Konovalov
2019-05-06 16:31 ` Andrey Konovalov
2019-05-06 16:31 ` andreyknvl
2019-05-06 16:31 ` Andrey Konovalov
2019-05-24 13:13 ` Mauro Carvalho Chehab
2019-05-24 13:13 ` Mauro Carvalho Chehab
2019-05-24 13:13 ` Mauro Carvalho Chehab
2019-05-24 13:13 ` mchehab+samsung
2019-05-24 13:13 ` Mauro Carvalho Chehab
2019-05-06 16:31 ` [PATCH v15 15/17] tee, arm64: untag user pointers in tee_shm_register Andrey Konovalov
2019-05-06 16:31 ` Andrey Konovalov
2019-05-06 16:31 ` Andrey Konovalov
2019-05-06 16:31 ` Andrey Konovalov
2019-05-06 16:31 ` andreyknvl
2019-05-06 16:31 ` Andrey Konovalov
2019-05-06 16:31 ` [PATCH v15 16/17] vfio/type1, arm64: untag user pointers in vaddr_get_pfn Andrey Konovalov
2019-05-06 16:31 ` Andrey Konovalov
2019-05-06 16:31 ` Andrey Konovalov
2019-05-06 16:31 ` Andrey Konovalov
2019-05-06 16:31 ` andreyknvl
2019-05-06 16:31 ` Andrey Konovalov
2019-05-06 16:31 ` [PATCH v15 17/17] selftests, arm64: add a selftest for passing tagged pointers to kernel Andrey Konovalov
2019-05-06 16:31 ` Andrey Konovalov
2019-05-06 16:31 ` Andrey Konovalov
2019-05-06 16:31 ` Andrey Konovalov
2019-05-06 16:31 ` andreyknvl
2019-05-06 16:31 ` Andrey Konovalov
2019-05-22 14:16 ` Catalin Marinas
2019-05-22 14:16 ` Catalin Marinas
2019-05-22 14:16 ` Catalin Marinas
2019-05-22 14:16 ` catalin.marinas
2019-05-22 14:16 ` Catalin Marinas
2019-05-31 14:21 ` Andrey Konovalov
2019-05-31 14:21 ` Andrey Konovalov
2019-05-31 14:21 ` Andrey Konovalov
2019-05-31 14:21 ` Andrey Konovalov
2019-05-31 14:21 ` andreyknvl
2019-05-31 14:21 ` Andrey Konovalov
2019-05-31 16:22 ` Catalin Marinas
2019-05-31 16:22 ` Catalin Marinas
2019-05-31 16:22 ` Catalin Marinas
2019-05-31 16:22 ` Catalin Marinas
2019-05-31 16:22 ` catalin.marinas
2019-05-31 16:22 ` Catalin Marinas
2019-05-17 14:49 ` [PATCH v15 00/17] arm64: untag user pointers passed to the kernel Catalin Marinas
2019-05-17 14:49 ` Catalin Marinas
2019-05-17 14:49 ` Catalin Marinas
2019-05-17 14:49 ` catalin.marinas
2019-05-17 14:49 ` Catalin Marinas
2019-05-20 23:53 ` Evgenii Stepanov
2019-05-20 23:53 ` Evgenii Stepanov
2019-05-20 23:53 ` Evgenii Stepanov
2019-05-20 23:53 ` Evgenii Stepanov
2019-05-20 23:53 ` eugenis
2019-05-20 23:53 ` Evgenii Stepanov
2019-05-21 18:29 ` Catalin Marinas
2019-05-21 18:29 ` Catalin Marinas
2019-05-21 18:29 ` Catalin Marinas
2019-05-21 18:29 ` Catalin Marinas
2019-05-21 18:29 ` catalin.marinas
2019-05-21 18:29 ` Catalin Marinas
2019-05-22 0:04 ` Kees Cook
2019-05-22 0:04 ` Kees Cook
2019-05-22 0:04 ` Kees Cook
2019-05-22 0:04 ` Kees Cook
2019-05-22 0:04 ` keescook
2019-05-22 0:04 ` Kees Cook
2019-05-22 10:11 ` Catalin Marinas
2019-05-22 10:11 ` Catalin Marinas
2019-05-22 10:11 ` Catalin Marinas
2019-05-22 10:11 ` Catalin Marinas
2019-05-22 10:11 ` catalin.marinas
2019-05-22 10:11 ` Catalin Marinas
2019-05-22 15:30 ` enh
2019-05-22 15:30 ` enh
2019-05-22 15:30 ` enh
2019-05-22 15:30 ` enh
2019-05-22 15:30 ` enh
2019-05-22 15:30 ` enh
2019-05-22 16:35 ` Catalin Marinas
2019-05-22 16:35 ` Catalin Marinas
2019-05-22 16:35 ` Catalin Marinas
2019-05-22 16:35 ` Catalin Marinas
2019-05-22 16:35 ` catalin.marinas
2019-05-22 16:35 ` Catalin Marinas
2019-05-22 16:58 ` enh
2019-05-22 16:58 ` enh
2019-05-22 16:58 ` enh
2019-05-22 16:58 ` enh
2019-05-22 16:58 ` enh
2019-05-22 16:58 ` enh
2019-05-23 15:21 ` Catalin Marinas
2019-05-23 15:21 ` Catalin Marinas
2019-05-23 15:21 ` Catalin Marinas
2019-05-23 15:21 ` Catalin Marinas
2019-05-23 15:21 ` catalin.marinas
2019-05-23 15:21 ` Catalin Marinas
2019-05-22 20:47 ` Kees Cook
2019-05-22 20:47 ` Kees Cook
2019-05-22 20:47 ` Kees Cook
2019-05-22 20:47 ` Kees Cook
2019-05-22 20:47 ` keescook
2019-05-22 20:47 ` Kees Cook
2019-05-22 23:03 ` Evgenii Stepanov
2019-05-22 23:03 ` Evgenii Stepanov
2019-05-22 23:03 ` Evgenii Stepanov
2019-05-22 23:03 ` Evgenii Stepanov
2019-05-22 23:03 ` eugenis
2019-05-22 23:03 ` Evgenii Stepanov
2019-05-22 23:09 ` enh
2019-05-22 23:09 ` enh
2019-05-22 23:09 ` enh
2019-05-22 23:09 ` enh
2019-05-22 23:09 ` enh
2019-05-22 23:09 ` enh
2019-05-23 7:34 ` Catalin Marinas
2019-05-23 7:34 ` Catalin Marinas
2019-05-23 7:34 ` Catalin Marinas
2019-05-23 7:34 ` Catalin Marinas
2019-05-23 7:34 ` catalin.marinas
2019-05-23 7:34 ` Catalin Marinas
2019-05-23 14:44 ` Catalin Marinas
2019-05-23 14:44 ` Catalin Marinas
2019-05-23 14:44 ` Catalin Marinas
2019-05-23 14:44 ` Catalin Marinas
2019-05-23 14:44 ` catalin.marinas
2019-05-23 14:44 ` Catalin Marinas
2019-05-23 15:44 ` enh
2019-05-23 15:44 ` enh
2019-05-23 15:44 ` enh
2019-05-23 15:44 ` enh
2019-05-23 15:44 ` enh
2019-05-23 15:44 ` enh
2019-05-23 17:00 ` Catalin Marinas
2019-05-23 17:00 ` Catalin Marinas
2019-05-23 17:00 ` Catalin Marinas
2019-05-23 17:00 ` Catalin Marinas
2019-05-23 17:00 ` catalin.marinas
2019-05-23 17:00 ` Catalin Marinas
2019-05-23 16:38 ` Kees Cook
2019-05-23 16:38 ` Kees Cook
2019-05-23 16:38 ` Kees Cook
2019-05-23 16:38 ` Kees Cook
2019-05-23 16:38 ` keescook
2019-05-23 16:38 ` Kees Cook
2019-05-23 17:43 ` Catalin Marinas
2019-05-23 17:43 ` Catalin Marinas
2019-05-23 17:43 ` Catalin Marinas
2019-05-23 17:43 ` Catalin Marinas
2019-05-23 17:43 ` catalin.marinas
2019-05-23 17:43 ` Catalin Marinas
2019-05-23 21:31 ` Kees Cook
2019-05-23 21:31 ` Kees Cook
2019-05-23 21:31 ` Kees Cook
2019-05-23 21:31 ` Kees Cook
2019-05-23 21:31 ` keescook
2019-05-23 21:31 ` Kees Cook
2019-05-24 11:20 ` Catalin Marinas
2019-05-24 11:20 ` Catalin Marinas
2019-05-24 11:20 ` Catalin Marinas
2019-05-24 11:20 ` Catalin Marinas
2019-05-24 11:20 ` catalin.marinas
2019-05-24 11:20 ` Catalin Marinas
2019-05-28 17:02 ` Catalin Marinas
2019-05-28 17:02 ` Catalin Marinas
2019-05-28 17:02 ` Catalin Marinas
2019-05-28 17:02 ` Catalin Marinas
2019-05-28 17:02 ` catalin.marinas
2019-05-28 17:02 ` Catalin Marinas
2019-06-02 5:06 ` Kees Cook
2019-06-02 5:06 ` Kees Cook
2019-06-02 5:06 ` Kees Cook
2019-06-02 5:06 ` Kees Cook
2019-06-02 5:06 ` keescook
2019-06-02 5:06 ` Kees Cook
2019-05-22 19:21 ` Kees Cook
2019-05-22 19:21 ` Kees Cook
2019-05-22 19:21 ` Kees Cook
2019-05-22 19:21 ` Kees Cook
2019-05-22 19:21 ` keescook
2019-05-22 19:21 ` Kees Cook
2019-05-22 20:15 ` enh
2019-05-22 20:15 ` enh
2019-05-22 20:15 ` enh
2019-05-22 20:15 ` enh
2019-05-22 20:15 ` enh
2019-05-22 20:15 ` enh
2019-05-23 15:08 ` Catalin Marinas
2019-05-23 15:08 ` Catalin Marinas
2019-05-23 15:08 ` Catalin Marinas
2019-05-23 15:08 ` Catalin Marinas
2019-05-23 15:08 ` catalin.marinas
2019-05-23 15:08 ` Catalin Marinas
2019-05-23 17:51 ` Khalid Aziz
2019-05-23 17:51 ` Khalid Aziz
2019-05-23 17:51 ` Khalid Aziz
2019-05-23 17:51 ` Khalid Aziz
2019-05-23 17:51 ` khalid.aziz
2019-05-23 17:51 ` Khalid Aziz
2019-05-23 20:11 ` Catalin Marinas
2019-05-23 20:11 ` Catalin Marinas
2019-05-23 20:11 ` Catalin Marinas
2019-05-23 20:11 ` Catalin Marinas
2019-05-23 20:11 ` catalin.marinas
2019-05-23 20:11 ` Catalin Marinas
2019-05-23 21:42 ` Khalid Aziz
2019-05-23 21:42 ` Khalid Aziz
2019-05-23 21:42 ` Khalid Aziz
2019-05-23 21:42 ` Khalid Aziz
2019-05-23 21:42 ` khalid.aziz
2019-05-23 21:42 ` Khalid Aziz
2019-05-23 21:49 ` Khalid Aziz
2019-05-23 21:49 ` Khalid Aziz
2019-05-23 21:49 ` Khalid Aziz
2019-05-23 21:49 ` Khalid Aziz
2019-05-23 21:49 ` khalid.aziz
2019-05-23 21:49 ` Khalid Aziz
2019-05-24 10:11 ` Catalin Marinas
2019-05-24 10:11 ` Catalin Marinas
2019-05-24 10:11 ` Catalin Marinas
2019-05-24 10:11 ` Catalin Marinas
2019-05-24 10:11 ` catalin.marinas
2019-05-24 10:11 ` Catalin Marinas
2019-05-24 14:25 ` Khalid Aziz
2019-05-24 14:25 ` Khalid Aziz
2019-05-24 14:25 ` Khalid Aziz
2019-05-24 14:25 ` Khalid Aziz
2019-05-24 14:25 ` khalid.aziz
2019-05-24 14:25 ` Khalid Aziz
2019-05-28 14:14 ` Andrey Konovalov
2019-05-28 14:14 ` Andrey Konovalov
2019-05-28 14:14 ` Andrey Konovalov
2019-05-28 14:14 ` Andrey Konovalov
2019-05-28 14:14 ` andreyknvl
2019-05-28 14:14 ` Andrey Konovalov
2019-05-29 6:11 ` Christoph Hellwig
2019-05-29 6:11 ` Christoph Hellwig
2019-05-29 6:11 ` Christoph Hellwig
2019-05-29 6:11 ` Christoph Hellwig
2019-05-29 6:11 ` hch
2019-05-29 6:11 ` Christoph Hellwig
2019-05-29 12:12 ` Catalin Marinas
2019-05-29 12:12 ` Catalin Marinas
2019-05-29 12:12 ` Catalin Marinas
2019-05-29 12:12 ` Catalin Marinas
2019-05-29 12:12 ` catalin.marinas
2019-05-29 12:12 ` Catalin Marinas
2019-05-30 17:15 ` Catalin Marinas
2019-05-30 17:15 ` Catalin Marinas
2019-05-30 17:15 ` Catalin Marinas
2019-05-30 17:15 ` Catalin Marinas
2019-05-30 17:15 ` catalin.marinas
2019-05-30 17:15 ` Catalin Marinas
2019-05-31 14:29 ` Andrey Konovalov
2019-05-31 14:29 ` Andrey Konovalov
2019-05-31 14:29 ` Andrey Konovalov
2019-05-31 14:29 ` Andrey Konovalov
2019-05-31 14:29 ` andreyknvl
2019-05-31 14:29 ` Andrey Konovalov
2019-05-31 16:19 ` Catalin Marinas
2019-05-31 16:19 ` Catalin Marinas
2019-05-31 16:19 ` Catalin Marinas
2019-05-31 16:19 ` Catalin Marinas
2019-05-31 16:19 ` catalin.marinas
2019-05-31 16:19 ` Catalin Marinas
2019-05-31 16:24 ` Andrey Konovalov
2019-05-31 16:24 ` Andrey Konovalov
2019-05-31 16:24 ` Andrey Konovalov
2019-05-31 16:24 ` Andrey Konovalov
2019-05-31 16:24 ` andreyknvl
2019-05-31 16:24 ` Andrey Konovalov
2019-05-31 16:46 ` Catalin Marinas
2019-05-31 16:46 ` Catalin Marinas
2019-05-31 16:46 ` Catalin Marinas
2019-05-31 16:46 ` Catalin Marinas
2019-05-31 16:46 ` catalin.marinas
2019-05-31 16:46 ` Catalin Marinas
2019-05-21 18:48 ` Jason Gunthorpe
2019-05-21 18:48 ` Jason Gunthorpe
2019-05-21 18:48 ` Jason Gunthorpe
2019-05-21 18:48 ` jgg
2019-05-21 18:48 ` Jason Gunthorpe
2019-05-22 13:49 ` Dave Martin
2019-05-22 13:49 ` Dave Martin
2019-05-22 13:49 ` Dave Martin
2019-05-22 13:49 ` Dave.Martin
2019-05-22 13:49 ` Dave Martin
2019-05-23 0:20 ` Jason Gunthorpe
2019-05-23 0:20 ` Jason Gunthorpe
2019-05-23 0:20 ` Jason Gunthorpe
2019-05-23 0:20 ` jgg
2019-05-23 0:20 ` Jason Gunthorpe
2019-05-23 10:42 ` Dave Martin
2019-05-23 10:42 ` Dave Martin
2019-05-23 10:42 ` Dave Martin
2019-05-23 10:42 ` Dave.Martin
2019-05-23 10:42 ` Dave Martin
2019-05-23 16:57 ` Catalin Marinas [this message]
2019-05-23 16:57 ` Catalin Marinas
2019-05-23 16:57 ` Catalin Marinas
2019-05-23 16:57 ` catalin.marinas
2019-05-23 16:57 ` Catalin Marinas
2019-05-24 14:23 ` Dave Martin
2019-05-24 14:23 ` Dave Martin
2019-05-24 14:23 ` Dave Martin
2019-05-24 14:23 ` Dave.Martin
2019-05-24 14:23 ` 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=20190523165708.q6ru7xg45aqfjzpr@mbp \
--to=catalin.marinas@arm.com \
--cc=Christian.Koenig@amd.com \
--cc=Dave.Martin@arm.com \
--cc=Jacob.Bramley@arm.com \
--cc=Lee.Smith@arm.com \
--cc=Ruben.Ayrapetyan@arm.com \
--cc=Szabolcs.Nagy@arm.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=andreyknvl@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=eugenis@google.com \
--cc=jgg@ziepe.ca \
--cc=keescook@chromium.org \
--cc=kevin.brodsky@arm.c \
--cc=kvm@vger.kernel.org \
--cc=leon@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=vincenzo.frascino@arm.com \
--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.