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>, linux-doc@vger.kernel.org, Will Deacon <will.deacon@arm.com>, Kostya Serebryany <kcc@google.com>, linux-kselftest@vger.kernel.org, Chintan Pandya <cpandya@codeaurora.org>, Shuah Khan <shuah@kernel.org>, Ingo Molnar <mingo@kernel.org>, linux-arch@vger.kernel.org, Jacob Bramley <Jacob.Bramley@arm.com>, Dmitry Vyukov <dvyukov@google.com>, Evgeniy Stepanov <eugenis@google.com>, Kees Cook <keescook@chromium.org>, Ruben Ayrapetyan <Ruben.Ayrapetyan@arm.com>, Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>, Al 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>, 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: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel Date: Wed, 1 Aug 2018 18:42:56 +0100 [thread overview] Message-ID: <20180801174256.5mbyf33eszml4nmu@armageddon.cambridge.arm.com> (raw) In-Reply-To: <CAAeHK+yWF05XoU+0iuJoXAL3cWgdtxbeLoBz169yP12W4LkcQw@mail.gmail.com> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote: > On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote: > > On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote: > >> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas > >> <catalin.marinas@arm.com> wrote: > >>> While I support this work, as a maintainer I'd like to understand > >>> whether we'd be in a continuous chase of ABI breaks with every kernel > >>> release or we have a better way to identify potential issues. Is there > >>> any way to statically analyse conversions from __user ptr to long for > >>> example? Or, could we get the compiler to do this for us? > >> > >> OK, got it, I'll try to figure out a way to find these conversions. > > > > I've prototyped a checker on top of clang static analyzer (initially > > looked at sparse, but couldn't find any documentation or examples). > > The results are here [1], search for "warning: user pointer cast". > > Sharing in case anybody wants to take a look, will look at them myself > > tomorrow. > > > > [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115 > > So the checker reports ~100 different places where a __user pointer > being casted. I've looked through them and found 3 places where we > need to add untagging. Source code lines below come from 4.18-rc2+ > (6f0d349d). [...] > I'll add the 3 patches with fixes to v5 of this patchset. Thanks for investigating. You can fix those three places in your code but I was rather looking for a way to check such casting in the future for newly added code. While for the khwasan we can assume it's a debug option, the tagged user pointers are ABI and we need to keep it stable. We could we actually add some macros for explicit conversion between __user ptr and long and silence the warning there (I guess this would work better for sparse). We can then detect new ptr to long casts as they appear. I just hope that's not too intrusive. (I haven't tried the sparse patch yet, hopefully sometime this week) -- Catalin
WARNING: multiple messages have this Message-ID
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>, linux-doc@vger.kernel.org, Will Deacon <will.deacon@arm.com>, Kostya Serebryany <kcc@google.com>, linux-kselftest@vger.kernel.org, Chintan Pandya <cpandya@codeaurora.org>, Shuah Khan <shuah@kernel.org>, Ingo Molnar <mingo@kernel.org>, linux-arch@vger.kernel.org, Jacob Bramley <Jacob.Bramley@arm.com>, Dmitry Vyukov <dvyukov@google.com>, Evgeniy Stepanov <eugenis@google.com>, Kees Cook <keescook@chromium.org>, Ruben Ayrapetyan <Ruben.Ayrapetyan@arm.com>, Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>, Al 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>, 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: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel Date: Wed, 1 Aug 2018 18:42:56 +0100 [thread overview] Message-ID: <20180801174256.5mbyf33eszml4nmu@armageddon.cambridge.arm.com> (raw) In-Reply-To: <CAAeHK+yWF05XoU+0iuJoXAL3cWgdtxbeLoBz169yP12W4LkcQw@mail.gmail.com> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote: > On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote: > > On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote: > >> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas > >> <catalin.marinas@arm.com> wrote: > >>> While I support this work, as a maintainer I'd like to understand > >>> whether we'd be in a continuous chase of ABI breaks with every kernel > >>> release or we have a better way to identify potential issues. Is there > >>> any way to statically analyse conversions from __user ptr to long for > >>> example? Or, could we get the compiler to do this for us? > >> > >> OK, got it, I'll try to figure out a way to find these conversions. > > > > I've prototyped a checker on top of clang static analyzer (initially > > looked at sparse, but couldn't find any documentation or examples). > > The results are here [1], search for "warning: user pointer cast". > > Sharing in case anybody wants to take a look, will look at them myself > > tomorrow. > > > > [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115 > > So the checker reports ~100 different places where a __user pointer > being casted. I've looked through them and found 3 places where we > need to add untagging. Source code lines below come from 4.18-rc2+ > (6f0d349d). [...] > I'll add the 3 patches with fixes to v5 of this patchset. Thanks for investigating. You can fix those three places in your code but I was rather looking for a way to check such casting in the future for newly added code. While for the khwasan we can assume it's a debug option, the tagged user pointers are ABI and we need to keep it stable. We could we actually add some macros for explicit conversion between __user ptr and long and silence the warning there (I guess this would work better for sparse). We can then detect new ptr to long casts as they appear. I just hope that's not too intrusive. (I haven't tried the sparse patch yet, hopefully sometime this week) -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID
From: catalin.marinas at arm.com (Catalin Marinas) Subject: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel Date: Wed, 1 Aug 2018 18:42:56 +0100 [thread overview] Message-ID: <20180801174256.5mbyf33eszml4nmu@armageddon.cambridge.arm.com> (raw) In-Reply-To: <CAAeHK+yWF05XoU+0iuJoXAL3cWgdtxbeLoBz169yP12W4LkcQw@mail.gmail.com> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote: > On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl at google.com> wrote: > > On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl at google.com> wrote: > >> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas > >> <catalin.marinas at arm.com> wrote: > >>> While I support this work, as a maintainer I'd like to understand > >>> whether we'd be in a continuous chase of ABI breaks with every kernel > >>> release or we have a better way to identify potential issues. Is there > >>> any way to statically analyse conversions from __user ptr to long for > >>> example? Or, could we get the compiler to do this for us? > >> > >> OK, got it, I'll try to figure out a way to find these conversions. > > > > I've prototyped a checker on top of clang static analyzer (initially > > looked at sparse, but couldn't find any documentation or examples). > > The results are here [1], search for "warning: user pointer cast". > > Sharing in case anybody wants to take a look, will look at them myself > > tomorrow. > > > > [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115 > > So the checker reports ~100 different places where a __user pointer > being casted. I've looked through them and found 3 places where we > need to add untagging. Source code lines below come from 4.18-rc2+ > (6f0d349d). [...] > I'll add the 3 patches with fixes to v5 of this patchset. Thanks for investigating. You can fix those three places in your code but I was rather looking for a way to check such casting in the future for newly added code. While for the khwasan we can assume it's a debug option, the tagged user pointers are ABI and we need to keep it stable. We could we actually add some macros for explicit conversion between __user ptr and long and silence the warning there (I guess this would work better for sparse). We can then detect new ptr to long casts as they appear. I just hope that's not too intrusive. (I haven't tried the sparse patch yet, hopefully sometime this week) -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID
From: catalin.marinas@arm.com (Catalin Marinas) Subject: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel Date: Wed, 1 Aug 2018 18:42:56 +0100 [thread overview] Message-ID: <20180801174256.5mbyf33eszml4nmu@armageddon.cambridge.arm.com> (raw) Message-ID: <20180801174256.H4UgDddVaKLSGEffGRDsWW13MczPJFX7weSNobR3dkw@z> (raw) In-Reply-To: <CAAeHK+yWF05XoU+0iuJoXAL3cWgdtxbeLoBz169yP12W4LkcQw@mail.gmail.com> On Mon, Jul 16, 2018@01:25:59PM +0200, Andrey Konovalov wrote: > On Thu, Jun 28, 2018@9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote: > > On Wed, Jun 27, 2018@5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote: > >> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas > >> <catalin.marinas@arm.com> wrote: > >>> While I support this work, as a maintainer I'd like to understand > >>> whether we'd be in a continuous chase of ABI breaks with every kernel > >>> release or we have a better way to identify potential issues. Is there > >>> any way to statically analyse conversions from __user ptr to long for > >>> example? Or, could we get the compiler to do this for us? > >> > >> OK, got it, I'll try to figure out a way to find these conversions. > > > > I've prototyped a checker on top of clang static analyzer (initially > > looked at sparse, but couldn't find any documentation or examples). > > The results are here [1], search for "warning: user pointer cast". > > Sharing in case anybody wants to take a look, will look at them myself > > tomorrow. > > > > [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115 > > So the checker reports ~100 different places where a __user pointer > being casted. I've looked through them and found 3 places where we > need to add untagging. Source code lines below come from 4.18-rc2+ > (6f0d349d). [...] > I'll add the 3 patches with fixes to v5 of this patchset. Thanks for investigating. You can fix those three places in your code but I was rather looking for a way to check such casting in the future for newly added code. While for the khwasan we can assume it's a debug option, the tagged user pointers are ABI and we need to keep it stable. We could we actually add some macros for explicit conversion between __user ptr and long and silence the warning there (I guess this would work better for sparse). We can then detect new ptr to long casts as they appear. I just hope that's not too intrusive. (I haven't tried the sparse patch yet, hopefully sometime this week) -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID
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>, linux-doc@vger.kernel.org, Will Deacon <will.deacon@arm.com>, Kostya Serebryany <kcc@google.com>, linux-kselftest@vger.kernel.org, Chintan Pandya <cpandya@codeaurora.org>, Shuah Khan <shuah@kernel.org>, Ingo Molnar <mingo@kernel.org>, linux-arch@vger.kernel.org, Jacob Bramley <Jacob.Bramley@arm.com>, Dmitry Vyukov <dvyukov@google.com>, Evgeniy Stepanov <eugenis@google.com>, Kees Cook <keescook@chromium.org>, Ruben Ayrapetyan <Ruben.Ayrapetyan@arm.com>, Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>, Al 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@linuxfoundati> Subject: Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel Date: Wed, 1 Aug 2018 18:42:56 +0100 [thread overview] Message-ID: <20180801174256.5mbyf33eszml4nmu@armageddon.cambridge.arm.com> (raw) In-Reply-To: <CAAeHK+yWF05XoU+0iuJoXAL3cWgdtxbeLoBz169yP12W4LkcQw@mail.gmail.com> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote: > On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote: > > On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote: > >> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas > >> <catalin.marinas@arm.com> wrote: > >>> While I support this work, as a maintainer I'd like to understand > >>> whether we'd be in a continuous chase of ABI breaks with every kernel > >>> release or we have a better way to identify potential issues. Is there > >>> any way to statically analyse conversions from __user ptr to long for > >>> example? Or, could we get the compiler to do this for us? > >> > >> OK, got it, I'll try to figure out a way to find these conversions. > > > > I've prototyped a checker on top of clang static analyzer (initially > > looked at sparse, but couldn't find any documentation or examples). > > The results are here [1], search for "warning: user pointer cast". > > Sharing in case anybody wants to take a look, will look at them myself > > tomorrow. > > > > [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115 > > So the checker reports ~100 different places where a __user pointer > being casted. I've looked through them and found 3 places where we > need to add untagging. Source code lines below come from 4.18-rc2+ > (6f0d349d). [...] > I'll add the 3 patches with fixes to v5 of this patchset. Thanks for investigating. You can fix those three places in your code but I was rather looking for a way to check such casting in the future for newly added code. While for the khwasan we can assume it's a debug option, the tagged user pointers are ABI and we need to keep it stable. We could we actually add some macros for explicit conversion between __user ptr and long and silence the warning there (I guess this would work better for sparse). We can then detect new ptr to long casts as they appear. I just hope that's not too intrusive. (I haven't tried the sparse patch yet, hopefully sometime this week) -- Catalin
WARNING: multiple messages have this Message-ID
From: catalin.marinas@arm.com (Catalin Marinas) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel Date: Wed, 1 Aug 2018 18:42:56 +0100 [thread overview] Message-ID: <20180801174256.5mbyf33eszml4nmu@armageddon.cambridge.arm.com> (raw) In-Reply-To: <CAAeHK+yWF05XoU+0iuJoXAL3cWgdtxbeLoBz169yP12W4LkcQw@mail.gmail.com> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote: > On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote: > > On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote: > >> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas > >> <catalin.marinas@arm.com> wrote: > >>> While I support this work, as a maintainer I'd like to understand > >>> whether we'd be in a continuous chase of ABI breaks with every kernel > >>> release or we have a better way to identify potential issues. Is there > >>> any way to statically analyse conversions from __user ptr to long for > >>> example? Or, could we get the compiler to do this for us? > >> > >> OK, got it, I'll try to figure out a way to find these conversions. > > > > I've prototyped a checker on top of clang static analyzer (initially > > looked at sparse, but couldn't find any documentation or examples). > > The results are here [1], search for "warning: user pointer cast". > > Sharing in case anybody wants to take a look, will look at them myself > > tomorrow. > > > > [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115 > > So the checker reports ~100 different places where a __user pointer > being casted. I've looked through them and found 3 places where we > need to add untagging. Source code lines below come from 4.18-rc2+ > (6f0d349d). [...] > I'll add the 3 patches with fixes to v5 of this patchset. Thanks for investigating. You can fix those three places in your code but I was rather looking for a way to check such casting in the future for newly added code. While for the khwasan we can assume it's a debug option, the tagged user pointers are ABI and we need to keep it stable. We could we actually add some macros for explicit conversion between __user ptr and long and silence the warning there (I guess this would work better for sparse). We can then detect new ptr to long casts as they appear. I just hope that's not too intrusive. (I haven't tried the sparse patch yet, hopefully sometime this week) -- Catalin
next prev parent reply other threads:[~2018-08-01 17:43 UTC|newest] Thread overview: 195+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-06-20 15:24 Andrey Konovalov 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` andreyknvl 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` [PATCH v4 1/7] arm64: add type casts to untagged_addr macro Andrey Konovalov 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` andreyknvl 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` [PATCH v4 2/7] uaccess: add untagged_addr definition for other arches Andrey Konovalov 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` andreyknvl 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` [PATCH v4 3/7] arm64: untag user addresses in access_ok and __uaccess_mask_ptr Andrey Konovalov 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` andreyknvl 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` [PATCH v4 4/7] mm, arm64: untag user addresses in mm/gup.c Andrey Konovalov 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` andreyknvl 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` [PATCH v4 5/7] lib, arm64: untag addrs passed to strncpy_from_user and strnlen_user Andrey Konovalov 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` andreyknvl 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` [PATCH v4 6/7] arm64: update Documentation/arm64/tagged-pointers.txt Andrey Konovalov 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` andreyknvl 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` [PATCH v4 7/7] selftests, arm64: add a selftest for passing tagged pointers to kernel Andrey Konovalov 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` Andrey Konovalov 2018-06-20 15:24 ` andreyknvl 2018-06-20 15:24 ` Andrey Konovalov 2018-06-26 12:47 ` [PATCH v4 0/7] arm64: untag user pointers passed to the kernel Andrey Konovalov 2018-06-26 12:47 ` Andrey Konovalov 2018-06-26 12:47 ` Andrey Konovalov 2018-06-26 12:47 ` andreyknvl 2018-06-26 12:47 ` Andrey Konovalov 2018-06-26 17:29 ` Catalin Marinas 2018-06-26 17:29 ` Catalin Marinas 2018-06-26 17:29 ` Catalin Marinas 2018-06-26 17:29 ` Catalin Marinas 2018-06-26 17:29 ` catalin.marinas 2018-06-26 17:29 ` Catalin Marinas 2018-06-27 15:05 ` Andrey Konovalov 2018-06-27 15:05 ` Andrey Konovalov 2018-06-27 15:05 ` Andrey Konovalov 2018-06-27 15:05 ` Andrey Konovalov 2018-06-27 15:05 ` andreyknvl 2018-06-27 15:05 ` Andrey Konovalov 2018-06-27 15:08 ` Ramana Radhakrishnan 2018-06-27 15:08 ` Ramana Radhakrishnan 2018-06-27 15:08 ` Ramana Radhakrishnan 2018-06-27 15:08 ` Ramana Radhakrishnan 2018-06-27 15:08 ` Ramana Radhakrishnan 2018-06-27 15:08 ` ramana.radhakrishnan 2018-06-27 15:08 ` Ramana Radhakrishnan 2018-06-27 17:17 ` Catalin Marinas 2018-06-27 17:17 ` Catalin Marinas 2018-06-27 17:17 ` Catalin Marinas 2018-06-27 17:17 ` Catalin Marinas 2018-06-27 17:17 ` Catalin Marinas 2018-06-27 17:17 ` catalin.marinas 2018-06-27 17:17 ` Catalin Marinas 2018-06-28 6:17 ` Luc Van Oostenryck 2018-06-28 6:17 ` Luc Van Oostenryck 2018-06-28 6:17 ` Luc Van Oostenryck 2018-06-28 6:17 ` Luc Van Oostenryck 2018-06-28 6:17 ` Luc Van Oostenryck 2018-06-28 6:17 ` luc.vanoostenryck 2018-06-28 6:17 ` Luc Van Oostenryck 2018-06-28 10:27 ` Catalin Marinas 2018-06-28 10:27 ` Catalin Marinas 2018-06-28 10:27 ` Catalin Marinas 2018-06-28 10:27 ` Catalin Marinas 2018-06-28 10:27 ` Catalin Marinas 2018-06-28 10:27 ` catalin.marinas 2018-06-28 10:27 ` Catalin Marinas 2018-06-28 10:46 ` Luc Van Oostenryck 2018-06-28 10:46 ` Luc Van Oostenryck 2018-06-28 10:46 ` Luc Van Oostenryck 2018-06-28 10:46 ` Luc Van Oostenryck 2018-06-28 10:46 ` Luc Van Oostenryck 2018-06-28 10:46 ` luc.vanoostenryck 2018-06-28 10:46 ` Luc Van Oostenryck 2018-06-28 14:48 ` Catalin Marinas 2018-06-28 14:48 ` Catalin Marinas 2018-06-28 14:48 ` Catalin Marinas 2018-06-28 14:48 ` Catalin Marinas 2018-06-28 14:48 ` Catalin Marinas 2018-06-28 14:48 ` catalin.marinas 2018-06-28 14:48 ` Catalin Marinas 2018-06-28 15:28 ` Luc Van Oostenryck 2018-06-28 15:28 ` Luc Van Oostenryck 2018-06-28 15:28 ` Luc Van Oostenryck 2018-06-28 15:28 ` Luc Van Oostenryck 2018-06-28 15:28 ` Luc Van Oostenryck 2018-06-28 15:28 ` luc.vanoostenryck 2018-06-28 15:28 ` Luc Van Oostenryck 2018-06-29 15:27 ` David Laight 2018-06-29 15:27 ` David Laight 2018-06-29 15:27 ` David Laight 2018-06-29 15:27 ` David Laight 2018-06-29 15:27 ` David Laight 2018-06-29 15:27 ` David.Laight 2018-06-29 15:27 ` David Laight 2018-06-28 23:21 ` [PATCH] sparse: stricter warning for explicit cast to ulong Luc Van Oostenryck 2018-06-28 23:21 ` Luc Van Oostenryck 2018-06-28 23:21 ` Luc Van Oostenryck 2018-06-28 23:21 ` Luc Van Oostenryck 2018-06-28 23:21 ` luc.vanoostenryck 2018-06-28 23:21 ` Luc Van Oostenryck 2018-06-28 23:21 ` Luc Van Oostenryck 2018-06-28 19:30 ` [PATCH v4 0/7] arm64: untag user pointers passed to the kernel Andrey Konovalov 2018-06-28 19:30 ` Andrey Konovalov 2018-06-28 19:30 ` Andrey Konovalov 2018-06-28 19:30 ` Andrey Konovalov 2018-06-28 19:30 ` andreyknvl 2018-06-28 19:30 ` Andrey Konovalov 2018-06-29 15:19 ` Andrey Konovalov 2018-06-29 15:19 ` Andrey Konovalov 2018-06-29 15:19 ` Andrey Konovalov 2018-06-29 15:19 ` Andrey Konovalov 2018-06-29 15:19 ` andreyknvl 2018-06-29 15:19 ` Andrey Konovalov 2018-06-29 15:20 ` Andrey Konovalov 2018-06-29 15:20 ` Andrey Konovalov 2018-06-29 15:20 ` Andrey Konovalov 2018-06-29 15:20 ` Andrey Konovalov 2018-06-29 15:20 ` andreyknvl 2018-06-29 15:20 ` Andrey Konovalov 2018-07-16 11:25 ` Andrey Konovalov 2018-07-16 11:25 ` Andrey Konovalov 2018-07-16 11:25 ` Andrey Konovalov 2018-07-16 11:25 ` Andrey Konovalov 2018-07-16 11:25 ` andreyknvl 2018-07-16 11:25 ` Andrey Konovalov 2018-07-31 13:23 ` Andrey Konovalov 2018-07-31 13:23 ` Andrey Konovalov 2018-07-31 13:23 ` Andrey Konovalov 2018-07-31 13:23 ` Andrey Konovalov 2018-07-31 13:23 ` andreyknvl 2018-07-31 13:23 ` Andrey Konovalov 2018-08-01 17:42 ` Catalin Marinas [this message] 2018-08-01 17:42 ` Catalin Marinas 2018-08-01 17:42 ` Catalin Marinas 2018-08-01 17:42 ` Catalin Marinas 2018-08-01 17:42 ` catalin.marinas 2018-08-01 17:42 ` Catalin Marinas 2018-08-02 15:00 ` Andrey Konovalov 2018-08-02 15:00 ` Andrey Konovalov 2018-08-02 15:00 ` Andrey Konovalov 2018-08-02 15:00 ` Andrey Konovalov 2018-08-02 15:00 ` andreyknvl 2018-08-02 15:00 ` Andrey Konovalov 2018-08-03 14:59 ` Andrey Konovalov 2018-08-03 14:59 ` Andrey Konovalov 2018-08-03 14:59 ` Andrey Konovalov 2018-08-03 14:59 ` Andrey Konovalov 2018-08-03 14:59 ` andreyknvl 2018-08-03 14:59 ` Andrey Konovalov 2018-08-03 15:09 ` Greg Kroah-Hartman 2018-08-03 15:09 ` Greg Kroah-Hartman 2018-08-03 15:09 ` Greg Kroah-Hartman 2018-08-03 15:09 ` Greg Kroah-Hartman 2018-08-03 15:09 ` gregkh 2018-08-03 15:09 ` Greg Kroah-Hartman 2018-08-03 16:43 ` Matthew Wilcox 2018-08-03 16:43 ` Matthew Wilcox 2018-08-03 16:43 ` Matthew Wilcox 2018-08-03 16:43 ` Matthew Wilcox 2018-08-03 16:43 ` willy 2018-08-03 16:43 ` Matthew Wilcox 2018-08-03 16:54 ` Andrey Konovalov 2018-08-03 16:54 ` Andrey Konovalov 2018-08-03 16:54 ` Andrey Konovalov 2018-08-03 16:54 ` Andrey Konovalov 2018-08-03 16:54 ` andreyknvl 2018-08-03 16:54 ` Andrey Konovalov 2018-08-06 19:12 ` Luc Van Oostenryck 2018-08-06 19:12 ` Luc Van Oostenryck 2018-08-06 19:12 ` Luc Van Oostenryck 2018-08-06 19:12 ` Luc Van Oostenryck 2018-08-06 19:12 ` luc.vanoostenryck 2018-08-06 19:12 ` 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=20180801174256.5mbyf33eszml4nmu@armageddon.cambridge.arm.com \ --to=catalin.marinas@arm.com \ --cc=Jacob.Bramley@arm.com \ --cc=Lee.Smith@arm.com \ --cc=Ramana.Radhakrishnan@arm.com \ --cc=Ruben.Ayrapetyan@arm.com \ --cc=akpm@linux-foundation.org \ --cc=andreyknvl@google.com \ --cc=cpandya@codeaurora.org \ --cc=dvyukov@google.com \ --cc=eugenis@google.com \ --cc=gregkh@linuxfoundation.org \ --cc=kcc@google.com \ --cc=keescook@chromium.org \ --cc=kirill.shutemov@linux.intel.com \ --cc=kstewart@linuxfoundation.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mark.rutland@arm.com \ --cc=mingo@kernel.org \ --cc=robin.murphy@arm.com \ --cc=shuah@kernel.org \ --cc=viro@zeniv.linux.org.uk \ --cc=will.deacon@arm.com \ --subject='Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel' \ /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
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.