From: Mike Rapoport
The test verifies that file descriptor created with memfd_secret does
not allow read/write operations, that secret memory mappings respect
RLIMIT_MEMLOCK and that remote accesses with process_vm_read() and
ptrace() to the secret memory fail.
Signed-off-by: Mike Rapoport
From: Mike Rapoport
It will be used by the upcoming secret memory implementation.
Signed-off-by: Mike Rapoport
---
mm/internal.h | 3 +++
mm/mmap.c | 5 ++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/mm/internal.h b/mm/internal.h
index c43ccdddb0f6..ae146a260b14
From: Mike Rapoport
Account memory consumed by secretmem to memcg. The accounting is updated
when the memory is actually allocated and freed.
Signed-off-by: Mike Rapoport
---
mm/filemap.c | 3 ++-
mm/secretmem.c | 36 +++-
2 files changed, 37 insertions
From: Mike Rapoport
The definition of PMD_PAGE_ORDER denoting the number of base pages in the
second-level leaf page is already used by DAX and maybe handy in other
cases as well.
Several architectures already have definition of PMD_ORDER as the size of
second level page table, so to avoid
From: Mike Rapoport
Removing a PAGE_SIZE page from the direct map every time such page is
allocated for a secret memory mapping will cause severe fragmentation of
the direct map. This fragmentation can be reduced by using PMD-size pages
as a pool for small pages for secret memory mappings.
Add
From: Mike Rapoport
Hi,
This is an implementation of "secret" mappings backed by a file descriptor.
The file descriptor backing secret memory mappings is created using a
dedicated memfd_secret system call The desired protection mode for the
memory is configured using flags
On Tue, Nov 17, 2020 at 04:09:39PM +0100, David Hildenbrand wrote:
> On 15.11.20 09:26, Mike Rapoport wrote:
> > On Thu, Nov 12, 2020 at 09:15:18PM +0100, David Hildenbrand wrote:
...
> > My thinking was that since secretmem does what mlock() does wrt
> > swapability, it
On Mon, Nov 16, 2020 at 05:05:37PM +0530, Faiyaz Mohammed wrote:
> __init is used with inline due to which memblock wraper functions are
> not getting inline.
> for example:
> [0.00] memblock_alloc_try_nid: 1490 bytes align=0x40 nid=-1
> from=0x max_addr=0x
Hi Adrian,
On Tue, Nov 17, 2020 at 09:07:25AM +0100, John Paul Adrian Glaubitz wrote:
> Hi Mike!
>
> On 11/17/20 7:23 AM, Mike Rapoport wrote:
> > There were minor differences only for m68k between the versions. I've
> > verified them on ARAnyM but if you have a real mach
On Mon, Nov 16, 2020 at 11:05:54PM +0300, Serge Semin wrote:
> On Mon, Nov 16, 2020 at 06:45:15PM +0100, Thomas Bogendoerfer wrote:
> > The loop over all memblocks works with PFN numbers and not physical
> > addresses, so we need for_each_mem_pfn_range().
>
> Great catch! Don't know how that has
On Tue, Nov 17, 2020 at 06:40:16AM +, Vineet Gupta wrote:
> Hi Mike,
>
> On 11/1/20 9:04 AM, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > Currently ARC uses DISCONTIGMEM to cope with sparse physical memory address
> > space on systems with 2 memory
On Mon, Nov 16, 2020 at 10:01:37PM +0100, Alejandro Colomar wrote:
> From: Mike Rapoport
>
> Signed-off-by: Mike Rapoport
> Cowritten-by: Alejandro Colomar
> Acked-by: Alejandro Colomar
> Signed-off-by: Alejandro Colomar
> ---
>
> Hi Mike,
>
> I added tha
Hi Adrian,
On Tue, Nov 17, 2020 at 06:24:51AM +0100, John Paul Adrian Glaubitz wrote:
> Hi!
>
> On 11/1/20 6:04 PM, Mike Rapoport wrote:
> > It's been a while since DISCONTIGMEM is generally considered deprecated,
> > but it is still used by four architectures. This set
m_range()")
> Signed-off-by: Thomas Bogendoerfer
Reviewed-by: Mike Rapoport
Thanks, Thomas!
> ---
> arch/mips/kernel/setup.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> index
On Mon, Nov 16, 2020 at 10:14:04AM +0530, Faiyaz Mohammed wrote:
> It is useful to know the exact caller of memblock_phys_alloc_range() to
> track early memory reservations during development.
>
> Currently, when memblock debugging is enabled, the allocations done with
>
On Fri, Nov 13, 2020 at 03:42:25PM -0800, Roman Gushchin wrote:
> вт, 10 нояб. 2020 г. в 07:16, Mike Rapoport :
> >
> > From: Mike Rapoport
> >
> > Account memory consumed by secretmem to memcg. The accounting is updated
> > when the memory is actually alloca
On Fri, Nov 13, 2020 at 05:14:52PM -0800, Andrew Morton wrote:
> On Fri, 13 Nov 2020 18:02:39 +1100 Stephen Rothwell
> wrote:
>
> > Hi all,
> >
> > After merging the akpm tree, today's linux-next build (i386 defconfig)
> > failed like this:
> >
> > mm/secretmem.c: In function
On Fri, Nov 13, 2020 at 12:25:08PM +, Catalin Marinas wrote:
> Hi Mike,
>
> On Tue, Nov 10, 2020 at 05:14:43PM +0200, Mike Rapoport wrote:
> > diff --git a/arch/arm64/include/asm/unistd32.h
> > b/arch/arm64/include/asm/unistd32.h
> > index 6c1dcca067e0..c71c3fe
On Fri, Nov 13, 2020 at 02:06:56PM +, Matthew Wilcox wrote:
> On Tue, Nov 10, 2020 at 05:14:39PM +0200, Mike Rapoport wrote:
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index c89c5444924b..d8d170fa5210 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
>
On Fri, Nov 13, 2020 at 01:58:48PM +, Matthew Wilcox wrote:
> On Tue, Nov 10, 2020 at 05:14:39PM +0200, Mike Rapoport wrote:
> > +static vm_fault_t secretmem_fault(struct vm_fault *vmf)
> > +{
> > + struct address_space *mapping = vmf->vma->vm_file->f_mappin
On Thu, Nov 12, 2020 at 09:15:18PM +0100, David Hildenbrand wrote:
>
> > Am 12.11.2020 um 20:08 schrieb Mike Rapoport :
> >
> > On Thu, Nov 12, 2020 at 05:22:00PM +0100, David Hildenbrand wrote:
> >>> On 10.11.20 19:06, Mike Rapoport wrote:
> >>> On
On Thu, Nov 12, 2020 at 05:41:50PM +, Matthew Wilcox wrote:
> On Wed, Oct 28, 2020 at 09:50:56AM +0200, Mike Rapoport wrote:
> > > @@ -2074,8 +2074,8 @@ EXPORT_SYMBOL(find_get_pages_contig);
> > > * @nr_pages:the maximum number of pages
> > > * @pages:
On Thu, Nov 12, 2020 at 05:22:00PM +0100, David Hildenbrand wrote:
> On 10.11.20 19:06, Mike Rapoport wrote:
> > On Tue, Nov 10, 2020 at 06:17:26PM +0100, David Hildenbrand wrote:
> > > On 10.11.20 16:14, Mike Rapoport wrote:
> > > > From: Mike Rapoport
&g
Hi Andrew,
It'll be great if this can be pulled back to mmotm for wider exposure to
testing and fuzzing.
On Tue, Nov 10, 2020 at 05:14:35PM +0200, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Hi,
>
> This is an implementation of "secret" mappings backed by a file
On Wed, Nov 11, 2020 at 09:54:48PM +0800, Baoquan He wrote:
> On 11/11/20 at 09:27pm, chenzhou wrote:
> > Hi Baoquan,
> ...
> > >> #ifdef CONFIG_CRASH_DUMP
> > >> static int __init early_init_dt_scan_elfcorehdr(unsigned long node,
> > >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> >
On Sat, Oct 31, 2020 at 03:44:33PM +0800, Chen Zhou wrote:
> Make the functions reserve_crashkernel[_low]() as generic.
> Arm64 will use these to reimplement crashkernel=X.
>
> Signed-off-by: Chen Zhou
> Tested-by: John Donnelly
> ---
> arch/x86/include/asm/kexec.h | 25 ++
>
Hi,
On Sat, Oct 31, 2020 at 03:44:30PM +0800, Chen Zhou wrote:
> Move CRASH_ALIGN to header asm/kexec.h and replace the hard-coded
> alignment with macro CRASH_ALIGN in function reserve_crashkernel().
>
> Suggested-by: Dave Young
> Signed-off-by: Chen Zhou
> Tested-by: John Donnelly
> ---
>
On Wed, Nov 11, 2020 at 03:15:11PM +0530, Faiyaz Mohammed wrote:
>
> On 11/11/2020 12:11 AM, Mike Rapoport wrote:
> > Hi,
> >
> > On Tue, Nov 10, 2020 at 05:50:17PM +0530, Faiyaz Mohammed wrote:
> > > Since memblock_alloc is not getting inlined, memblock_reserv
On Wed, Nov 11, 2020 at 01:30:40PM +0530, Faiyaz Mohammed wrote:
>
> On 11/10/2020 11:46 PM, Mike Rapoport wrote:
> > Hi,
> >
> > On Tue, Nov 10, 2020 at 05:49:58PM +0530, Faiyaz Mohammed wrote:
> > > Exact caller of memblock_phys_alloc_range is not available w
On Wed, Nov 11, 2020 at 11:57:02AM +0100, Arnd Bergmann wrote:
> On Wed, Nov 11, 2020 at 11:26 AM Mike Rapoport wrote:
> >
> > On Wed, Nov 11, 2020 at 10:33:29AM +0100, Arnd Bergmann wrote:
> > > On Tue, Nov 10, 2020 at 5:21 PM Mike Rapoport wrote:
> > > >
On Wed, Nov 11, 2020 at 10:33:29AM +0100, Arnd Bergmann wrote:
> On Tue, Nov 10, 2020 at 5:21 PM Mike Rapoport wrote:
> > On Tue, Nov 10, 2020 at 12:21:11PM +0100, Arnd Bergmann wrote:
> > >
> > > To be on the safe side, we could provoke a compile-time error
> >
emory to be unplugged will be cleared. While this is
> suboptimal, it's similar to memory balloon drivers handling, where
> all pages to be inflated will get cleared as well.
>
> Cc: Andrew Morton
> Cc: Alexander Potapenko
> Cc: Michal Hocko
> Cc: Mike Kravetz
&g
Hi,
On Tue, Nov 10, 2020 at 03:36:20PM -0800, Minchan Kim wrote:
> On Tue, Nov 10, 2020 at 06:21:55PM +0200, Mike Rapoport wrote:
> > On Tue, Nov 10, 2020 at 12:21:11PM +0100, Arnd Bergmann wrote:
> > > On Tue, Nov 10, 2020 at 10:58 AM Mike Rapoport wrote:
> > > > &
Hi,
On Tue, Nov 10, 2020 at 05:50:17PM +0530, Faiyaz Mohammed wrote:
> Since memblock_alloc is not getting inlined, memblock_reserve owner info
> is lost. Below information is not enough for memory accounting.
> for example:
> [0.00] memblock_alloc_try_nid: 1490 bytes align=0x40 nid=-1
>
Hi,
On Tue, Nov 10, 2020 at 05:49:58PM +0530, Faiyaz Mohammed wrote:
> Exact caller of memblock_phys_alloc_range is not available with
> "memblock=debug". Below information is not enough for memory accounting.
> for example:
> [0.00] memblock_reserve:
On Tue, Nov 10, 2020 at 06:17:26PM +0100, David Hildenbrand wrote:
> On 10.11.20 16:14, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > It will be used by the upcoming secret memory implementation.
> >
> > Signed-off-by: Mike Rapoport
> > ---
>
On Tue, Nov 10, 2020 at 12:21:11PM +0100, Arnd Bergmann wrote:
> On Tue, Nov 10, 2020 at 10:58 AM Mike Rapoport wrote:
> > > >
> > > > asm/sparsemem.h is not available on some architectures.
> > > > It's better to use linux/mmzone.h instead.
>
&g
From: Mike Rapoport
Wire up memfd_secret system call on architectures that define
ARCH_HAS_SET_DIRECT_MAP, namely arm64, risc-v and x86.
Signed-off-by: Mike Rapoport
Acked-by: Palmer Dabbelt
Acked-by: Arnd Bergmann
---
arch/arm64/include/asm/unistd.h| 2 +-
arch/arm64/include/asm
From: Mike Rapoport
The test verifies that file descriptor created with memfd_secret does
not allow read/write operations, that secret memory mappings respect
RLIMIT_MEMLOCK and that remote accesses with process_vm_read() and
ptrace() to the secret memory fail.
Signed-off-by: Mike Rapoport
From: Mike Rapoport
Account memory consumed by secretmem to memcg. The accounting is updated
when the memory is actually allocated and freed.
Signed-off-by: Mike Rapoport
---
mm/filemap.c | 2 +-
mm/secretmem.c | 42 +-
2 files changed, 42 insertions
From: Mike Rapoport
It is unsafe to allow saving of secretmem areas to the hibernation snapshot
as they would be visible after the resume and this essentially will defeat
the purpose of secret memory mappings.
Prevent hibernation whenever there are active secret memory users.
Signed-off
From: Mike Rapoport
Removing a PAGE_SIZE page from the direct map every time such page is
allocated for a secret memory mapping will cause severe fragmentation of
the direct map. This fragmentation can be reduced by using PMD-size pages
as a pool for small pages for secret memory mappings.
Add
From: Mike Rapoport
Introduce "memfd_secret" 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 me
From: Mike Rapoport
The underlying implementations of set_direct_map_invalid_noflush() and
set_direct_map_default_noflush() allow updating multiple contiguous pages
at once.
Add numpages parameter to set_direct_map_*_noflush() to expose this ability
with these APIs.
Signed-off-by: Mike
From: Mike Rapoport
It will be used by the upcoming secret memory implementation.
Signed-off-by: Mike Rapoport
---
mm/internal.h | 3 +++
mm/mmap.c | 5 ++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/mm/internal.h b/mm/internal.h
index c43ccdddb0f6..ae146a260b14
From: Mike Rapoport
The definition of PMD_PAGE_ORDER denoting the number of base pages in the
second-level leaf page is already used by DAX and maybe handy in other
cases as well.
Several architectures already have definition of PMD_ORDER as the size of
second level page table, so to avoid
From: Mike Rapoport
Hi,
This is an implementation of "secret" mappings backed by a file descriptor.
The file descriptor backing secret memory mappings is created using a
dedicated memfd_secret system call The desired protection mode for the
memory is configured using flags
On Tue, Nov 10, 2020 at 10:29:54AM +0100, Stefan Agner wrote:
> On 2020-11-08 07:46, Mike Rapoport wrote:
> > On Sat, Nov 07, 2020 at 04:22:06PM +0100, Stefan Agner wrote:
> >> Most architectures define MAX_PHYSMEM_BITS in asm/sparsemem.h and don't
> >> include it in
From: Mike Rapoport
For architectures that enable ARCH_HAS_SET_MEMORY having the ability to
verify that a page is mapped in the kernel direct map can be useful
regardless of hibernation.
Add RISC-V implementation of kernel_page_present(), update its forward
declarations and stubs to be a part
From: Mike Rapoport
The design of DEBUG_PAGEALLOC presumes that __kernel_map_pages() must never
fail. With this assumption is wouldn't be safe to allow general usage of
this function.
Moreover, some architectures that implement __kernel_map_pages() have this
function guarded by #ifdef
From: Mike Rapoport
When CONFIG_DEBUG_PAGEALLOC is enabled, it unmaps pages from the kernel
direct mapping after free_pages(). The pages than need to be mapped back
before they could be used. Theese mapping operations use
__kernel_map_pages() guarded with with debug_pagealloc_enabled
From: Mike Rapoport
When DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP is enabled a page may be
not present in the direct map and has to be explicitly mapped before it
could be copied.
Introduce hibernate_map_page() and hibernation_unmap_page() that will
explicitly use set_direct_map_{default
From: Mike Rapoport
Hi,
During recent discussion about KVM protected memory, David raised a concern
about usage of __kernel_map_pages() outside of DEBUG_PAGEALLOC scope [1].
Indeed, for architectures that define CONFIG_ARCH_HAS_SET_DIRECT_MAP it is
possible that __kernel_map_pages() would fail
Oops, this one has some rebase errors, I'll send v7 soon.
Sorry for the noise.
On Mon, Nov 09, 2020 at 06:24:11PM +0200, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Hi,
>
> During recent discussion about KVM protected memory, David raised a concern
> about usage of
From: Mike Rapoport
For architectures that enable ARCH_HAS_SET_MEMORY having the ability to
verify that a page is mapped in the kernel direct map can be useful
regardless of hibernation.
Add RISC-V implementation of kernel_page_present(), update its forward
declarations and stubs to be a part
From: Mike Rapoport
When DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP is enabled a page may be
not present in the direct map and has to be explicitly mapped before it
could be copied.
Introduce hibernate_map_page() and hibernation_unmap_page() that will
explicitly use set_direct_map_{default
From: Mike Rapoport
The design of DEBUG_PAGEALLOC presumes that __kernel_map_pages() must never
fail. With this assumption is wouldn't be safe to allow general usage of
this function.
Moreover, some architectures that implement __kernel_map_pages() have this
function guarded by #ifdef
From: Mike Rapoport
Hi,
During recent discussion about KVM protected memory, David raised a concern
about usage of __kernel_map_pages() outside of DEBUG_PAGEALLOC scope [1].
Indeed, for architectures that define CONFIG_ARCH_HAS_SET_DIRECT_MAP it is
possible that __kernel_map_pages() would fail
From: Mike Rapoport
When CONFIG_DEBUG_PAGEALLOC is enabled, it unmaps pages from the kernel
direct mapping after free_pages(). The pages than need to be mapped back
before they could be used. Theese mapping operations use
__kernel_map_pages() guarded with with debug_pagealloc_enabled
On Mon, Nov 09, 2020 at 12:33:46PM +0100, Vlastimil Babka wrote:
> On 11/8/20 7:57 AM, Mike Rapoport wrote:
> > --- a/mm/slab.c
> > +++ b/mm/slab.c
> > @@ -1428,21 +1428,19 @@ static bool is_debug_pagealloc_cache(struct
> > kmem_cache *cachep)
> >
From: Mike Rapoport
For architectures that enable ARCH_HAS_SET_MEMORY having the ability to
verify that a page is mapped in the kernel direct map can be useful
regardless of hibernation.
Add RISC-V implementation of kernel_page_present(), update its forward
declarations and stubs to be a part
From: Mike Rapoport
When DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP is enabled a page may be
not present in the direct map and has to be explicitly mapped before it
could be copied.
Introduce hibernate_map_page() and hibernation_unmap_page() that will
explicitly use set_direct_map_{default
From: Mike Rapoport
The design of DEBUG_PAGEALLOC presumes that __kernel_map_pages() must never
fail. With this assumption is wouldn't be safe to allow general usage of
this function.
Moreover, some architectures that implement __kernel_map_pages() have this
function guarded by #ifdef
From: Mike Rapoport
Instead of using slab_kernel_map() with 'map' parameter to remap pages when
DEBUG_PAGEALLOC is enabled, use dedicated helpers slab_kernel_map() and
slab_kernel_unmap().
Signed-off-by: Mike Rapoport
---
mm/slab.c | 26 +++---
1 file changed, 15
From: Mike Rapoport
Hi,
During recent discussion about KVM protected memory, David raised a concern
about usage of __kernel_map_pages() outside of DEBUG_PAGEALLOC scope [1].
Indeed, for architectures that define CONFIG_ARCH_HAS_SET_DIRECT_MAP it is
possible that __kernel_map_pages() would fail
From: Mike Rapoport
When CONFIG_DEBUG_PAGEALLOC is enabled, it unmaps pages from the kernel
direct mapping after free_pages(). The pages than need to be mapped back
before they could be used. Theese mapping operations use
__kernel_map_pages() guarded with with debug_pagealloc_enabled
On Sat, Nov 07, 2020 at 04:22:06PM +0100, Stefan Agner wrote:
> Most architectures define MAX_PHYSMEM_BITS in asm/sparsemem.h and don't
> include it in asm/pgtable.h. Include asm/sparsemem.h directly to get
> the MAX_PHYSMEM_BITS define on all architectures.
>
> This fixes a crash when accessing
On Sat, Nov 07, 2020 at 05:19:35PM +0800, Wang Qing wrote:
> writting -> writing
>
> Signed-off-by: Wang Qing
Reviewed-by: Mike Rapoport
> ---
> tools/testing/selftests/vm/userfaultfd.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a
On Sat, Nov 07, 2020 at 05:22:26PM +0800, Wang Qing wrote:
> Remove duplicate header which is included twice.
>
> Signed-off-by: Wang Qing
Reviewed-by: Mike Rapoport
> ---
> arch/arm/mach-sa1100/hackkit.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/a
On Sat, Nov 07, 2020 at 05:15:50PM +0800, Wang Qing wrote:
> Remove duplicate header which is included twice.
>
> Signed-off-by: Wang Qing
Reviewed-by: Mike Rapoport
> ---
> arch/arm/mm/mmu.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mm/m
Hi Linus,
The following changes since commit 4ef8451b332662d004df269d4cdeb7d9f31419b5:
Merge tag 'perf-tools-for-v5.10-2020-11-03' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux (2020-11-03 13:28:50
-0800)
are available in the Git repository at:
On Wed, Nov 04, 2020 at 07:02:20PM +0100, Vlastimil Babka wrote:
> On 11/3/20 5:20 PM, Mike Rapoport wrote:
> > From: Mike Rapoport
>
> Subject should have "on DEBUG_PAGEALLOC" ?
>
> > The design of DEBUG_PAGEALLOC presumes that __kernel_map_pages() must ne
On Wed, Nov 04, 2020 at 06:40:28PM +0100, Vlastimil Babka wrote:
> On 11/3/20 5:20 PM, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > When DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP is enabled a page may be
> > not present in the direct map and has to
On Wed, Nov 04, 2020 at 06:35:50PM +0100, Vlastimil Babka wrote:
> On 11/3/20 5:20 PM, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > When CONFIG_DEBUG_PAGEALLOC is enabled, it unmaps pages from the kernel
> > direct mapping after free_pages(). The pages
On Thu, Nov 05, 2020 at 06:45:04PM +1100, Anand K. Mistry wrote:
> SNIPPED
>
> > >
> > > Looks like left column became too wide, so rather than shift the right
> > > column to the right, I'd suggest to drop underscores in Speculation*.
> >
> > Hm. That makes it inconsistent with
On Thu, Nov 05, 2020 at 05:45:49PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (htmldocs)
> produced this warning:
>
> Documentation/filesystems/proc.rst:296: WARNING: Malformed table.
> Text in column margin in table line 61.
>
>
On Wed, Nov 04, 2020 at 12:39:13PM +0100, Hagen Paul Pfeifer wrote:
> > On 11/03/2020 5:30 PM Mike Rapoport wrote:
> >
> > > > As long as the task share the file descriptor, they can share the
> > > > secretmem pages, pretty much like normal memfd.
>
On Wed, Nov 04, 2020 at 10:50:07AM +0100, osalvador wrote:
> On Thu, Oct 29, 2020 at 05:27:17PM +0100, David Hildenbrand wrote:
> > Let's revert what we did in case seomthing goes wrong and we return an
> > error.
>
> Dumb question, but should not we do this for other arches as well?
It seems
Hi Russell,
On Sat, Oct 31, 2020 at 05:45:35PM +0200, Mike Rapoport wrote:
> On Sat, Oct 31, 2020 at 12:21:24PM +0100, Ard Biesheuvel wrote:
> > On Sat, 31 Oct 2020 at 12:04, Russell King - ARM Linux admin
> > wrote:
> > >
> > > Clearly, I wasn't blunt
On Wed, Nov 04, 2020 at 09:35:14AM +0100, Ard Biesheuvel wrote:
> On Sat, 31 Oct 2020 at 18:44, Max Filippov wrote:
> >
> > On Sat, Oct 31, 2020 at 10:16 AM Mike Rapoport wrote:
> > >
> > > On Sat, Oct 31, 2020 at 09:37:09AM -0700, Max Filippov wrote:
> > &
On Mon, Nov 02, 2020 at 06:51:25PM -0800, Sudarshan Rajagopalan wrote:
> On 2020-10-30 01:38, Mike Rapoport wrote:
> > On Thu, Oct 29, 2020 at 02:29:27PM -0700, Sudarshan Rajagopalan wrote:
> > > Hello all,
> > >
> > > We have a usecase where a module driver ad
On Tue, Nov 03, 2020 at 02:52:14PM +0100, Hagen Paul Pfeifer wrote:
> > On 11/02/2020 4:40 PM Mike Rapoport wrote:
>
> > > Isn't memfd_secret currently *unnecessarily* designed to be a "one task
> > > feature"? memfd_secret fulfills exactly two (generic) f
From: Mike Rapoport
The design of DEBUG_PAGEALLOC presumes that __kernel_map_pages() must never
fail. With this assumption is wouldn't be safe to allow general usage of
this function.
Moreover, some architectures that implement __kernel_map_pages() have this
function guarded by #ifdef
From: Mike Rapoport
For architectures that enable ARCH_HAS_SET_MEMORY having the ability to
verify that a page is mapped in the kernel direct map can be useful
regardless of hibernation.
Add RISC-V implementation of kernel_page_present(), update its forward
declarations and stubs to be a part
From: Mike Rapoport
When DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP is enabled a page may be
not present in the direct map and has to be explicitly mapped before it
could be copied.
Introduce hibernate_map_page() that will explicitly use
set_direct_map_{default,invalid}_noflush
From: Mike Rapoport
Hi,
During recent discussion about KVM protected memory, David raised a concern
about usage of __kernel_map_pages() outside of DEBUG_PAGEALLOC scope [1].
Indeed, for architectures that define CONFIG_ARCH_HAS_SET_DIRECT_MAP it is
possible that __kernel_map_pages() would fail
From: Mike Rapoport
When CONFIG_DEBUG_PAGEALLOC is enabled, it unmaps pages from the kernel
direct mapping after free_pages(). The pages than need to be mapped back
before they could be used. Theese mapping operations use
__kernel_map_pages() guarded with with debug_pagealloc_enabled
On Tue, Nov 03, 2020 at 05:39:16PM +0300, Kirill A. Shutemov wrote:
> On Tue, Nov 03, 2020 at 02:13:50PM +0200, Mike Rapoport wrote:
> > > > +
> > > > + if (WARN_ON(ret))
> > >
> > > _ONCE?
> >
> > I've changed it to p
On Tue, Nov 03, 2020 at 02:08:16PM +0300, Kirill A. Shutemov wrote:
> On Sun, Nov 01, 2020 at 07:08:13PM +0200, Mike Rapoport wrote:
> > diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
> > index 46b1804c1ddf..054c8cce4236 100644
> > --- a/kernel/power/snapsh
On Mon, Nov 02, 2020 at 06:51:09PM +0100, David Hildenbrand wrote:
> > > Assume you have a system with quite some ZONE_MOVABLE memory (esp. in
> > > virtualized environments), eating up a significant amount of !ZONE_MOVABLE
> > > memory dynamically at runtime can lead to non-obvious issues. It
On Mon, Nov 02, 2020 at 10:11:12AM +0100, David Hildenbrand wrote:
> On 24.09.20 15:28, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > Hi,
> >
> > This is an implementation of "secret" mappings backed by a file descriptor.
> > I'v
On Sun, Nov 01, 2020 at 12:09:35PM +0100, Hagen Paul Pfeifer wrote:
> * Mike Rapoport | 2020-09-24 16:28:58 [+0300]:
>
> >This is an implementation of "secret" mappings backed by a file descriptor.
> >I've dropped the boot time reservation patch for now as it
On Mon, Nov 02, 2020 at 10:28:14AM +0100, David Hildenbrand wrote:
> On 01.11.20 18:08, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > For architectures that enable ARCH_HAS_SET_MEMORY having the ability to
> > verify that a page is mapped in the kern
On Mon, Nov 02, 2020 at 10:23:20AM +0100, David Hildenbrand wrote:
>
> > int __init kernel_map_pages_in_pgd(pgd_t *pgd, u64 pfn, unsigned long
> > address,
> >unsigned numpages, unsigned long page_flags)
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
>
On Mon, Nov 02, 2020 at 10:19:36AM +0100, David Hildenbrand wrote:
> On 01.11.20 18:08, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > When DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP is enabled a page may be
> > not present in the direct map and has to
From: Mike Rapoport
For architectures that enable ARCH_HAS_SET_MEMORY having the ability to
verify that a page is mapped in the kernel direct map can be useful
regardless of hibernation.
Add RISC-V implementation of kernel_page_present(), update its forward
declarations and stubs to be a part
From: Mike Rapoport
Hi,
During recent discussion about KVM protected memory, David raised a concern
about usage of __kernel_map_pages() outside of DEBUG_PAGEALLOC scope [1].
Indeed, for architectures that define CONFIG_ARCH_HAS_SET_DIRECT_MAP it is
possible that __kernel_map_pages() would fail
From: Mike Rapoport
When CONFIG_DEBUG_PAGEALLOC is enabled, it unmaps pages from the kernel
direct mapping after free_pages(). The pages than need to be mapped back
before they could be used. Theese mapping operations use
__kernel_map_pages() guarded with with debug_pagealloc_enabled
From: Mike Rapoport
When DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP is enabled a page may be
not present in the direct map and has to be explicitly mapped before it
could be copied.
Introduce hibernate_map_page() that will explicitly use
set_direct_map_{default,invalid}_noflush
From: Mike Rapoport
The design of DEBUG_PAGEALLOC presumes that __kernel_map_pages() must never
fail. With this assumption is wouldn't be safe to allow general usage of
this function.
Moreover, some architectures that implement __kernel_map_pages() have this
function guarded by #ifdef
601 - 700 of 2824 matches
Mail list logo
