From: Arnd Bergmann <arnd@arndb.de>
To: Mike Rapoport <rppt@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Christopher Lameter <cl@linux.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Elena Reshetova <elena.reshetova@intel.com>,
"H. Peter Anvin" <hpa@zytor.com>, Idan Yaniv <idan.yaniv@ibm.com>,
Ingo Molnar <mingo@redhat.com>,
James Bottomley <jejb@linux.ibm.com>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Matthew Wilcox <willy@infradead.org>,
Mike Rapoport <rppt@linux.ibm.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Tycho Andersen <tycho@tycho.ws>, Will Deacon <will@kernel.org>,
Linux API <linux-api@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
linux-nvdimm@lists.01.org,
linux-riscv <linux-riscv@lists.infradead.org>,
the arch/x86 maintainers <x86@kernel.org>,
linaro-mm-sig@lists.linaro.org,
Sumit Semwal <sumit.semwal@linaro.org>
Subject: Re: [PATCH 3/6] mm: introduce secretmemfd system call to create "secret" memory areas
Date: Mon, 20 Jul 2020 13:30:13 +0200 [thread overview]
Message-ID: <CAK8P3a0NyvRMqH7X0YNO5E6DGtvZXD5ZcD6Y6n7AkocufkMnHA@mail.gmail.com> (raw)
In-Reply-To: <20200720092435.17469-4-rppt@kernel.org>
On Mon, Jul 20, 2020 at 11:25 AM Mike Rapoport <rppt@kernel.org> wrote:
>
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> Introduce "secretmemfd" system call with the ability to create memory areas
> visible only in the context of the owning process and not mapped not only
> to other processes but in the kernel page tables as well.
>
> The user will create a file descriptor using the secretmemfd system call
> where flags supplied as a parameter to this system call will define the
> desired protection mode for the memory associated with that file
> descriptor. Currently there are two protection modes:
>
> * exclusive - the memory area is unmapped from the kernel direct map and it
> is present only in the page tables of the owning mm.
> * uncached - the memory area is present only in the page tables of the
> owning mm and it is mapped there as uncached.
>
> For instance, the following example will create an uncached mapping (error
> handling is omitted):
>
> fd = secretmemfd(SECRETMEM_UNCACHED);
> ftruncate(fd, MAP_SIZE);
> ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
> fd, 0);
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
I wonder if this should be more closely related to dmabuf file
descriptors, which
are already used for a similar purpose: sharing access to secret memory areas
that are not visible to the OS but can be shared with hardware through device
drivers that can import a dmabuf file descriptor.
Arnd
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Mike Rapoport <rppt@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Christopher Lameter <cl@linux.com>,
Dan Williams <dan.j.williams@intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Elena Reshetova <elena.reshetova@intel.com>,
"H. Peter Anvin" <hpa@zytor.com>, Idan Yaniv <idan.yaniv@ibm.com>,
Ingo Molnar <mingo@redhat.com>,
James Bottomley <jejb@linux.ibm.com>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Matthew Wilcox <willy@infradead.org>,
Mike Rapoport <rppt@linux.ibm.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Tycho Andersen <tycho@tycho.ws>, Will Deacon <will@kernel.org>,
Linux API <linux-api@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
linux-nvdimm@lists.01.org,
linux-riscv <linux-riscv@lists.infradead.org>,
"the arch/x86 maintainers" <x86@kernel.org>,
linaro-mm-sig@lists.linaro.org,
Sumit Semwal <sumit.semwal@linaro.org>
Subject: Re: [PATCH 3/6] mm: introduce secretmemfd system call to create "secret" memory areas
Date: Mon, 20 Jul 2020 13:30:13 +0200 [thread overview]
Message-ID: <CAK8P3a0NyvRMqH7X0YNO5E6DGtvZXD5ZcD6Y6n7AkocufkMnHA@mail.gmail.com> (raw)
In-Reply-To: <20200720092435.17469-4-rppt@kernel.org>
On Mon, Jul 20, 2020 at 11:25 AM Mike Rapoport <rppt@kernel.org> wrote:
>
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> Introduce "secretmemfd" system call with the ability to create memory areas
> visible only in the context of the owning process and not mapped not only
> to other processes but in the kernel page tables as well.
>
> The user will create a file descriptor using the secretmemfd system call
> where flags supplied as a parameter to this system call will define the
> desired protection mode for the memory associated with that file
> descriptor. Currently there are two protection modes:
>
> * exclusive - the memory area is unmapped from the kernel direct map and it
> is present only in the page tables of the owning mm.
> * uncached - the memory area is present only in the page tables of the
> owning mm and it is mapped there as uncached.
>
> For instance, the following example will create an uncached mapping (error
> handling is omitted):
>
> fd = secretmemfd(SECRETMEM_UNCACHED);
> ftruncate(fd, MAP_SIZE);
> ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
> fd, 0);
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
I wonder if this should be more closely related to dmabuf file
descriptors, which
are already used for a similar purpose: sharing access to secret memory areas
that are not visible to the OS but can be shared with hardware through device
drivers that can import a dmabuf file descriptor.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Mike Rapoport <rppt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Alexander Viro
<viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>,
Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
Christopher Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>,
Dan Williams
<dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Dave Hansen <dave.hansen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
Elena Reshetova
<elena.reshetova-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>,
Idan Yaniv <idan.yaniv-qyM6JfAXOaQ@public.gmane.org>,
Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
James Bottomley <jejb-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>,
"Kirill A. Shutemov"
<kirill-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>,
Matthew Wilcox <willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
Mike Rapoport <rppt-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>,
Palmer Dabbelt <palmer-96lFi9zoCfxBDgjK7y7TUQ@public.gmane.org>,
Paul Walmsley
<paul.walmsley-SpMDHPYPyPbQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH 3/6] mm: introduce secretmemfd system call to create "secret" memory areas
Date: Mon, 20 Jul 2020 13:30:13 +0200 [thread overview]
Message-ID: <CAK8P3a0NyvRMqH7X0YNO5E6DGtvZXD5ZcD6Y6n7AkocufkMnHA@mail.gmail.com> (raw)
In-Reply-To: <20200720092435.17469-4-rppt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On Mon, Jul 20, 2020 at 11:25 AM Mike Rapoport <rppt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
> From: Mike Rapoport <rppt-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>
>
> Introduce "secretmemfd" system call with the ability to create memory areas
> visible only in the context of the owning process and not mapped not only
> to other processes but in the kernel page tables as well.
>
> The user will create a file descriptor using the secretmemfd system call
> where flags supplied as a parameter to this system call will define the
> desired protection mode for the memory associated with that file
> descriptor. Currently there are two protection modes:
>
> * exclusive - the memory area is unmapped from the kernel direct map and it
> is present only in the page tables of the owning mm.
> * uncached - the memory area is present only in the page tables of the
> owning mm and it is mapped there as uncached.
>
> For instance, the following example will create an uncached mapping (error
> handling is omitted):
>
> fd = secretmemfd(SECRETMEM_UNCACHED);
> ftruncate(fd, MAP_SIZE);
> ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
> fd, 0);
>
> Signed-off-by: Mike Rapoport <rppt-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>
I wonder if this should be more closely related to dmabuf file
descriptors, which
are already used for a similar purpose: sharing access to secret memory areas
that are not visible to the OS but can be shared with hardware through device
drivers that can import a dmabuf file descriptor.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Mike Rapoport <rppt@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Linux-MM <linux-mm@kvack.org>, "H. Peter Anvin" <hpa@zytor.com>,
Christopher Lameter <cl@linux.com>,
Idan Yaniv <idan.yaniv@ibm.com>,
Dan Williams <dan.j.williams@intel.com>,
Elena Reshetova <elena.reshetova@intel.com>,
linux-arch <linux-arch@vger.kernel.org>,
Tycho Andersen <tycho@tycho.ws>,
linux-nvdimm@lists.01.org, Will Deacon <will@kernel.org>,
the arch/x86 maintainers <x86@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
Mike Rapoport <rppt@linux.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
James Bottomley <jejb@linux.ibm.com>,
linaro-mm-sig@lists.linaro.org, Borislav Petkov <bp@alien8.de>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andy Lutomirski <luto@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Thomas Gleixner <tglx@linutronix.de>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux API <linux-api@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Sumit Semwal <sumit.semwal@linaro.org>
Subject: Re: [PATCH 3/6] mm: introduce secretmemfd system call to create "secret" memory areas
Date: Mon, 20 Jul 2020 13:30:13 +0200 [thread overview]
Message-ID: <CAK8P3a0NyvRMqH7X0YNO5E6DGtvZXD5ZcD6Y6n7AkocufkMnHA@mail.gmail.com> (raw)
In-Reply-To: <20200720092435.17469-4-rppt@kernel.org>
On Mon, Jul 20, 2020 at 11:25 AM Mike Rapoport <rppt@kernel.org> wrote:
>
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> Introduce "secretmemfd" system call with the ability to create memory areas
> visible only in the context of the owning process and not mapped not only
> to other processes but in the kernel page tables as well.
>
> The user will create a file descriptor using the secretmemfd system call
> where flags supplied as a parameter to this system call will define the
> desired protection mode for the memory associated with that file
> descriptor. Currently there are two protection modes:
>
> * exclusive - the memory area is unmapped from the kernel direct map and it
> is present only in the page tables of the owning mm.
> * uncached - the memory area is present only in the page tables of the
> owning mm and it is mapped there as uncached.
>
> For instance, the following example will create an uncached mapping (error
> handling is omitted):
>
> fd = secretmemfd(SECRETMEM_UNCACHED);
> ftruncate(fd, MAP_SIZE);
> ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
> fd, 0);
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
I wonder if this should be more closely related to dmabuf file
descriptors, which
are already used for a similar purpose: sharing access to secret memory areas
that are not visible to the OS but can be shared with hardware through device
drivers that can import a dmabuf file descriptor.
Arnd
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Mike Rapoport <rppt@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>,
Borislav Petkov <bp@alien8.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Christopher Lameter <cl@linux.com>,
Dan Williams <dan.j.williams@intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Elena Reshetova <elena.reshetova@intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Idan Yaniv <idan.yaniv@ibm.com>, Ingo Molnar <mingo@redhat.com>,
James Bottomley <jejb@linux.ibm.com>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Matthew Wilcox <willy@infradead.org>,
Mike Rapoport <rppt@linux.ibm.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Tycho Andersen <tycho@tycho.ws>, Will Deacon <will@kernel.org>,
Linux API <linux-api@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
linux-nvdimm@lists.01.org,
linux-riscv <linux-riscv@lists.infradead.org>,
"the arch/x86 maintainers" <x86@kernel.org>,
linaro-mm-sig@lists.linaro.org,
Sumit Semwal <sumit.semwal@linaro.org>
Subject: Re: [PATCH 3/6] mm: introduce secretmemfd system call to create "secret" memory areas
Date: Mon, 20 Jul 2020 13:30:13 +0200 [thread overview]
Message-ID: <CAK8P3a0NyvRMqH7X0YNO5E6DGtvZXD5ZcD6Y6n7AkocufkMnHA@mail.gmail.com> (raw)
In-Reply-To: <20200720092435.17469-4-rppt@kernel.org>
On Mon, Jul 20, 2020 at 11:25 AM Mike Rapoport <rppt@kernel.org> wrote:
>
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> Introduce "secretmemfd" system call with the ability to create memory areas
> visible only in the context of the owning process and not mapped not only
> to other processes but in the kernel page tables as well.
>
> The user will create a file descriptor using the secretmemfd system call
> where flags supplied as a parameter to this system call will define the
> desired protection mode for the memory associated with that file
> descriptor. Currently there are two protection modes:
>
> * exclusive - the memory area is unmapped from the kernel direct map and it
> is present only in the page tables of the owning mm.
> * uncached - the memory area is present only in the page tables of the
> owning mm and it is mapped there as uncached.
>
> For instance, the following example will create an uncached mapping (error
> handling is omitted):
>
> fd = secretmemfd(SECRETMEM_UNCACHED);
> ftruncate(fd, MAP_SIZE);
> ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
> fd, 0);
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
I wonder if this should be more closely related to dmabuf file
descriptors, which
are already used for a similar purpose: sharing access to secret memory areas
that are not visible to the OS but can be shared with hardware through device
drivers that can import a dmabuf file descriptor.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Mike Rapoport <rppt@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Linux-MM <linux-mm@kvack.org>, "H. Peter Anvin" <hpa@zytor.com>,
Christopher Lameter <cl@linux.com>,
Idan Yaniv <idan.yaniv@ibm.com>,
Dan Williams <dan.j.williams@intel.com>,
Elena Reshetova <elena.reshetova@intel.com>,
linux-arch <linux-arch@vger.kernel.org>,
Tycho Andersen <tycho@tycho.ws>,
linux-nvdimm@lists.01.org, Will Deacon <will@kernel.org>,
the arch/x86 maintainers <x86@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
Mike Rapoport <rppt@linux.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
James Bottomley <jejb@linux.ibm.com>,
linaro-mm-sig@lists.linaro.org, Borislav Petkov <bp@alien8.de>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andy Lutomirski <luto@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Thomas Gleixner <tglx@linutronix.de>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux API <linux-api@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Sumit Semwal <sumit.semwal@linaro.org>
Subject: Re: [PATCH 3/6] mm: introduce secretmemfd system call to create "secret" memory areas
Date: Mon, 20 Jul 2020 13:30:13 +0200 [thread overview]
Message-ID: <CAK8P3a0NyvRMqH7X0YNO5E6DGtvZXD5ZcD6Y6n7AkocufkMnHA@mail.gmail.com> (raw)
In-Reply-To: <20200720092435.17469-4-rppt@kernel.org>
On Mon, Jul 20, 2020 at 11:25 AM Mike Rapoport <rppt@kernel.org> wrote:
>
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> Introduce "secretmemfd" system call with the ability to create memory areas
> visible only in the context of the owning process and not mapped not only
> to other processes but in the kernel page tables as well.
>
> The user will create a file descriptor using the secretmemfd system call
> where flags supplied as a parameter to this system call will define the
> desired protection mode for the memory associated with that file
> descriptor. Currently there are two protection modes:
>
> * exclusive - the memory area is unmapped from the kernel direct map and it
> is present only in the page tables of the owning mm.
> * uncached - the memory area is present only in the page tables of the
> owning mm and it is mapped there as uncached.
>
> For instance, the following example will create an uncached mapping (error
> handling is omitted):
>
> fd = secretmemfd(SECRETMEM_UNCACHED);
> ftruncate(fd, MAP_SIZE);
> ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
> fd, 0);
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
I wonder if this should be more closely related to dmabuf file
descriptors, which
are already used for a similar purpose: sharing access to secret memory areas
that are not visible to the OS but can be shared with hardware through device
drivers that can import a dmabuf file descriptor.
Arnd
_______________________________________________
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:[~2020-07-20 11:30 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-20 9:24 [PATCH 0/6] mm: introduce secretmemfd system call to create "secret" memory areas Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` [PATCH 1/6] mm: add definition of PMD_PAGE_ORDER Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` [PATCH 2/6] mmap: make mlock_future_check() global Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` [PATCH 3/6] mm: introduce secretmemfd system call to create "secret" memory areas Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 11:30 ` Arnd Bergmann [this message]
2020-07-20 11:30 ` Arnd Bergmann
2020-07-20 11:30 ` Arnd Bergmann
2020-07-20 11:30 ` Arnd Bergmann
2020-07-20 11:30 ` Arnd Bergmann
2020-07-20 11:30 ` Arnd Bergmann
2020-07-20 14:20 ` Mike Rapoport
2020-07-20 14:20 ` Mike Rapoport
2020-07-20 14:20 ` Mike Rapoport
2020-07-20 14:20 ` Mike Rapoport
2020-07-20 14:20 ` Mike Rapoport
2020-07-20 14:34 ` Arnd Bergmann
2020-07-20 14:34 ` Arnd Bergmann
2020-07-20 14:34 ` Arnd Bergmann
2020-07-20 14:34 ` Arnd Bergmann
2020-07-20 14:34 ` Arnd Bergmann
2020-07-20 14:34 ` Arnd Bergmann
2020-07-20 17:46 ` Mike Rapoport
2020-07-20 17:46 ` Mike Rapoport
2020-07-20 17:46 ` Mike Rapoport
2020-07-20 17:46 ` Mike Rapoport
2020-07-20 17:46 ` Mike Rapoport
2020-07-20 15:51 ` James Bottomley
2020-07-20 15:51 ` James Bottomley
2020-07-20 15:51 ` James Bottomley
2020-07-20 15:51 ` James Bottomley
2020-07-20 15:51 ` James Bottomley
2020-07-20 18:08 ` Arnd Bergmann
2020-07-20 18:08 ` Arnd Bergmann
2020-07-20 18:08 ` Arnd Bergmann
2020-07-20 18:08 ` Arnd Bergmann
2020-07-20 18:08 ` Arnd Bergmann
2020-07-20 18:08 ` Arnd Bergmann
2020-07-20 19:16 ` James Bottomley
2020-07-20 19:16 ` James Bottomley
2020-07-20 19:16 ` James Bottomley
2020-07-20 19:16 ` James Bottomley
2020-07-20 19:16 ` James Bottomley
2020-07-20 20:05 ` Arnd Bergmann
2020-07-20 20:05 ` Arnd Bergmann
2020-07-20 20:05 ` Arnd Bergmann
2020-07-20 20:05 ` Arnd Bergmann
2020-07-20 20:05 ` Arnd Bergmann
2020-07-20 20:05 ` Arnd Bergmann
2020-07-21 10:59 ` Michael Kerrisk (man-pages)
2020-07-21 10:59 ` Michael Kerrisk (man-pages)
2020-07-21 10:59 ` Michael Kerrisk (man-pages)
2020-07-21 10:59 ` Michael Kerrisk (man-pages)
2020-07-21 10:59 ` Michael Kerrisk (man-pages)
2020-07-21 10:59 ` Michael Kerrisk (man-pages)
2020-07-20 9:24 ` [PATCH 4/6] arch, mm: wire up secretmemfd system call were relevant Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-26 17:44 ` Palmer Dabbelt
2020-07-26 17:44 ` Palmer Dabbelt
2020-07-26 17:44 ` Palmer Dabbelt
2020-07-26 17:44 ` Palmer Dabbelt
2020-07-26 17:44 ` Palmer Dabbelt
2020-07-20 9:24 ` [PATCH 5/6] mm: secretmem: use PMD-size pages to amortize direct map fragmentation Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` [PATCH 6/6] mm: secretmem: add ability to reserve memory at boot Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
2020-07-20 9:24 ` Mike Rapoport
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=CAK8P3a0NyvRMqH7X0YNO5E6DGtvZXD5ZcD6Y6n7AkocufkMnHA@mail.gmail.com \
--to=arnd@arndb.de \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=cl@linux.com \
--cc=dave.hansen@linux.intel.com \
--cc=elena.reshetova@intel.com \
--cc=hpa@zytor.com \
--cc=idan.yaniv@ibm.com \
--cc=jejb@linux.ibm.com \
--cc=kirill@shutemov.name \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-riscv@lists.infradead.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=peterz@infradead.org \
--cc=rppt@kernel.org \
--cc=rppt@linux.ibm.com \
--cc=sumit.semwal@linaro.org \
--cc=tglx@linutronix.de \
--cc=tycho@tycho.ws \
--cc=viro@zeniv.linux.org.uk \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=x86@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 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.