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 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 :)
>
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 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
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
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
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
> ---
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 Tue, Oct 20, 2020 at 09:18:58AM +0300, Kirill A. Shutemov wrote:
> If the protected memory feature enabled, unmap guest memory from
> kernel's direct mappings.
>
> Migration and KSM is disabled for protected memory as it would require a
> special treatment.
>
> Signed-off-by: Kirill A.
On Fri, Oct 23, 2020 at 06:33:34PM +0200, Mauro Carvalho Chehab wrote:
> Some identifiers have different names between their prototypes
> and the kernel-doc markup.
>
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Mike Rapoport
> ---
> include/linux/memblock.h | 4 ++--
&g
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
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() and update its forward
declarations and stubs
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 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.
On arm64 it is possible that a page would be removed from the direct map
using set_direct_map_invalid_noflush
On Fri, Oct 02, 2020 at 02:09:17PM +0300, Topi Miettinen wrote:
> Writing a new value of 3 to /proc/sys/kernel/randomize_va_space
> enables full randomization of memory mappings created with mmap(NULL,
> ...). With 2, the base of the VMA used for such mappings is random,
> but the mappings are
On Thu, Oct 08, 2020 at 01:41:55PM +0200, Vlastimil Babka wrote:
> The updates to pcplists' high and batch valued are handled by multiple
Nit: ^ values
> functions that make the calculations hard to follow. Consolidate everything
> to
On Fri, Oct 16, 2020 at 05:14:00PM +0800, Zhenhua Huang wrote:
> Page owner of pages used by page owner itself used is missing on arm32
> targets.
> The reason is dummy_handle and failure_handle is not initialized correctly.
> Buddy allocator is used to initialize these two handles. However,
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
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
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
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
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 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/asm/unistd.h| 2 +-
arch/arm64/include/asm
On Mon, Oct 26, 2020 at 01:13:52AM +, Edgecombe, Rick P wrote:
> On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> > Indeed, for architectures that define CONFIG_ARCH_HAS_SET_DIRECT_MAP
> > it is
> > possible that __kernel_map_pages() would fail, but since this
>
On Mon, Oct 26, 2020 at 12:38:32AM +, Edgecombe, Rick P wrote:
> On Sun, 2020-10-25 at 12:15 +0200, 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 di
On Mon, Oct 26, 2020 at 12:54:01AM +, Edgecombe, Rick P wrote:
> On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> > index 7f248fc45317..16f878c26667 100644
> > --- a/arch/x86/mm/pat/set_memory.c
> > +++ b/arch/x86/mm/pat/set_memory.c
> > @@ -2228,7 +2228,6
On Mon, Oct 26, 2020 at 03:12:55PM +0800, Zhenhua Huang wrote:
> Hi Mike,
>
> On Sun, Oct 25, 2020 at 11:42:53PM +0800, Mike Rapoport wrote:
> > On Fri, Oct 16, 2020 at 05:14:00PM +0800, Zhenhua Huang wrote:
> > > Page owner of pages used by page owner itself used is miss
ment.
I'd also mention that making page fault accounting actually use this
task struct is quite a project, so there is no point to keep tsk
argument.
> Signed-off-by: John Hubbard
> Cc: Oleg Nesterov
FWIW:
Reviewed-by: Mike Rapoport
> ---
>
> Hi,
>
> Just something tha
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
> >
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 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 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
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 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 ++
>
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
> >
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 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
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 Wed, Nov 18, 2020 at 11:55:33PM +, Song Bao Hua (Barry Song) wrote:
> > From: Ard Biesheuvel [mailto:a...@kernel.org]
> >
> > On Wed, 18 Nov 2020 at 21:27, Song Bao Hua (Barry Song)
> > wrote:
> > >
> > > Good question. Originally I wrote this patch to debug and verify the
> > vmemmap
> >
On Thu, Nov 19, 2020 at 01:51:18PM +0100, Alexander Graf wrote:
>
>
> On 19.11.20 13:02, Christian Borntraeger wrote:
> >
> > On 16.11.20 16:34, Catangiu, Adrian Costin wrote:
> > > - Background
> > >
> > > The VM Generation ID is a feature defined by Microsoft (paper:
> > >
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 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 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 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 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 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 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 Sat, Oct 17, 2020 at 11:36:39AM +0200, David Hildenbrand wrote:
> On 17.10.20 10:26, Mike Rapoport wrote:
> > On Fri, Oct 16, 2020 at 07:02:23PM -0700, Sudarshan Rajagopalan wrote:
> >> Certain architectures such as arm64 doesn't allow boot memory to be
> >> offlin
On Mon, Oct 26, 2020 at 12:05:13PM +0100, David Hildenbrand wrote:
> On 25.10.20 11:15, 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 than
On Mon, Oct 26, 2020 at 06:05:30PM +, Edgecombe, Rick P wrote:
> On Mon, 2020-10-26 at 11:05 +0200, Mike Rapoport wrote:
> > On Mon, Oct 26, 2020 at 01:13:52AM +, Edgecombe, Rick P wrote:
> > > On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> > >
On Mon, Oct 26, 2020 at 06:57:32PM +, Edgecombe, Rick P wrote:
> On Mon, 2020-10-26 at 11:15 +0200, Mike Rapoport wrote:
> > On Mon, Oct 26, 2020 at 12:38:32AM +, Edgecombe, Rick P wrote:
> > > On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> >
On Tue, Oct 27, 2020 at 09:46:35AM +0100, David Hildenbrand wrote:
> On 27.10.20 09:38, Mike Rapoport wrote:
> > On Mon, Oct 26, 2020 at 06:05:30PM +, Edgecombe, Rick P wrote:
> > > On Mon, 2020-10-26 at 11:05 +0200, Mike Rapoport wrote:
> > > > On Mon, Oc
On Tue, Oct 27, 2020 at 09:12:23AM +0100, David Hildenbrand wrote:
> On 26.10.20 20:01, Edgecombe, Rick P wrote:
> > On Mon, 2020-10-26 at 10:37 +0200, Mike Rapoport wrote:
> >> +++ b/arch/x86/mm/pat/set_memory.c
> >> @@ -2184,14 +2184,14 @@ static int __set_pages_np(
On Mon, Oct 26, 2020 at 04:02:51PM -0700, Atish Patra wrote:
> Currently, all memblocks are mapped with PAGE_KERNEL_EXEC and the strict
> permissions are only enforced after /init starts. This leaves the kernel
> vulnerable from possible buggy built-in modules.
>
> Apply permissions to individual
On Mon, Oct 26, 2020 at 04:02:50PM -0700, Atish Patra wrote:
> Currently, SBI is initialized towards the end of arch setup. This prevents
> the set memory operations to be invoked earlier as it requires a full tlb
> flush.
>
> Initialize SBI as early as possible.
>
> Signed-off-by: Atish Patra
On Mon, Oct 26, 2020 at 04:02:53PM -0700, Atish Patra wrote:
> Currently, .init.text & .init.data are intermixed which makes it impossible
> apply different permissions to them. .init.data shouldn't need exec
> permissions while .init.text shouldn't have write permission.
>
> Keep them in
From: Mike Rapoport
ARM is the only architecture that defines CONFIG_ARCH_HAS_HOLES_MEMORYMODEL
which in turn enables memmap_valid_within() function that is intended to
verify existence of struct page associated with a pfn when there are holes
in the memory map.
However
From: Mike Rapoport
DISCONTIGMEM was intended to provide more efficient support for systems
with holes in their physical address space that FLATMEM did.
Yet, it's overhead in terms of the memory consumption seems to overweight
the savings on the unused memory map.
For a ARAnyM system with 16
From: Mike Rapoport
The ia64 implementation of __early_pfn_to_nid() essentially relies on the
same data as the generic implementation.
The correspondence between memory ranges and nodes is set in memblock
during early memory initialization in register_active_ranges() function
From: Mike Rapoport
After the removal of SN2 platform (commit cf07cb1ff4ea ("ia64: remove
support for the SGI SN2 platform") IA-64 always has ZONE_DMA32 and there is
no point to guard code with this configuration option.
Remove ifdefery associated with CONFIG_ZONE_DMA32
Signed-of
From: Mike Rapoport
Currently ARC uses DISCONTIGMEM to cope with sparse physical memory address
space on systems with 2 memory banks. While DISCONTIGMEM avoids wasting
memory on unpopulated memory map, it adds both memory and CPU overhead
relatively to FLATMEM. Moreover, DISCONTINGMEM
From: Mike Rapoport
For both FLATMEM and DISCONTIGMEM/SPARSEMEM the virtual map initialization
is spread over paging_init() for no good reason.
Split out the bits related to virtual map initialization to a helper
functions, one for FLATMEM and another for !FLATMEM configurations.
Signed-off
From: Mike Rapoport
The pg_data_map and pg_data_table arrays as well as page_to_pfn() and
pfn_to_page() are required only for DISCONTIGMEM. Other memory models can
use the generic definitions in asm-generic/memory_model.h.
Signed-off-by: Mike Rapoport
---
arch/m68k/include/asm/page.h
From: Mike Rapoport
The maximal PFN in the system is calculated during find_memory() time and
it is stored at max_low_pfn then.
Use this value in paging_init() and remove the redundant detection of
max_pfn in that function.
Signed-off-by: Mike Rapoport
---
arch/ia64/mm/discontig.c | 5
From: Mike Rapoport
The pg_data_t node structures and their initialization currently depends on
!CONFIG_SINGLE_MEMORY_CHUNK. Since they are required only for DISCONTIGMEM
make this dependency explicit and replace usage of
CONFIG_SINGLE_MEMORY_CHUNK with CONFIG_DISCONTIGMEM where appropriate
From: Mike Rapoport
ARM and ARM64 free unused parts of the memory map just before the
initialization of the page allocator. To allow holes in the memory map both
architectures overload pfn_valid() and define HAVE_ARCH_PFN_VALID.
Allowing holes in the memory map for FLATMEM may be useful
From: Mike Rapoport
Hi,
It's been a while since DISCONTIGMEM is generally considered deprecated,
but it is still used by four architectures. This set replaces DISCONTIGMEM
with a different way to handle holes in the memory map and marks
DISCONTIGMEM configuration as BROKEN in Kconfigs
From: Mike Rapoport
SPARSEMEM memory model suitable for systems with large holes in their
phyiscal memory layout. With SPARSEMEM_VMEMMAP enabled it provides
pfn_to_page() and page_to_pfn() as fast as FLATMEM.
Make it the default memory model for IA-64 and disable DISCONTIGMEM which
From: Mike Rapoport
Enable SPARSEMEM support on alpha and deprecate DISCONTIGMEM.
The required changes are mostly around moving duplicated definitions of
page access and address conversion macros to a common place and making sure
they are available for all memory models.
The DISCONTINGMEM
From: Mike Rapoport
Virtual memory map was intended to avoid wasting memory on the memory map
on systems with large holes in the physical memory layout. Long ago it been
superseded first by DISCONTIGMEM and then by SPARSEMEM. Moreover,
SPARSEMEM_VMEMMAP provide the same functionality in much
On Thu, Oct 29, 2020 at 02:29:27PM -0700, Sudarshan Rajagopalan wrote:
> Hello all,
>
> We have a usecase where a module driver adds certain memory blocks using
> add_memory_driver_managed(), so that it can perform memory hotplug
> operations on these blocks. In general, these memory blocks
On Thu, Oct 29, 2020 at 12:21:41PM -0700, Atish Patra wrote:
> On Tue, Oct 27, 2020 at 3:46 AM Mike Rapoport wrote:
> >
> > On Mon, Oct 26, 2020 at 04:02:53PM -0700, Atish Patra wrote:
> > > Currently, .init.text & .init.data are intermixed which makes it
> >
id freeing
reserved pages.
Fixes: cddb5ddf2b76 ("arm, xtensa: simplify initialization of high memory
pages")
Link: https://lore.kernel.org/r/20201029110334.4118-1-a...@kernel.org/
Signed-off-by: Ard Biesheuvel
Co-developed-by: Mike Rapoport
Signed-off-by: Mike Rapoport
---
Max, Russell,
On Wed, Nov 18, 2020 at 02:41:45PM +1300, Barry Song wrote:
> early_param memmap is only implemented on X86, MIPS and XTENSA. To avoid
> wasting users’ time on trying this on platform like ARM, mark it clearly.
>
> Signed-off-by: Barry Song
Reviewed-by: Mike Rapoport
> ---
>
On Fri, Nov 20, 2020 at 10:15:30AM +0100, David Hildenbrand wrote:
> On 20.11.20 09:25, Michal Hocko wrote:
> > On Fri 20-11-20 14:43:25, Muchun Song wrote:
> > > We only can free the unused vmemmap to the buddy system when the
> > > size of struct page is a power of two.
> >
> > Can we actually
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
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
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
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 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
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
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
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
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
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
---
mm/filemap.c | 3 ++-
mm/secretmem.c | 36 +++-
2 files changed, 37 insertions
On Tue, Nov 17, 2020 at 12:02:01PM -0800, Shakeel Butt wrote:
> On Tue, Nov 17, 2020 at 11:49 AM Roman Gushchin wrote:
> >
> > On Tue, Nov 17, 2020 at 06:29:29PM +0200, Mike Rapoport wrote:
> > > From: Mike Rapoport
> > >
> > > Account memory cons
On Tue, Nov 17, 2020 at 05:15:30PM +, Catalin Marinas wrote:
> On Tue, Nov 17, 2020 at 06:29:31PM +0200, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > Wire up memfd_secret system call on architectures that define
> > ARCH_HAS_SET_DIRECT_MAP, n
Hi Barry,
On Wed, Nov 18, 2020 at 07:33:14PM +1300, Barry Song wrote:
> memmap should be an useful kernel parameter which has been supported by
> x86, mips and xtensa.
Why is this parameter should be useful for ARM64?
My understanding is that it is required only to work around really
broken
(added one of the AnC paper authors)
On Tue, Nov 17, 2020 at 10:21:30PM +0200, Topi Miettinen wrote:
> On 17.11.2020 18.54, Matthew Wilcox wrote:
> > On Mon, Oct 26, 2020 at 06:05:18PM +0200, Topi Miettinen wrote:
> > > Writing a new value of 3 to /proc/sys/kernel/randomize_va_space
> > > enables
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
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
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
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
901 - 1000 of 2824 matches
Mail list logo
