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
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-rc5-mmotm-2021-01-27-23-30, with secretmem
and related 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 back
On Sat, Feb 06, 2021 at 12:59:40PM +, Ivan Khoronzhuk wrote:
> In order to avoid crash kernel corruption, its memory is reserved
> early in memblock and as result, in time when resources are inited
> it's not present in memblock.memory, so crash kernel memory is out
> of ranges listed with for_
Hi,
Any comments on this?
On Thu, Jan 28, 2021 at 12:57:09PM +0200, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Hi,
>
> David noticed that we do some of memblock_reserve() calls after allocations
> are possible:
>
> https://lore.kernel.org/lkml/6ba6bde3-
d
devmem_is_allowed() considers it disallowed area.
So here's the revert of bde9cfa3afe4 as well.
>From a7fdc4117010d393dd77b99da5b573a5c98453ce Mon Sep 17 00:00:00 2001
From: Mike Rapoport
Date: Thu, 4 Feb 2021 20:12:37 +0200
Subject: [PATCH] Revert "x86/setup:
gt; leads to crashes.
>
> This changes back to only low memory being allocatable in the early
> stages, now using memblock allocation.
>
> Signed-off-by: Andreas Larsson
Acked-by: Mike Rapoport
> ---
> arch/sparc/mm/init_32.c | 3 +++
> 1 file changed, 3 insertions(+)
>
On Wed, Feb 03, 2021 at 01:15:58PM +0100, Michal Hocko wrote:
> On Thu 21-01-21 14:27:18, Mike Rapoport wrote:
> > +static struct file *secretmem_file_create(unsigned long flags)
> > +{
> > + struct file *file = ERR_PTR(-ENOMEM);
> > + struct secretmem_ctx *ctx;
On Wed, Feb 03, 2021 at 01:09:30PM +0100, Michal Hocko wrote:
> On Tue 02-02-21 10:55:40, James Bottomley wrote:
> > On Tue, 2021-02-02 at 20:15 +0200, Mike Rapoport wrote:
> > > On Tue, Feb 02, 2021 at 03:34:29PM +0100, David Hildenbrand wrote:
> > > > On 02.0
On Wed, Feb 03, 2021 at 10:12:22AM +0100, Michal Hocko wrote:
> On Tue 02-02-21 21:10:40, Mike Rapoport wrote:
> >
> > Let me reiterate to make sure I don't misread your suggestion.
> >
> > If we make secretmem an opt-in feature with, e.g. kernel parameter, t
On Tue, Feb 02, 2021 at 02:27:14PM +0100, Michal Hocko wrote:
> On Tue 02-02-21 14:48:57, Mike Rapoport wrote:
> > On Tue, Feb 02, 2021 at 10:35:05AM +0100, Michal Hocko wrote:
> > > On Mon 01-02-21 08:56:19, James Bottomley wrote:
> > >
> > > I have also
On Tue, Feb 02, 2021 at 03:34:29PM +0100, David Hildenbrand wrote:
> On 02.02.21 15:32, Michal Hocko wrote:
> > On Tue 02-02-21 15:26:20, David Hildenbrand wrote:
> > > On 02.02.21 15:22, Michal Hocko wrote:
> > > > On Tue 02-02-21 15:12:21, David Hildenbrand wrote:
> > > > [...]
> > > > > I think
On Tue, Feb 02, 2021 at 10:35:05AM +0100, Michal Hocko wrote:
> On Mon 01-02-21 08:56:19, James Bottomley wrote:
>
> I have also proposed potential ways out of this. Either the pool is not
> fixed sized and you make it a regular unevictable memory (if direct map
> fragmentation is not considered a
On Mon, Feb 01, 2021 at 03:32:33PM +0100, David Hildenbrand wrote:
> On 01.02.21 15:30, Mike Rapoport wrote:
> > >
> > > I'd suggest going through all zone ranges in free_area_init() first,
> > > dealing
> > > with zones that have "not section
On Mon, Feb 01, 2021 at 07:26:05PM +0800, Baoquan He wrote:
> On 02/01/21 at 10:32am, David Hildenbrand wrote:
> >
> > 2) In init_zone_unavailable_mem(), similar to round_up(max_pfn,
> > PAGES_PER_SECTION) handling, consider range
> > [round_down(min_pfn, PAGES_PER_SECTION), min_pfn - 1]
> > w
On Mon, Feb 01, 2021 at 10:32:44AM +0100, David Hildenbrand wrote:
> On 30.01.21 23:10, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The physical memory on an x86 system starts at address 0, but this is not
> > always reflected in e820 map. For example, the
On Mon, Feb 01, 2021 at 05:39:58PM +0800, Baoquan He wrote:
> On 02/01/21 at 10:14am, David Hildenbrand wrote:
> > On 11.01.21 20:40, Mike Rapoport wrote:
> > > +
> > > +static void __init init_unavailable_mem(void)
> > > +{
> > > + int zone;
>
On Sun, Jan 31, 2021 at 01:49:27PM -0800, Linus Torvalds wrote:
> On Sun, Jan 31, 2021 at 12:04 AM Mike Rapoport wrote:
> >
> > >
> > > That's *particularly* true when the very line above it did a
> > > "memblock_reserve()" of the exact same rang
00
>
> The issue was bisected to:
>
> commit cc9327f3b085ba5be5639a5ec3ce5b08a0f14a7c
> Author: Mike Rapoport
> Date: Thu Jan 28 07:42:40 2021 +
>
> mm: introduce memfd_secret system call to create "secret" memory areas
>
> bisection log:
On Sat, Jan 30, 2021 at 04:37:54PM -0800, Linus Torvalds wrote:
> On Sat, Jan 30, 2021 at 2:10 PM Mike Rapoport wrote:
> >
> > In either case, e820__memblock_setup() won't add the range 0x - 0x1000
> > to memblock.memory and later during memory map initializat
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 are
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 report
From: Mike Rapoport
The physical memory on an x86 system starts at address 0, but this is not
always reflected in e820 map. For example, the BIOS can have e820 entries
like
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x1000-0x0009
On Thu, Jan 28, 2021 at 02:01:06PM +0100, Michal Hocko wrote:
> On Thu 28-01-21 11:22:59, Mike Rapoport wrote:
>
> > And hugetlb pools may be also depleted by anybody by calling
> > mmap(MAP_HUGETLB) and there is no any limiting knob for this, while
> > secretmem has RLI
On Thu, Jan 28, 2021 at 07:28:57AM -0800, James Bottomley wrote:
> On Thu, 2021-01-28 at 14:01 +0100, Michal Hocko wrote:
> > On Thu 28-01-21 11:22:59, Mike Rapoport wrote:
> [...]
> > > One of the major pushbacks on the first RFC [1] of the concept was
> > > about t
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
Reviewed-by: David Hildenbrand
Acked-by: Borislav Petkov
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 and
On Wed, Jan 27, 2021 at 04:03:00PM +0100, Andreas Larsson wrote:
>
>
> Commit cca079ef8ac29a7c02192d2bad2ffe4c0c5ffdd0 makes sparc32 use
> memblocks instead of the previous bootmem solution. Unfortunately, due
> to this:
>
> #define PAGE_OFFSET 0xf000
> #define __va(x)((void *)(
On Thu, Jan 28, 2021 at 10:45:49AM +0800, Baoquan He wrote:
> On 01/27/21 at 08:26pm, Mike Rapoport wrote:
> > Hi Lukasz,
> >
> > On Wed, Jan 27, 2021 at 02:15:53PM +0100, Łukasz Majczak wrote:
> > > Hi Mike,
> > >
> > > I have started bisect
On Tue, Jan 26, 2021 at 01:08:23PM +0100, Michal Hocko wrote:
> On Tue 26-01-21 12:56:48, David Hildenbrand wrote:
> > On 26.01.21 12:46, Michal Hocko wrote:
> > > On Thu 21-01-21 14:27:19, Mike Rapoport wrote:
> > > > From: Mike Rapoport
> > > >
> &g
; > console=ttyS0,115200n8 debug earlyprintk=serial loglevel=7
> >
> > I was thinking about using earlycon, but it seems to be blocked.
> > (I think the lack of earlycon might be related to Chromebook HW
> > security design. There is an EC controller which is a pa
re any messages?
> Best regards
> Lukasz
>
> śr., 27 sty 2021 o 11:05 Mike Rapoport napisał(a):
> >
> > Hi Lukasz,
> >
> > On Wed, Jan 27, 2021 at 10:22:29AM +0100, Łukasz Majczak wrote:
> > > Crash after mm: fix initialization of struct page for hole
Hi Lukasz,
On Wed, Jan 27, 2021 at 10:22:29AM +0100, Łukasz Majczak wrote:
> Crash after mm: fix initialization of struct page for holes in memory layout
>
> Hi,
> I was trying to run v5.11-rc5 on my Samsung Chromebook Pro (Caroline),
> but I've noticed it has crashed - unfortunately it seems to
ton
> Cc: Guo Ren
> Cc: Mike Rapoport
> Cc: Oscar Salvador
> Cc: Michal Hocko
> Cc: Wei Yang
> Signed-off-by: David Hildenbrand
> ---
>
> Not compile tested as documentation on how to get
> https://gitlab.com/c-sky/buildroot
> running, especially wit
On Mon, Jan 25, 2021 at 09:13:59PM +, Chris Wilson wrote:
> Quoting Mike Rapoport (2021-01-25 21:04:56)
> > On Mon, Jan 25, 2021 at 08:34:34PM +, Chris Wilson wrote:
> > > Quoting Linus Torvalds (2021-01-25 01:06:40)
> > > > Mike Rapoport (3):
> > > .
On Tue, Jan 26, 2021 at 08:31:42AM +0100, Michal Hocko wrote:
> On Mon 25-01-21 23:38:17, Mike Rapoport wrote:
> > On Mon, Jan 25, 2021 at 05:54:51PM +0100, Michal Hocko wrote:
> > > On Thu 21-01-21 14:27:20, Mike Rapoport wrote:
> > > > From: Mike Rapoport
&
On Tue, Jan 26, 2021 at 08:16:14AM +0100, Michal Hocko wrote:
> On Mon 25-01-21 23:36:18, Mike Rapoport wrote:
> > On Mon, Jan 25, 2021 at 06:01:22PM +0100, Michal Hocko wrote:
> > > On Thu 21-01-21 14:27:18, Mike Rapoport wrote:
> > > > From: Mike Rapopo
On Mon, Jan 25, 2021 at 09:46:19PM +, Chris Wilson wrote:
> Quoting Mike Rapoport (2021-01-25 21:33:48)
> > On Mon, Jan 25, 2021 at 12:49:39PM -0800, Linus Torvalds wrote:
> > > On Mon, Jan 25, 2021 at 12:35 PM Chris Wilson
> > > wrote:
> > > >
> &
On Tue, Jan 26, 2021 at 10:00:13AM +0100, Michal Hocko wrote:
> On Tue 26-01-21 10:33:11, Mike Rapoport wrote:
> > On Tue, Jan 26, 2021 at 08:16:14AM +0100, Michal Hocko wrote:
> > > On Mon 25-01-21 23:36:18, Mike Rapoport wrote:
> > > > On Mon, Jan 25, 2021 at 06:01:
On Mon, Jan 25, 2021 at 12:49:39PM -0800, Linus Torvalds wrote:
> On Mon, Jan 25, 2021 at 12:35 PM Chris Wilson
> wrote:
> >
> > Quoting Linus Torvalds (2021-01-25 01:06:40)
> > > Mike Rapoport (3):
> > ...
> > > mm: fix initialization of struct
On Mon, Jan 25, 2021 at 09:18:04AM -0800, Shakeel Butt wrote:
> On Mon, Jan 25, 2021 at 8:20 AM Matthew Wilcox wrote:
> >
> > On Thu, Jan 21, 2021 at 02:27:20PM +0200, Mike Rapoport wrote:
> > > From: Mike Rapoport
> > >
> > > Account memory consume
On Mon, Jan 25, 2021 at 05:54:51PM +0100, Michal Hocko wrote:
> On Thu 21-01-21 14:27:20, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > Account memory consumed by secretmem to memcg. The accounting is updated
> > when the memory is actually allocated and free
On Mon, Jan 25, 2021 at 06:01:22PM +0100, Michal Hocko wrote:
> On Thu 21-01-21 14:27:18, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > Introduce "memfd_secret" system call with the ability to create memory
> > areas visible only in the context of
On Mon, Jan 25, 2021 at 08:34:34PM +, Chris Wilson wrote:
> Quoting Linus Torvalds (2021-01-25 01:06:40)
> > Mike Rapoport (3):
> ...
> > mm: fix initialization of struct page for holes in memory layout
>
> We have half a dozen or so different machines in CI tha
On Mon, Jan 25, 2021 at 03:59:11PM +0100, Borislav Petkov wrote:
> On Fri, Jan 15, 2021 at 10:32:54AM +0200, Mike Rapoport wrote:
> > + trim_low_memory_range();
>
> Btw, you can get rid of that one too:
>
> /*
> * Here we put platform-specific memory range workarounds
On Mon, Jan 25, 2021 at 03:50:41PM +0100, Borislav Petkov wrote:
> On Fri, Jan 15, 2021 at 10:32:54AM +0200, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The early reservations of memory areas used by the firmware, bootloader,
> > kernel text and data
On Mon, Jan 25, 2021 at 11:52:32AM +0530, Anshuman Khandual wrote:
>
> On 12/22/20 12:42 PM, Anshuman Khandual wrote:
> > pfn_valid() asserts that there is a memblock entry for a given pfn without
> > MEMBLOCK_NOMAP flag being set. The problem with ZONE_DEVICE based memory is
> > that they do not
On Sat, Jan 23, 2021 at 06:09:11PM -0800, Andrew Morton wrote:
> On Fri, 22 Jan 2021 01:37:14 -0300 Thiago Jung Bauermann
> wrote:
>
> > Mike Rapoport writes:
> >
> > > > Signed-off-by: Roman Gushchin
> > >
> > > Reviewed-by: Mike Rapopor
On Fri, Jan 22, 2021 at 08:12:30PM -0800, Palmer Dabbelt wrote:
> On Wed, 20 Jan 2021 10:06:04 PST (-0800), r...@kernel.org wrote:
> > From: Mike Rapoport
> >
> > ARCH_HAS_SET_DIRECT_MAP and ARCH_HAS_SET_MEMORY configuration options have
> > no meaning when CONFIG_MMU
pe warning from kernel test robot
> mm: rename memmap_init() and memmap_init_zone()
> mm: simplify parater of function memmap_init_zone()
> mm: simplify parameter of setup_usemap()
> mm: remove unneeded local variable in free_area_init_core
For the series:
Reviewed-by: Mik
Hi Linus,
The following changes since commit 9791581c049c10929e97098374dd1716a81fefcc:
Merge tag 'for-5.11-rc4-tag' of
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux (2021-01-20 14:15:33
-0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/
onstraints, lets just reduce the section size to 128MB for 4K
> and 16K base page size configs, and to 512MB for 64K base page size config.
>
> Signed-off-by: Sudarshan Rajagopalan
> Suggested-by: Anshuman Khandual
> Suggested-by: David Hildenbrand
> Cc: Catalin Marinas
&
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 memory m
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
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() and
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-by
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
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
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
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
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
On Thu, Jan 21, 2021 at 04:17:27PM +0800, Baoquan He wrote:
> On 01/20/21 at 11:47pm, kernel test robot wrote:
> > Hi Baoquan,
> >
> > I love your patch! Perhaps something to improve:
> >
> > [auto build test WARNING on linux/master]
> > [also build test WARNING on linus/master v5.11-rc4 next-202
On Wed, Jan 20, 2021 at 08:35:04PM +, Matthew Wilcox wrote:
> On Wed, Jan 20, 2021 at 08:06:07PM +0200, Mike Rapoport wrote:
> > +static struct page *secretmem_alloc_page(gfp_t gfp)
> > +{
> > + /*
> > +* FIXME: use a cache of large pages to reduce the direct m
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
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
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
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
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-by
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() and
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 memory m
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
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 and
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 variable
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
> bu
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 fr
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 are
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.
If
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 report
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
> >>
> >> diff
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 :)
401 - 500 of 1150 matches
Mail list logo
