linux-next: manual merge of the kspp tree with the tip tree
Hi all,
Today's linux-next merge of the kspp tree got a conflict in:
Documentation/x86/x86_64/mm.txt
between commits:
5b1290406579 ("x86/mm/doc: Clean up the x86-64 virtual memory layout
descriptions")
32b89760ddf4 ("x86/mm/doc: Enhance the x86-64 virtual memory layout
descriptions")
from the tip tree and commit:
afaef01c0015 ("x86/entry: Add STACKLEAK erasing the kernel stack at the end
of syscalls")
from the kspp tree.
I fixed it up (see below - could probably be done better) and can carry
the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/x86/x86_64/mm.txt
index 702898633b00,600bc2afa27d..
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@@ -1,124 -1,57 +1,126 @@@
+
+Complete virtual memory map with 4-level page tables
+
-Virtual memory map with 4 level page tables:
-
- - 7fff (=47 bits) user space, different per mm
-hole caused by [47:63] sign extension
-8000 - 87ff (=43 bits) guard hole, reserved for
hypervisor
-8800 - c7ff (=64 TB) direct mapping of all phys.
memory
-c800 - c8ff (=40 bits) hole
-c900 - e8ff (=45 bits) vmalloc/ioremap space
-e900 - e9ff (=40 bits) hole
-ea00 - eaff (=40 bits) virtual memory map (1TB)
-... unused hole ...
-ec00 - fbff (=44 bits) kasan shadow memory (16TB)
-... unused hole ...
- vaddr_end for KASLR
-fe00 - fe7f (=39 bits) cpu_entry_area mapping
-fe80 - feff (=39 bits) LDT remap for PTI
-ff00 - ff7f (=39 bits) %esp fixup stacks
-... unused hole ...
-ffef - fffe (=64 GB) EFI region mapping space
-... unused hole ...
-8000 - 9fff (=512 MB) kernel text mapping, from phys 0
-a000 - feff (1520 MB) module mapping space
-[fixmap start] - ff5f kernel-internal fixmap range
-ff60 - ff600fff (=4 kB) legacy vsyscall ABI
-ffe0 - (=2 MB) unused hole
+Notes:
+
+ - Negative addresses such as "-23 TB" are absolute addresses in bytes,
counted down
+ from the top of the 64-bit address space. It's easier to understand the
layout
+ when seen both in absolute addresses and in distance-from-top notation.
+
+ For example 0xe900 == -23 TB, it's 23 TB lower than the top of
the
+ 64-bit address space ().
+
+ Note that as we get closer to the top of the address space, the notation
changes
+ from TB to GB and then MB/KB.
+
+ - "16M TB" might look weird at first sight, but it's an easier to visualize
size
+ notation than "16 EB", which few will recognize at first sight as 16
exabytes.
+ It also shows it nicely how incredibly large 64-bit address space is.
+
+
+Start addr| Offset | End addr | Size | VM area
description
+
+ || | |
+ |0 | 7fff | 128 TB | user-space
virtual memory, different per mm
+__||__|_|___
+ || | |
+ 8000 | +128TB | 7fff | ~16M TB | ... huge,
almost 64 bits wide hole of non-canonical
+ || | | virtual
memory addresses up to the -128 TB
+ || | | starting
offset of kernel mappings.
+__||__|_|___
+|
+| Kernel-space
virtual memory, shared between all processes:
+|___
+ || | |
+ 8000 | -128TB
linux-next: manual merge of the kspp tree with the tip tree
Hi all,
Today's linux-next merge of the kspp tree got a conflict in:
Documentation/x86/x86_64/mm.txt
between commits:
5b1290406579 ("x86/mm/doc: Clean up the x86-64 virtual memory layout
descriptions")
32b89760ddf4 ("x86/mm/doc: Enhance the x86-64 virtual memory layout
descriptions")
from the tip tree and commit:
afaef01c0015 ("x86/entry: Add STACKLEAK erasing the kernel stack at the end
of syscalls")
from the kspp tree.
I fixed it up (see below - could probably be done better) and can carry
the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/x86/x86_64/mm.txt
index 702898633b00,600bc2afa27d..
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@@ -1,124 -1,57 +1,126 @@@
+
+Complete virtual memory map with 4-level page tables
+
-Virtual memory map with 4 level page tables:
-
- - 7fff (=47 bits) user space, different per mm
-hole caused by [47:63] sign extension
-8000 - 87ff (=43 bits) guard hole, reserved for
hypervisor
-8800 - c7ff (=64 TB) direct mapping of all phys.
memory
-c800 - c8ff (=40 bits) hole
-c900 - e8ff (=45 bits) vmalloc/ioremap space
-e900 - e9ff (=40 bits) hole
-ea00 - eaff (=40 bits) virtual memory map (1TB)
-... unused hole ...
-ec00 - fbff (=44 bits) kasan shadow memory (16TB)
-... unused hole ...
- vaddr_end for KASLR
-fe00 - fe7f (=39 bits) cpu_entry_area mapping
-fe80 - feff (=39 bits) LDT remap for PTI
-ff00 - ff7f (=39 bits) %esp fixup stacks
-... unused hole ...
-ffef - fffe (=64 GB) EFI region mapping space
-... unused hole ...
-8000 - 9fff (=512 MB) kernel text mapping, from phys 0
-a000 - feff (1520 MB) module mapping space
-[fixmap start] - ff5f kernel-internal fixmap range
-ff60 - ff600fff (=4 kB) legacy vsyscall ABI
-ffe0 - (=2 MB) unused hole
+Notes:
+
+ - Negative addresses such as "-23 TB" are absolute addresses in bytes,
counted down
+ from the top of the 64-bit address space. It's easier to understand the
layout
+ when seen both in absolute addresses and in distance-from-top notation.
+
+ For example 0xe900 == -23 TB, it's 23 TB lower than the top of
the
+ 64-bit address space ().
+
+ Note that as we get closer to the top of the address space, the notation
changes
+ from TB to GB and then MB/KB.
+
+ - "16M TB" might look weird at first sight, but it's an easier to visualize
size
+ notation than "16 EB", which few will recognize at first sight as 16
exabytes.
+ It also shows it nicely how incredibly large 64-bit address space is.
+
+
+Start addr| Offset | End addr | Size | VM area
description
+
+ || | |
+ |0 | 7fff | 128 TB | user-space
virtual memory, different per mm
+__||__|_|___
+ || | |
+ 8000 | +128TB | 7fff | ~16M TB | ... huge,
almost 64 bits wide hole of non-canonical
+ || | | virtual
memory addresses up to the -128 TB
+ || | | starting
offset of kernel mappings.
+__||__|_|___
+|
+| Kernel-space
virtual memory, shared between all processes:
+|___
+ || | |
+ 8000 | -128TB
linux-next: manual merge of the kspp tree with the tip tree
Hi Kees,
Today's linux-next merge of the kspp tree got a conflict in:
drivers/misc/lkdtm/core.c
between commit:
bef459026b16 ("lkdtm: Test copy_to_user() on bad kernel pointer under
KERNEL_DS")
from the tip tree and commit:
f90d1e0c7804 ("lkdtm: Add a test for STACKLEAK")
from the kspp tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/misc/lkdtm/core.c
index 5a755590d3dc,aca26d81e9b8..
--- a/drivers/misc/lkdtm/core.c
+++ b/drivers/misc/lkdtm/core.c
@@@ -183,7 -183,7 +183,8 @@@ static const struct crashtype crashtype
CRASHTYPE(USERCOPY_STACK_FRAME_FROM),
CRASHTYPE(USERCOPY_STACK_BEYOND),
CRASHTYPE(USERCOPY_KERNEL),
+ CRASHTYPE(USERCOPY_KERNEL_DS),
+ CRASHTYPE(STACKLEAK_ERASING),
};
pgpc_R5k95RSd.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the kspp tree with the tip tree
Hi Kees,
Today's linux-next merge of the kspp tree got a conflict in:
drivers/misc/lkdtm/core.c
between commit:
bef459026b16 ("lkdtm: Test copy_to_user() on bad kernel pointer under
KERNEL_DS")
from the tip tree and commit:
f90d1e0c7804 ("lkdtm: Add a test for STACKLEAK")
from the kspp tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/misc/lkdtm/core.c
index 5a755590d3dc,aca26d81e9b8..
--- a/drivers/misc/lkdtm/core.c
+++ b/drivers/misc/lkdtm/core.c
@@@ -183,7 -183,7 +183,8 @@@ static const struct crashtype crashtype
CRASHTYPE(USERCOPY_STACK_FRAME_FROM),
CRASHTYPE(USERCOPY_STACK_BEYOND),
CRASHTYPE(USERCOPY_KERNEL),
+ CRASHTYPE(USERCOPY_KERNEL_DS),
+ CRASHTYPE(STACKLEAK_ERASING),
};
pgpc_R5k95RSd.pgp
Description: OpenPGP digital signature
