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.12-rc1, 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 mappings is created using a
dedicated memfd_secret system call T
On Tue, Mar 02, 2021 at 09:04:09PM +0800, Baoquan He wrote:
> On 03/02/21 at 12:04pm, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The early reservations of memory areas used by the firmware, bootloader,
> > kernel text and data are spread over setup_arc
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
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
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
The below patches consolidate early memory reservations done during
setup_arch() so that memory used
Hi George,
On Mon, Mar 01, 2021 at 08:20:45PM -0500, George Kennedy wrote:
> > > > >
> > > > There should be no harm in doing the memblock_reserve() for all
> > > > the standard
> > > > tables, right?
> > > It should be ok to memblock_reserve() all the tables very early as
> > > long as
> > > we
("memblock: do not start bottom-up allocations
> with kernel_end")
> Debugged-by: Serge Semin
> Reported-by: Kamal Dasu
> Signed-off-by: Florian Fainelli
Acked-by: Mike Rapoport
> ---
> Thomas,
>
> This is intended as a stop-gap solution for 5.12-rc1 and t
Thanks a lot for all of your work! Loving using qtile and following it's
growth.
Em sábado, 13 de fevereiro de 2021 às 11:55:57 UTC-3, Tycho Andersen
escreveu:
> Hi all,
>
> I've just tagged 0.17.0.
>
> There's been a _lot_ more activity in the last year than in past
> years, so thanks for
an Fainelli wrote:
> >> Hi Mike,
> >>
> >> On 2/28/2021 1:00 AM, Mike Rapoport wrote:
> >>> Hi Florian,
> >>>
> >>> On Sat, Feb 27, 2021 at 08:18:47PM -0800, Florian Fainelli wrote:
> >>>>
> >
> >>>> [.
On Fri, Feb 26, 2021 at 11:16:06AM -0500, George Kennedy wrote:
> On 2/26/2021 6:17 AM, Mike Rapoport wrote:
> > Hi George,
> >
> > On Thu, Feb 25, 2021 at 08:19:18PM -0500, George Kennedy wrote:
> > >
> > > Not sure if it's the right thing to do, but
Hi Florian,
On Sat, Feb 27, 2021 at 08:18:47PM -0800, Florian Fainelli wrote:
>
> On 12/17/2020 12:12 PM, Roman Gushchin wrote:
> > With kaslr the kernel image is placed at a random place, so starting
> > the bottom-up allocation with the kernel_end can result in an
> > allocation failure and a
Hi George,
On Thu, Feb 25, 2021 at 08:19:18PM -0500, George Kennedy wrote:
>
> Mike,
>
> To get rid of the 0xBE453000 hardcoding, I added the following patch
> to your above patch to get the iBFT table "address" to use with
> memblock_reserve():
>
> diff --git
On Thu, Feb 25, 2021 at 07:38:44PM +0100, Vlastimil Babka wrote:
> On 2/25/21 7:05 PM, Mike Rapoport wrote:
> >>
> >> What if two zones are adjacent? I.e. if the hole was at a boundary between
> >> two
> >> zones.
> >
> > What do you mean by
On Thu, Feb 25, 2021 at 04:08:51PM -0800, Andrew Morton wrote:
> On Fri, 26 Feb 2021 00:43:51 +0200 Mike Rapoport wrote:
>
> > From: Mike Rapoport
>
> > void __meminit __weak memmap_init_zone(struct zone *zone)
> > {
> > unsigned long zone
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,
@Andrew, this is based on v5.11-mmotm-2021-02-18-18-29 with the previous
version reverted
Commit 73a6e474cb37 ("mm: memmap_init: iterate over memblock regions rather
that check each PFN") exposed several issues with the memory map
initialization and these p
lock_set_bottom_up()")
> Signed-off-by: Arnd Bergmann
I thought it'll go via memblock tree but since Andrew has already took it
Reviewed-by: Mike Rapoport
> ---
> include/linux/memblock.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/l
On Thu, Feb 25, 2021 at 09:54:34AM -0800, Linus Torvalds wrote:
> On Thu, Feb 25, 2021 at 9:07 AM Mike Rapoport wrote:
> >
> > >
> > > We might still double-initialize PFNs when two zones overlap within a
> > > section, correct?
> >
> > You mean th
On Thu, Feb 25, 2021 at 06:51:53PM +0100, Vlastimil Babka wrote:
> On 2/24/21 4:39 PM, Mike Rapoport wrote:
> > From: Mike Rapoport
>
> Hi, thanks for your efforts. I'll just nit pick on the description/comments
> as I
> don't feel confident about judging the implementati
On Thu, Feb 25, 2021 at 11:31:04AM -0500, George Kennedy wrote:
>
>
> On 2/25/2021 11:07 AM, Mike Rapoport wrote:
> > On Thu, Feb 25, 2021 at 10:22:44AM -0500, George Kennedy wrote:
> > > > > > > On 2/24/2021 5:37 AM, Mike Rapoport wrote:
> > > App
On Thu, Feb 25, 2021 at 06:23:24PM +0100, David Hildenbrand wrote:
> On 25.02.21 17:31, George Kennedy wrote:
> > : rsdp_address=bfbfa014
> > [ 0.066612] ACPI: RSDP 0xBFBFA014 24 (v02 BOCHS )
> > [ 0.067759] ACPI: XSDT 0xBFBF90E8 4C (v01 BOCHS BXPCFACP
> > 0001
On Thu, Feb 25, 2021 at 04:59:06PM +0100, David Hildenbrand wrote:
> On 24.02.21 16:39, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > There could be struct pages that are not backed by actual physical memory.
> > This can happen when the actual me
On Thu, Feb 25, 2021 at 10:22:44AM -0500, George Kennedy wrote:
>
> > > > > On 2/24/2021 5:37 AM, Mike Rapoport wrote:
>
> Applied just your latest patch, but same failure.
>
> I thought there was an earlier comment (which I can't find now) that stated
> that me
On Thu, Feb 25, 2021 at 03:06:27PM +0100, Arnd Bergmann wrote:
> On Thu, Feb 25, 2021 at 2:47 PM David Hildenbrand wrote:
> >
> > On 25.02.21 14:38, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > The inlining logic in clang-13 is rewritten to often not inline
> > > some functions
On Thu, Feb 25, 2021 at 07:38:19AM -0500, George Kennedy wrote:
> On 2/25/2021 3:53 AM, Mike Rapoport wrote:
> > Hi George,
> >
> > > On 2/24/2021 5:37 AM, Mike Rapoport wrote:
> > > > On Tue, Feb 23, 2021 at 04:46:28PM -0500, George Kennedy wrote:
> &
Hi George,
> On 2/24/2021 5:37 AM, Mike Rapoport wrote:
> > On Tue, Feb 23, 2021 at 04:46:28PM -0500, George Kennedy wrote:
> > > Mike,
> > >
> > > Still no luck.
> > >
> > > [ 30.193723] iscsi: registered transport (iser)
> > >
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,
@Andrew, this is based on v5.11-mmotm-2021-02-18-18-29 with the previous
version reverted
Commit 73a6e474cb37 ("mm: memmap_init: iterate over memblock regions rather
that check each PFN") exposed several issues with the memory map
initialization and these p
On Tue, Feb 23, 2021 at 04:46:28PM -0500, George Kennedy wrote:
>
> Mike,
>
> Still no luck.
>
> [ 30.193723] iscsi: registered transport (iser)
> [ 30.195970] iBFT detected.
> [ 30.196571] BUG: unable to handle page fault for address: ff240004
Hmm, we cannot set ibft_addr to
On Tue, Feb 23, 2021 at 04:16:44PM -0500, George Kennedy wrote:
>
>
> On 2/23/2021 3:09 PM, Mike Rapoport wrote:
> > On Tue, Feb 23, 2021 at 01:05:05PM -0500, George Kennedy wrote:
> > > On 2/23/2021 10:47 AM, Mike Rapoport wrote:
> > >
> > > It no
On Tue, Feb 23, 2021 at 01:05:05PM -0500, George Kennedy wrote:
> On 2/23/2021 10:47 AM, Mike Rapoport wrote:
>
> It now crashes here:
>
> [ 0.051019] ACPI: Early table checksum verification disabled
> [ 0.056721] ACPI: RSDP 0xBFBFA014 24 (v02 BOCHS )
>
Hi George,
On Tue, Feb 23, 2021 at 09:35:32AM -0500, George Kennedy wrote:
>
> On 2/23/2021 5:33 AM, Mike Rapoport wrote:
> > (re-added CC)
> >
> > On Mon, Feb 22, 2021 at 08:24:59PM -0500, George Kennedy wrote:
> > > On 2/22/2021 4:55 PM, Mike Rapoport wrote:
&
(re-added CC)
On Mon, Feb 22, 2021 at 08:24:59PM -0500, George Kennedy wrote:
>
> On 2/22/2021 4:55 PM, Mike Rapoport wrote:
> > On Mon, Feb 22, 2021 at 01:42:56PM -0500, George Kennedy wrote:
> > > On 2/22/2021 11:13 AM, David Hildenbrand wrote:
> > > > On 22.
On Tue, Feb 23, 2021 at 10:49:44AM +0100, David Hildenbrand wrote:
> On 23.02.21 10:48, Mike Rapoport wrote:
> > On Tue, Feb 23, 2021 at 09:04:19AM +0100, David Hildenbrand wrote:
> > > On 22.02.21 11:57, Mike Rapoport wrote:
> > > > From: Mike Rapoport
> >
On Tue, Feb 23, 2021 at 09:04:19AM +0100, David Hildenbrand wrote:
> On 22.02.21 11:57, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > There could be struct pages that are not backed by actual physical memory.
> > This can happen when the actual me
On Mon, Feb 22, 2021 at 01:42:56PM -0500, George Kennedy wrote:
>
> On 2/22/2021 11:13 AM, David Hildenbrand wrote:
> > On 22.02.21 16:13, George Kennedy wrote:
> > >
> > > On 2/22/2021 4:52 AM, David Hildenbrand wrote:
> > > >
> > > > Let me look into the code ... I have little experience with
On Mon, Feb 22, 2021 at 12:40:36PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 22, 2021 at 05:39:29PM +0100, David Hildenbrand wrote:
> > On 22.02.21 17:13, David Hildenbrand wrote:
> > > On 22.02.21 16:13, George Kennedy wrote:
> > > >
> > > >
> > > > On 2/22/2021 4:52 AM, David
Somehow I've managed to break the threading, the cover letter is here:
https://lore.kernel.org/lkml/20210222105400.28583-1-r...@kernel.org
On Mon, Feb 22, 2021 at 12:57:28PM +0200, Mike Rapoport wrote:
> From: Mike Rapoport
>
> There could be struct pages that are not backed by actual
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,
@Andrew, this is based on v5.11-mmotm-2021-02-18-18-29 with the previous
version reverted
Commit 73a6e474cb37 ("mm: memmap_init: iterate over memblock regions rather
that check each PFN") exposed several issues with the memory map
initialization and these p
On Mon, Feb 22, 2021 at 07:34:52AM +, Matthew Garrett wrote:
> On Mon, Feb 08, 2021 at 10:49:18AM +0200, Mike Rapoport wrote:
>
> > It is unsafe to allow saving of secretmem areas to the hibernation
> > snapshot as they would be visible after the resume and this essential
On Mon, Feb 22, 2021 at 07:34:52AM +, Matthew Garrett wrote:
> On Mon, Feb 08, 2021 at 10:49:18AM +0200, Mike Rapoport wrote:
>
> > It is unsafe to allow saving of secretmem areas to the hibernation
> > snapshot as they would be visible after the resume and this essential
Hi Vlastimil,
On Tue, Feb 16, 2021 at 05:39:12PM +0100, Vlastimil Babka wrote:
>
>
> So, Andrea could you please check if this fixes the original
> fast_isolate_around() issue for you? With the VM_BUG_ON not removed, DEBUG_VM
> enabled, no changes to struct page initialization...
> It relies on
On Mon, Feb 15, 2021 at 09:45:30AM +0100, David Hildenbrand wrote:
> On 14.02.21 18:29, Mike Rapoport wrote:
> > On Fri, Feb 12, 2021 at 10:56:19AM +0100, David Hildenbrand wrote:
> > > On 12.02.21 10:55, David Hildenbrand wrote:
> > > > On 08.02.21 12:08, Mike Rap
On Tue, Feb 16, 2021 at 09:33:20AM +0100, Michal Hocko wrote:
> On Mon 15-02-21 23:24:40, Mike Rapoport wrote:
> > On Mon, Feb 15, 2021 at 10:00:31AM +0100, Michal Hocko wrote:
> > > On Sun 14-02-21 20:00:16, Mike Rapoport wrote:
> > > > On Fri, Feb 12, 2021 at 02:18:
On Mon, Feb 15, 2021 at 10:00:31AM +0100, Michal Hocko wrote:
> On Sun 14-02-21 20:00:16, Mike Rapoport wrote:
> > On Fri, Feb 12, 2021 at 02:18:20PM +0100, Michal Hocko wrote:
>
> > We can correctly set the zone links for the reserved pages for holes in the
> >
On Fri, Feb 12, 2021 at 02:18:20PM +0100, Michal Hocko wrote:
> On Fri 12-02-21 11:42:15, David Hildenbrand wrote:
> > On 12.02.21 11:33, Michal Hocko wrote:
> [...]
> > > I have to digest this but my first impression is that this is more heavy
> > > weight than it needs to. Pfn walkers should
On Fri, Feb 12, 2021 at 10:56:19AM +0100, David Hildenbrand wrote:
> On 12.02.21 10:55, David Hildenbrand wrote:
> > On 08.02.21 12:08, Mike Rapoport wrote:
> > > +#ifdef CONFIG_SPARSEMEM
> > > + /*
> > > + * Sections in the memory map may not match actual
On Fri, Feb 12, 2021 at 10:18:19AM +0100, David Hildenbrand wrote:
> On 12.02.21 00:09, Mike Rapoport wrote:
> > On Thu, Feb 11, 2021 at 01:07:10PM +0100, David Hildenbrand wrote:
> > > On 11.02.21 12:27, Mike Rapoport wrote:
> > > > On Thu, Feb 11, 2021 at 10:01
On Fri, Feb 12, 2021 at 10:18:19AM +0100, David Hildenbrand wrote:
> On 12.02.21 00:09, Mike Rapoport wrote:
> > On Thu, Feb 11, 2021 at 01:07:10PM +0100, David Hildenbrand wrote:
> > > On 11.02.21 12:27, Mike Rapoport wrote:
> > > > On Thu, Feb 11, 2021 at 10:01
mmon/videobuf2/videobuf2-dma-contig.c:509:5: error:
> >> implicit declaration of function '__pfn_to_phys'
> >> [-Werror=implicit-function-declaration]
> 509 | __pfn_to_phys(nums[0]), size, buf->dma_dir, 0);
> | ^
>cc1: some warnings being
On Thu, Feb 11, 2021 at 01:07:10PM +0100, David Hildenbrand wrote:
> On 11.02.21 12:27, Mike Rapoport wrote:
> > On Thu, Feb 11, 2021 at 10:01:32AM +0100, David Hildenbrand wrote:
>
> So let's talk about the main user-visible differences to other memfd files
> (especially, ot
On Thu, Feb 11, 2021 at 01:07:10PM +0100, David Hildenbrand wrote:
> On 11.02.21 12:27, Mike Rapoport wrote:
> > On Thu, Feb 11, 2021 at 10:01:32AM +0100, David Hildenbrand wrote:
>
> So let's talk about the main user-visible differences to other memfd files
> (especially, ot
On Thu, Feb 11, 2021 at 01:30:42PM +0100, Michal Hocko wrote:
> On Thu 11-02-21 13:20:08, Mike Rapoport wrote:
> [...]
> > Sealing is anyway controlled via fcntl() and I don't think
> > MFD_ALLOW_SEALING makes much sense for the secretmem because it is there to
> > pr
On Thu, Feb 11, 2021 at 01:30:42PM +0100, Michal Hocko wrote:
> On Thu 11-02-21 13:20:08, Mike Rapoport wrote:
> [...]
> > Sealing is anyway controlled via fcntl() and I don't think
> > MFD_ALLOW_SEALING makes much sense for the secretmem because it is there to
> > pr
On Thu, Feb 11, 2021 at 11:02:07AM +0100, David Hildenbrand wrote:
>
> Another thought regarding "doesn't have _any_ backing storage"
>
> What are the right semantics when it comes to memory accounting/commit?
>
> As secretmem does not have
> a) any backing storage
> b) cannot go to swap
>
>
On Thu, Feb 11, 2021 at 10:01:32AM +0100, David Hildenbrand wrote:
> On 11.02.21 09:39, Michal Hocko wrote:
> > On Thu 11-02-21 09:13:19, Mike Rapoport wrote:
> > > On Tue, Feb 09, 2021 at 02:17:11PM +0100, Michal Hocko wrote:
> > > > On Tue 09-02-21
On Thu, Feb 11, 2021 at 09:39:38AM +0100, Michal Hocko wrote:
> On Thu 11-02-21 09:13:19, Mike Rapoport wrote:
> > On Tue, Feb 09, 2021 at 02:17:11PM +0100, Michal Hocko wrote:
> > > On Tue 09-02-21 11:09:38, Mike Rapoport wrote:
> [...]
> > > > Citing my older
On Thu, Feb 11, 2021 at 11:02:07AM +0100, David Hildenbrand wrote:
>
> Another thought regarding "doesn't have _any_ backing storage"
>
> What are the right semantics when it comes to memory accounting/commit?
>
> As secretmem does not have
> a) any backing storage
> b) cannot go to swap
>
>
On Thu, Feb 11, 2021 at 10:01:32AM +0100, David Hildenbrand wrote:
> On 11.02.21 09:39, Michal Hocko wrote:
> > On Thu 11-02-21 09:13:19, Mike Rapoport wrote:
> > > On Tue, Feb 09, 2021 at 02:17:11PM +0100, Michal Hocko wrote:
> > > > On Tue 09-02-21
On Thu, Feb 11, 2021 at 09:39:38AM +0100, Michal Hocko wrote:
> On Thu 11-02-21 09:13:19, Mike Rapoport wrote:
> > On Tue, Feb 09, 2021 at 02:17:11PM +0100, Michal Hocko wrote:
> > > On Tue 09-02-21 11:09:38, Mike Rapoport wrote:
> [...]
> > > > Citing my older
On Tue, Feb 09, 2021 at 02:17:11PM +0100, Michal Hocko wrote:
> On Tue 09-02-21 11:09:38, Mike Rapoport wrote:
> > On Tue, Feb 09, 2021 at 09:47:08AM +0100, Michal Hocko wrote:
> > >
> > > OK, so IIUC this means that the model is to hand over memory from host
> >
On Tue, Feb 09, 2021 at 02:17:11PM +0100, Michal Hocko wrote:
> On Tue 09-02-21 11:09:38, Mike Rapoport wrote:
> > On Tue, Feb 09, 2021 at 09:47:08AM +0100, Michal Hocko wrote:
> > >
> > > OK, so IIUC this means that the model is to hand over memory from host
> >
On Tue, Feb 09, 2021 at 05:17:30PM -0800, Linus Torvalds wrote:
> On Tue, Feb 9, 2021 at 1:43 AM Mike Rapoport wrote:
> >
> > This a small cleanup in memblock for 5.12 merge window.
>
> If it's going to make Andrew's patches easier to apply during the 5.12
> time
Hi Linus,
This a small cleanup in memblock for 5.12 merge window.
The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837:
Linux 5.11-rc3 (2021-01-10 14:34:50 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock
On Tue, Feb 09, 2021 at 09:47:08AM +0100, Michal Hocko wrote:
> On Mon 08-02-21 23:26:05, Mike Rapoport wrote:
> > On Mon, Feb 08, 2021 at 11:49:22AM +0100, Michal Hocko wrote:
> > > On Mon 08-02-21 10:49:17, Mike Rapoport wrote:
> [...]
> > > > The file de
On Tue, Feb 09, 2021 at 09:47:08AM +0100, Michal Hocko wrote:
> On Mon 08-02-21 23:26:05, Mike Rapoport wrote:
> > On Mon, Feb 08, 2021 at 11:49:22AM +0100, Michal Hocko wrote:
> > > On Mon 08-02-21 10:49:17, Mike Rapoport wrote:
> [...]
> > > > The file de
On Mon, Feb 08, 2021 at 11:18:37AM +0100, Michal Hocko wrote:
> On Mon 08-02-21 10:49:18, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > It is unsafe to allow saving of secretmem areas to the hibernation
> > snapshot as they would be visible after the
On Mon, Feb 08, 2021 at 11:49:22AM +0100, Michal Hocko wrote:
> On Mon 08-02-21 10:49:17, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > Introduce "memfd_secret" system call with the ability to create memory
> > areas visible only in the context
On Mon, Feb 08, 2021 at 01:11:00PM -0800, Andrew Morton wrote:
> On Mon, 8 Feb 2021 13:08:20 +0200 Mike Rapoport wrote:
>
> > 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
> &
On Mon, Feb 08, 2021 at 10:27:18AM +0100, David Hildenbrand wrote:
> On 08.02.21 09:49, Mike Rapoport wrote:
>
> Some questions (and request to document the answers) as we now allow to have
> unmovable allocations all over the place and I don't see a single comment
> regarding th
On Mon, Feb 08, 2021 at 11:18:37AM +0100, Michal Hocko wrote:
> On Mon 08-02-21 10:49:18, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > It is unsafe to allow saving of secretmem areas to the hibernation
> > snapshot as they would be visible after the
On Mon, Feb 08, 2021 at 11:49:22AM +0100, Michal Hocko wrote:
> On Mon 08-02-21 10:49:17, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > Introduce "memfd_secret" system call with the ability to create memory
> > areas visible only in the context
On Mon, Feb 08, 2021 at 10:27:18AM +0100, David Hildenbrand wrote:
> On 08.02.21 09:49, Mike Rapoport wrote:
>
> Some questions (and request to document the answers) as we now allow to have
> unmovable allocations all over the place and I don't see a single comment
> regarding th
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
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 secretmem feature is off by default and the
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
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
Acked-by: Catalin Marinas
Cc: Alexander Viro
Cc: Andy Lutomirski
Cc
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
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
FENCE for ARM64")
Signed-off-by: Arnd Bergmann
Acked-by: Catalin Marinas
Cc: Marco Elver
Cc: Alexander Potapenko
Cc: Andrey Konovalov
Cc: Dmitry Vyukov
Cc: Mike Rapoport
Signed-off-by: Andrew Morton
---
arch/arm64/include/asm/kfence.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
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
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
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
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
Acked-by: Catalin Marinas
Cc: Alexander Viro
Cc: Andy Lutomirski
Cc
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 secretmem feature is off by default and the
FENCE for ARM64")
Signed-off-by: Arnd Bergmann
Acked-by: Catalin Marinas
Cc: Marco Elver
Cc: Alexander Potapenko
Cc: Andrey Konovalov
Cc: Dmitry Vyukov
Cc: Mike Rapoport
Signed-off-by: Andrew Morton
---
arch/arm64/include/asm/kfence.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
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
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
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-
1401 - 1500 of 6441 matches
Mail list logo
