Merge pull request #759 from uchin0704/master

linux-datastructures-2.md: fix minor typo

Booting/linux-bootstrap-1.md

@@ -141,7 +141,7 @@ You will see:
 
 ![Simple bootloader which prints only `!`](images/simple_bootloader.png)
 
-In this example, we can see that the code will be executed in `16-bit` real mode. After starting, it calls the [0x10](http://www.ctyme.com/intr/rb-0106.htm) interrupt, which just prints the `!` symbol. It fills the remaining `510` bytes with zeros and finishes with the two magic bytes `0xaa` and `0x55`.
+In this example, we can see that the code will be executed in `16-bit` real mode. After starting, it calls the [0x10](http://www.ctyme.com/intr/rb-0106.htm) interrupt, which just prints the `!` symbol. The times directive will pad that number of bytes up to 510th byte with zeros and finishes with the two magic bytes `0xaa` and `0x55`.
 
 You can see a binary dump of this using the `objdump` utility:
 

DataStructures/linux-datastructures-2.md

@@ -61,7 +61,7 @@ This structure presents the root of a radix tree and contains three fields:
 
 The first field we will discuss is `gfp_mask`:
 
-Low-level kernel memory allocation functions take a set of flags as - `gfp_mask`, which describes how that allocation is to be performed. These `GFP_` flags which control the allocation process can have following values: (`GF_NOIO` flag) means sleep and wait for memory, (`__GFP_HIGHMEM` flag) means high memory can be used, (`GFP_ATOMIC` flag) means the allocation process has high-priority and can't sleep etc.
+Low-level kernel memory allocation functions take a set of flags as - `gfp_mask`, which describes how that allocation is to be performed. These `GFP_` flags which control the allocation process can have following values: (`GFP_NOIO` flag) means sleep and wait for memory, (`__GFP_HIGHMEM` flag) means high memory can be used, (`GFP_ATOMIC` flag) means the allocation process has high-priority and can't sleep etc.
 
 * `GFP_NOIO` - can sleep and wait for memory;
 * `__GFP_HIGHMEM` - high memory can be used;

Initialization/linux-initialization-2.md

@@ -442,9 +442,17 @@ And the `_AC` macro is defined in the [include/uapi/linux/const.h](https://elixi
 #define _AC(X,Y)	__AC(X,Y)
 #endif
 ```
-So, where `__PAGE_OFFSET` expands to `0xffff880000000000`.
+Where `__PAGE_OFFSET` expands to `0xffff888000000000`. But, why is it possible to translate a virtual address to a physical address by subtracting `__PAGE_OFFSET`?  The answer is in the [Documentation/x86/x86_64/mm.rst](https://elixir.bootlin.com/linux/v5.10-rc5/source/Documentation/x86/x86_64/mm.rst#L45) documentation: 
 
-We initialize `pmd` and pass it to the `__early_make_pgtable` function along with `address`. The `__early_make_pgtable` function is defined in the same file as the `early_make_pgtable` function as the following:
+```
+...
+ffff888000000000 | -119.5  TB | ffffc87fffffffff |   64 TB | direct mapping of all physical memory (page_offset_base)
+...
+```
+
+As explained above, the virtual address space `ffff888000000000-ffffc87fffffffff` is direct mapping of all physical memory. When the kernel wants to access all physical memory, it uses direct mapping.
+
+Okay, let's get back to discussing `early_make_pgtable`. We initialize `pmd` and pass it to the `__early_make_pgtable` function along with `address`. The `__early_make_pgtable` function is defined in the same file as the `early_make_pgtable` function as follows:
 
 ```C
 int __init __early_make_pgtable(unsigned long address, pmdval_t pmd)