lkml.org 
[lkml]   [2019]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 4/4] x86/mm/KASLR: Adjust the padding size for the direct mapping.
On Fri, Nov 15, 2019 at 09:49:17AM -0500, Masayoshi Mizuma wrote:
> +/*
> + * Even though a huge virtual address space is reserved for the direct
> + * mapping of physical memory, e.g in 4-level paging mode, it's 64TB,
> + * rare system can own enough physical memory to use it up, most are
> + * even less than 1TB.

This sentence is unparseable.

> So with KASLR enabled, we adapt the size of

Who's "we"?

> + * direct mapping area to the size of actual physical memory plus the
> + * configured padding CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING.
> + * The left part will be taken out to join memory randomization.
> + */
> +static inline unsigned long calc_direct_mapping_size(void)

What direct mapping?!

The code is computing the physical memory regions base address and
sizes.

> +{
> + unsigned long size_tb, memory_tb;
> +
> + memory_tb = DIV_ROUND_UP(max_pfn << PAGE_SHIFT, 1UL << TB_SHIFT) +
> + CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
> +
> +#ifdef CONFIG_MEMORY_HOTPLUG
> + if (boot_params.max_addr) {
> + unsigned long maximum_tb;
> +
> + maximum_tb = DIV_ROUND_UP(boot_params.max_addr,
> + 1UL << TB_SHIFT);

All that jumping through hoops and adding a member to boot_params which
is useless on !hot-add systems - basically the majority out there - just
so that you can use that max address here?!

Did you not find acpi_table_parse_srat()?

--
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

\
 
 \ /
  Last update: 2019-12-12 21:19    [W:0.107 / U:3.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site