[PATCH] x86/mm/KASLR: Add code comments to explain fields of struct kaslr_memory_region

[Baoquan He]

Signed-off-by: Baoquan He <bhe@xxxxxxxxxx>
Suggested-by: Ingo Molnar <mingo@xxxxxxxxxx>

---
 arch/x86/mm/kaslr.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 91053cee7648..402984d8d729 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -41,9 +41,21 @@
 static const unsigned long vaddr_end = CPU_ENTRY_AREA_BASE;
 
 /*
- * Memory regions randomized by KASLR (except modules that use a separate logic
- * earlier during boot). The list is ordered based on virtual addresses. This
- * order is kept after randomization.
+ * Memory regions randomized by KASLR (except modules that use a separate
+ * logic earlier during boot). Currently they are the physical memory
+ * mapping, vmalloc and vmemmap regions, are ordered based on virtual
+ * addresses. The order is kept after randomization.
+ *
+ * @base: points to various global variables used by the MM to get the
+ * virtual base address of the above regions, which base addresses can
+ * thus be modified by the very early KASLR code to dynamically shape
+ * the virtual memory layout of these kernel memory regions on a per
+ * bootup basis.
+ *
+ * @size_tb: size in TB of each memory region. Thereinto, the size of
+ * the physical memory mapping region is variable, calculated according
+ * to the actual size of system RAM in order to save more space for
+ * randomization. The rest are fixed values related to paging mode.
  */
 static __initdata struct kaslr_memory_region {
 	unsigned long *base;

> /* Get size in bytes used by the memory region */
> static inline unsigned long get_padding(struct kaslr_memory_region *region)
> {
>         return (region->size_tb << TB_SHIFT);
> }

Yes, we can open code get_padding() as the following patch.