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
Cc: Alexander Viro
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Catalin
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
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
On arm64, set_direct_map_*() functions may return 0 without actually
changing the linear map. This behaviour can be controlled using kernel
parameters, so we need a way to determine at runtime whether calls to
set_direct_map_invalid_noflush
From: Mike Rapoport
Hi,
@Andrew, this is based on v5.11-rc4-mmots-2021-01-19-13-54 with secretmem
patches dropped from there, I can rebase whatever way you prefer.
This is an implementation of "secret" mappings backed by a file descriptor.
The file descriptor backing secret memor
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
Cc
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
Cc: Alexander Viro
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Catalin
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
Account memory consumed by secretmem to memcg. The accounting is updated
when the memory is actually allocated and freed.
Signed-off-by: Mike Rapoport
Acked-by: Roman Gushchin
Reviewed-by: Shakeel Butt
Cc: Alexander Viro
Cc: Andy Lutomirski
Cc: Arnd Bergmann
Cc
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
On arm64, set_direct_map_*() functions may return 0 without actually
changing the linear map. This behaviour can be controlled using kernel
parameters, so we need a way to determine at runtime whether calls to
set_direct_map_invalid_noflush
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
ARCH_HAS_SET_DIRECT_MAP and ARCH_HAS_SET_MEMORY configuration options have
no meaning when CONFIG_MMU is disabled and there is no point to enable them
for the nommu case.
Add an explicit dependency on MMU for these options.
Signed-off-by: Mike Rapoport
Reported-by: kernel
From: Mike Rapoport
It will be used by the upcoming secret memory implementation.
Signed-off-by: Mike Rapoport
Cc: Alexander Viro
Cc: Andy Lutomirski
Cc: Arnd Bergmann
Cc: Borislav Petkov
Cc: Catalin Marinas
Cc: Christopher Lameter
Cc: Dan Williams
Cc: Dave Hansen
Cc: David Hildenbrand
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,
@Andrew, this is based on v5.11-rc4-mmots-2021-01-19-13-54 with secretmem
patches dropped from there, I can rebase whatever way you prefer.
This is an implementation of "secret" mappings backed by a file descriptor.
The file descriptor backing secret memor
On Wed, Jan 20, 2021 at 04:02:10PM +, Matthew Wilcox wrote:
> On Wed, Jan 20, 2021 at 05:05:10PM +0200, Mike Rapoport wrote:
> > On Tue, Jan 19, 2021 at 08:22:13PM +, Matthew Wilcox wrote:
> > > On Thu, Dec 03, 2020 at 08:29:44AM +0200, Mike Rapoport wrote:
> >
On Wed, Jan 20, 2021 at 04:02:10PM +, Matthew Wilcox wrote:
> On Wed, Jan 20, 2021 at 05:05:10PM +0200, Mike Rapoport wrote:
> > On Tue, Jan 19, 2021 at 08:22:13PM +, Matthew Wilcox wrote:
> > > On Thu, Dec 03, 2020 at 08:29:44AM +0200, Mike Rapoport wrote:
> >
On Tue, Jan 19, 2021 at 08:22:13PM +, Matthew Wilcox wrote:
> On Thu, Dec 03, 2020 at 08:29:44AM +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 Tue, Jan 19, 2021 at 08:22:13PM +, Matthew Wilcox wrote:
> On Thu, Dec 03, 2020 at 08:29:44AM +0200, Mike Rapoport wrote:
> > +static vm_fault_t secretmem_fault(struct vm_fault *vmf)
> > +{
> > + struct address_space *mapping = vmf->vma->vm_file->f_mappin
Mike Rapoport (1):
ia64: fix build failure caused by memory model changes
arch/ia64/include/asm/sparsemem.h | 1 +
1 file changed, 1 insertion(+)
--
Sincerely yours,
Mike.
From: Mike Rapoport
Currently the first several pages are reserved both to avoid leaking their
contents on systems with L1TF and to avoid corrupting BIOS memory.
Merge the two memory reservations.
Signed-off-by: Mike Rapoport
---
arch/x86/kernel/setup.c | 29 +++--
1
From: Mike Rapoport
The early reservations of memory areas used by the firmware, bootloader,
kernel text and data are spread over setup_arch(). Moreover, some of them
happen *after* memblock allocations, e.g trim_platform_memory_ranges() and
trim_low_memory_range() are called after
From: Mike Rapoport
Hi,
David noticed that we do some of memblock_reserve() calls after allocations
are possible:
https://lore.kernel.org/lkml/6ba6bde3-1520-5cd0-f987-32d543f0b...@redhat.com
For now there is no actual problem because in top-down mode we allocate
from the end of the memory
On Thu, Jan 14, 2021 at 04:08:17PM +0900, Daeseok Youn wrote:
> No one checks the return value of memblock_free_all().
> Make the return value void.
>
> memblock_free_all() is used on mem_init() for each
> architecture, and the total count of freed pages will be added
> to _totalram_pages
If there are no objections, I'll take it via the memblock tree.
@Tony an ack would be appreciated.
On Fri, Dec 18, 2020 at 06:35:50PM +0200, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The change of ia64's default memory model to SPARSEMEM causes defconfig
> build to fai
Andrew,
Would you like me to
On Fri, Dec 18, 2020 at 06:35:50PM +0200, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The change of ia64's default memory model to SPARSEMEM causes defconfig
> build to fail:
>
> CC kernel/async.o
> In file included from in
On Wed, Jan 13, 2021 at 01:56:45PM +0100, David Hildenbrand wrote:
> On 11.01.21 20:40, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The first 4Kb of memory is a BIOS owned area and to avoid its allocation
> > for the kernel it was not listed in e820 tabl
On Wed, Jan 13, 2021 at 09:56:49AM +0100, Oscar Salvador wrote:
> On Mon, Jan 11, 2021 at 09:40:16PM +0200, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The first 4Kb of memory is a BIOS owned area and to avoid its allocation
> > for the kernel it was not list
On Tue, Jan 12, 2021 at 10:53:45AM +, Guillaume Tucker wrote:
> On 05/01/2021 09:13, Mike Rapoport wrote:
> > On Sun, Jan 03, 2021 at 03:09:14PM -0500, Andrea Arcangeli wrote:
> >> Hello Mike,
> >>
> >> On Sun, Jan 03, 2021 at 03:47:53PM +0200, Mike Rapop
On Mon, Jan 11, 2021 at 04:58:01PM -0800, Andrew Morton wrote:
> On Mon, 11 Jan 2021 21:40:15 +0200 Mike Rapoport wrote:
>
> > Commit 73a6e474cb37 ("mm: memmap_init: iterate over
> > memblock regions rather that check each PFN") exposed several issues with
>
From: Mike Rapoport
There could be struct pages that are not backed by actual physical memory.
This can happen when the actual memory bank is not a multiple of
SECTION_SIZE or when an architecture does not register memory holes
reserved by the firmware as memblock.memory.
Such pages
From: Mike Rapoport
The first 4Kb of memory is a BIOS owned area and to avoid its allocation
for the kernel it was not listed in e820 tables as memory. As the result,
pfn 0 was never recognised by the generic memory management and it is not a
part of neither node 0 nor ZONE_DMA
From: Mike Rapoport
Hi,
Commit 73a6e474cb37 ("mm: memmap_init: iterate over
memblock regions rather that check each PFN") exposed several issues with
the memory map initialization and these patches fix those issues.
Initially there were crashes during compaction that Qian Cai rep
On Mon, Jan 11, 2021 at 10:06:43AM -0500, Qian Cai wrote:
> On Sun, 2021-01-10 at 17:39 +0200, Mike Rapoport wrote:
> > On Wed, Jan 06, 2021 at 04:04:21PM -0500, Qian Cai wrote:
> > > On Wed, 2021-01-06 at 10:05 +0200, Mike Rapoport wrote:
> > > > I think we trigger P
On Mon, Jan 11, 2021 at 11:31:02AM +0100, David Hildenbrand wrote:
> On 04.01.21 07:18, Anshuman Khandual wrote:
...
> >> Actually, I think we want to check for partial present sections.
> >>
> >> Maybe we can rather switch to generic pfn_valid() and tweak it to
> >> something like
> >>
> >>
On Wed, Jan 06, 2021 at 04:04:21PM -0500, Qian Cai wrote:
> On Wed, 2021-01-06 at 10:05 +0200, Mike Rapoport wrote:
> > I think we trigger PF_POISONED_CHECK() in PageSlab(), then fffe
> > is "accessed" from VM_BUG_ON_PAGE().
> >
> > It seems to m
On Tue, Jan 05, 2021 at 01:45:37PM -0500, Qian Cai wrote:
> On Tue, 2021-01-05 at 10:24 +0200, Mike Rapoport wrote:
> > Hi,
> >
> > On Mon, Jan 04, 2021 at 02:03:00PM -0500, Qian Cai wrote:
> > > On Wed, 2020-12-09 at 23:43 +0200, Mike Rapoport wrot
On Sun, Jan 03, 2021 at 03:09:14PM -0500, Andrea Arcangeli wrote:
> Hello Mike,
>
> On Sun, Jan 03, 2021 at 03:47:53PM +0200, Mike Rapoport wrote:
> > Thanks for the logs, it seems that implicitly adding reserved regions to
> > memblock.memory wasn't that bright idea :)
>
Hi,
On Mon, Jan 04, 2021 at 02:03:00PM -0500, Qian Cai wrote:
> On Wed, 2020-12-09 at 23:43 +0200, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > Interleave initialization of pages that correspond to holes with the
> > initialization of memory map, so tha
On Fri, Dec 18, 2020 at 09:59:26PM +, Guillaume Tucker wrote:
> On 13/12/2020 08:23, Mike Rapoport wrote:
> > Hi Guillaume,
> >
> > On Fri, Dec 11, 2020 at 09:53:46PM +, Guillaume Tucker wrote:
> >> Hi Mike,
> >>
>
> OK, sorry for the delay
On Wed, Dec 23, 2020 at 08:35:37AM -0800, Roman Gushchin wrote:
> On Tue, Dec 22, 2020 at 08:06:06PM -0800, Andrew Morton wrote:
> > On Mon, 21 Dec 2020 09:05:51 -0800 Roman Gushchin wrote:
> >
> > > Subject: [PATCH v3 1/2] mm: cma: allocate cma areas bottom-up
> >
> > i386 allmodconfig:
> >
>
off-by: Baoquan He
Reviewed-by: Mike Rapoport
> ---
> mm/page_alloc.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 7f0a917ab858..189a86253c93 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
On Sun, Dec 20, 2020 at 04:27:53PM +0800, Baoquan He wrote:
> Parameter 'zone' has got needed information, let's remove other
> unnecessary parameters.
>
> Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport
> ---
> mm/page_alloc.c | 17 +++--
> 1 file
On Sun, Dec 20, 2020 at 04:27:52PM +0800, Baoquan He wrote:
> As David suggested, simply passing 'struct zone *zone' is enough. We can
> get all needed information from 'struct zone*' easily.
>
> Suggested-by: David Hildenbrand
> Signed-off-by: Baoquan He
Reviewed-by
range_start_pfn' and local variable
> 'range_end_pfn' of memmap_init() to zone_start_pfn/zone_end_pfn.
>
> Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport
> ---
> arch/ia64/include/asm/pgtable.h | 2 +-
> arch/ia64/mm/init.c | 6 +++---
> include/l
k regions
> rather that check each PFN")
> Reported-by: Rahul Gopakumar
> Signed-off-by: Baoquan He
> Cc: sta...@vger.kernel.org
Reviewed-by: Mike Rapoport
> ---
> arch/ia64/mm/init.c | 4 ++--
> include/linux/mm.h | 5 +++--
> mm/memory_hotplug.c | 2 +-
.002988] ---[ end trace f151227d0b39be70 ]---
>
> At the same time, the kernel image is protected with memblock_reserve(),
> so we can just start searching at PAGE_SIZE. In this case the
> bottom-up allocation has the same chances to success as a top-down
> allocation, so there is no reason
a: reserve 2048 MiB, up to 2048 MiB per node
> [0.002933] cma: Reserved 2048 MiB at 0x0003c000
> [0.002934] hugetlb_cma: reserved 2048 MiB on node 0
>
> v2:
> - switched to memblock_set_bottom_up(true), by Mike
> - start with 4GB, by Mike
>
> Signed-off-by: Roman Gu
From: Mike Rapoport
The change of ia64's default memory model to SPARSEMEM causes defconfig
build to fail:
CC kernel/async.o
In file included from include/linux/numa.h:25,
from include/linux/async.h:13,
from kernel/async.c:47:
arch/ia64/include/asm
ea")
>
> Signed-off-by: Atish Patra
Acked-by: Mike Rapoport
> ---
> arch/riscv/mm/init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index 8e577f14f120..e4133c20744c 100644
> ---
Hi Roman,
On Tue, Dec 15, 2020 at 11:36:15AM -0800, Roman Gushchin wrote:
> Currently cma areas without a fixed base address are allocated
> close to the end of the node. This placement is sub-optimal because
> of how the compaction works: it effectively moves pages into
> the cma area. In
On Tue, Dec 15, 2020 at 01:43:41PM -0800, Roman Gushchin wrote:
> On Tue, Dec 15, 2020 at 11:36:23PM +0200, Mike Rapoport wrote:
> > Hi Roman,
> >
> > On Tue, Dec 15, 2020 at 11:36:15AM -0800, Roman Gushchin wrote:
> > > Currently cma areas without a fixed base add
Hi Roman,
On Tue, Dec 15, 2020 at 11:36:15AM -0800, Roman Gushchin wrote:
> Currently cma areas without a fixed base address are allocated
> close to the end of the node. This placement is sub-optimal because
> of how the compaction works: it effectively moves pages into
> the cma area. In
Hi Linus,
The following changes since commit 09162bc32c880a791c6c0668ce0745cf7958f576:
Linux 5.10-rc4 (2020-11-15 16:44:31 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock.git/
tags/memblock-v5.11-rc1
for you to fetch changes up
On Mon, Dec 14, 2020 at 11:11:35AM +0100, David Hildenbrand wrote:
> On 09.12.20 22:43, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > memblock does not require that the reserved memory ranges will be a subset
> > of memblock.memory.
> >
> > A
On Mon, Dec 14, 2020 at 11:00:07AM +0100, David Hildenbrand wrote:
> On 13.12.20 16:09, Baoquan He wrote:
> > The current memmap_init_zone() only handles memory region inside one zone.
> > Actually memmap_init() does the memmap init of one zone. So rename both of
> > them accordingly.
> >
> > And
On Sat, Dec 12, 2020 at 08:01:44AM -0800, Guenter Roeck wrote:
> On Tue, Oct 27, 2020 at 01:29:49PM +0200, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > SPARSEMEM memory model suitable for systems with large holes in their
> > phyiscal memory layout. Wit
On Sat, Dec 12, 2020 at 08:01:44AM -0800, Guenter Roeck wrote:
> On Tue, Oct 27, 2020 at 01:29:49PM +0200, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > SPARSEMEM memory model suitable for systems with large holes in their
> > phyiscal memory layout. Wit
Hi Guillaume,
On Fri, Dec 11, 2020 at 09:53:46PM +, Guillaume Tucker wrote:
> Hi Mike,
>
> Please see the bisection report below about a boot failure on
> rk3288 with next-20201210.
>
> Reports aren't automatically sent to the public while we're
> trialing new bisection features on
Hi John,
On Fri, Dec 11, 2020 at 10:16:23PM -0800, John Hubbard wrote:
> On 12/2/20 10:29 PM, Mike Rapoport wrote:
> > From: Mike Rapoport
> ...
> > +#include "../kselftest.h"
> > +
> > +#define fail(fmt, ...) ksft_test_result_fail(f
Hi John,
On Fri, Dec 11, 2020 at 10:16:23PM -0800, John Hubbard wrote:
> On 12/2/20 10:29 PM, Mike Rapoport wrote:
> > From: Mike Rapoport
> ...
> > +#include "../kselftest.h"
> > +
> > +#define fail(fmt, ...) ksft_test_result_fail(f
From: Mike Rapoport
There could be struct pages that are not backed by actual physical memory.
This can happen when the actual memory bank is not a multiple of
SECTION_SIZE or when an architecture does not register memory holes
reserved by the firmware as memblock.memory.
Such pages
From: Mike Rapoport
Hi,
Commit 73a6e474cb37 ("mm: memmap_init: iterate over
memblock regions rather that check each PFN") exposed several issues with
the memory map initialization and these patches fix those issues.
Initially there were crashes during compaction that Qian Cai rep
From: Mike Rapoport
memblock does not require that the reserved memory ranges will be a subset
of memblock.memory.
As the result there maybe reserved pages that are not in the range of any
zone or node because zone and node boundaries are detected based on
memblock.memory and pages that only
On Sun, Dec 06, 2020 at 08:31:39PM -0800, Nadav Amit wrote:
>
> Whenever I run into a non-standard and non-trivial synchronization algorithm
> in the kernel (and elsewhere), I become very confused and concerned. I
> raised my question since I wanted to modify the code and could not figure
> out
On Mon, Dec 07, 2020 at 09:45:59AM -0500, Qian Cai wrote:
> On Thu, 2020-12-03 at 08:29 +0200, Mike Rapoport wrote:
...
> > diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> > index 6d55324363ab..f9d93fbf9b69 100644
> > --- a/include/linux/syscalls.h
&g
On Mon, Dec 07, 2020 at 09:45:59AM -0500, Qian Cai wrote:
> On Thu, 2020-12-03 at 08:29 +0200, Mike Rapoport wrote:
...
> > diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> > index 6d55324363ab..f9d93fbf9b69 100644
> > --- a/include/linux/syscalls.h
&g
On Mon, Dec 07, 2020 at 10:49:26AM +0100, Ard Biesheuvel wrote:
> On Mon, 7 Dec 2020 at 10:42, Mike Rapoport wrote:
> >
> > On Mon, Dec 07, 2020 at 09:35:06AM +, Marc Zyngier wrote:
> > > On 2020-12-07 09:09, Ard Biesheuvel wrote:
> > > > (+ Marc)
> &g
On Mon, Dec 07, 2020 at 09:35:06AM +, Marc Zyngier wrote:
> On 2020-12-07 09:09, Ard Biesheuvel wrote:
> > (+ Marc)
> >
> > On Fri, 4 Dec 2020 at 12:14, Will Deacon wrote:
> > >
> > > On Fri, Dec 04, 2020 at 09:44:43AM +0800, Wei Li wrote:
> > > > For the memory hole, sparse memory model
On Thu, Dec 03, 2020 at 11:23:10PM +0800, carver4...@163.com wrote:
> From: Hailong Liu
>
> When system in the booting stage, pages span from [start, end] of a memblock
> are freed to buddy in a order as large as possible (less than MAX_ORDER) at
> first, then decrease gradually to a proper
On Thu, Dec 03, 2020 at 03:39:16PM -0800, Andrew Morton wrote:
> On Thu, 3 Dec 2020 08:29:48 +0200 Mike Rapoport wrote:
>
> > From: Mike Rapoport
> >
> > Wire up memfd_secret system call on architectures that define
> > ARCH_HAS_SET_DIRECT_MAP
On Thu, Dec 03, 2020 at 03:39:16PM -0800, Andrew Morton wrote:
> On Thu, 3 Dec 2020 08:29:48 +0200 Mike Rapoport wrote:
>
> > From: Mike Rapoport
> >
> > Wire up memfd_secret system call on architectures that define
> > ARCH_HAS_SET_DIRECT_MAP
On Thu, Dec 03, 2020 at 03:36:10PM -0800, Andrew Morton wrote:
> On Thu, 3 Dec 2020 08:29:43 +0200 Mike Rapoport wrote:
>
> > From: Mike Rapoport
> >
> > On arm64, set_direct_map_*() functions may return 0 without actually
> > changing the linear map. This beh
On Thu, Dec 03, 2020 at 03:36:10PM -0800, Andrew Morton wrote:
> On Thu, 3 Dec 2020 08:29:43 +0200 Mike Rapoport wrote:
>
> > From: Mike Rapoport
> >
> > On arm64, set_direct_map_*() functions may return 0 without actually
> > changing the linear map. This beh
Hello Nadav,
On Thu, Dec 03, 2020 at 11:57:46AM -0800, Nadav Amit wrote:
> Hello Mike,
>
> Regarding your (old) patch:
>
> > On May 23, 2018, at 12:42 AM, Mike Rapoport wrote:
> >
> > If a process monitored with userfaultfd changes it's memory mappings or
> &
On Thu, Dec 03, 2020 at 12:31:44PM -0500, Andrea Arcangeli wrote:
> On Thu, Dec 03, 2020 at 12:51:07PM +0200, Mike Rapoport wrote:
> > On Thu, Dec 03, 2020 at 01:23:02AM -0500, Andrea Arcangeli wrote:
> > > 5) pfn 0 is the classical case where pfn 0 is
On Fri, Dec 04, 2020 at 11:13:47AM +, Will Deacon wrote:
> On Fri, Dec 04, 2020 at 09:44:43AM +0800, Wei Li wrote:
> > For the memory hole, sparse memory model that define SPARSEMEM_VMEMMAP
> > do not free the reserved memory for the page map, decrease the section
> > size can reduce the waste
> page dumped because: VM_BUG_ON_PAGE(1 && PageCompound(page))
> [ cut here ]
> kernel BUG at include/linux/page-flags.h:356!
Yeah, the change to initialization of "unavailable" memory missed pfn 0 :(
This should fix it:
>From 84a1c2531374706f35
On Thu, Dec 03, 2020 at 01:23:02AM -0500, Andrea Arcangeli wrote:
> On Wed, Dec 02, 2020 at 07:39:23PM +0200, Mike Rapoport wrote:
> > Hmm, do you have any logs? It worked on my box and with various memory
> > configurations in qemu.
>
> It crashes in reserve_bootmem_reg
On Wed, Dec 02, 2020 at 08:49:06PM +0200, Topi Miettinen wrote:
> On 1.12.2020 23.45, Topi Miettinen wrote:
> > Memory mappings inside kernel allocated with vmalloc() are in
> > predictable order and packed tightly toward the low addresses. With
> > new kernel boot parameter 'randomize_vmalloc=1',
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
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/uapi/asm/unistd.h | 1 +
arch/riscv/include/asm
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
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
Account memory consumed by secretmem to memcg. The accounting is updated
when the memory is actually allocated and freed.
Signed-off-by: Mike Rapoport
Acked-by: Roman Gushchin
---
mm/filemap.c | 3 ++-
mm/secretmem.c | 36 +++-
2 files
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
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
Hi,
@Andrew, this is based on v5.10-rc2-mmotm-2020-11-07-21-40, I can rebase on
current mmotm if you prefer.
This is an implementation of "secret" mappings backed by a file descriptor.
The file descriptor backing secret memory mappings is created using a
From: Mike Rapoport
On arm64, set_direct_map_*() functions may return 0 without actually
changing the linear map. This behaviour can be controlled using kernel
parameters, so we need a way to determine at runtime whether calls to
set_direct_map_invalid_noflush
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
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/uapi/asm/unistd.h | 1 +
arch/riscv/include/asm
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
Account memory consumed by secretmem to memcg. The accounting is updated
when the memory is actually allocated and freed.
Signed-off-by: Mike Rapoport
Acked-by: Roman Gushchin
---
mm/filemap.c | 3 ++-
mm/secretmem.c | 36 +++-
2 files
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
On arm64, set_direct_map_*() functions may return 0 without actually
changing the linear map. This behaviour can be controlled using kernel
parameters, so we need a way to determine at runtime whether calls to
set_direct_map_invalid_noflush
1601 - 1700 of 6442 matches
Mail list logo
