| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <Y2eY+LulWaKm7MHl@spud>
Date: Sun, 6 Nov 2022 11:22:32 +0000
From: Conor Dooley <conor@...nel.org>
To: Bagas Sanjaya <bagasdotme@...il.com>
Cc: linux-doc@...r.kernel.org, linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org, Jonathan Corbet <corbet@....net>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Alexandre Ghiti <alexandre.ghiti@...onical.com>
Subject: Re: [PATCH] Documentation: riscv: tableize memory layout
On Sun, Nov 06, 2022 at 05:02:40PM +0700, Bagas Sanjaya wrote:
> Documentation: riscv: tableize memory layout
Minor nit about the $subject - but this is the docs, so I guess there's
nowhere better to mention grammar: "tableize" is not a word. I think
what you want here is "tabulate".
> The memory layout is written as table but it is inside literal code
^ as a table ^ inside a
Anyway, those are minor nits I saw in passing, one actual comment and a
simple question below.
Thanks,
Conor.
> block, which renders as preformatted text. Write the layout in reST
> grid table instead.
>
> Signed-off-by: Bagas Sanjaya <bagasdotme@...il.com>
> ---
> Documentation/riscv/vm-layout.rst | 120 +++++++++++++++---------------
> 1 file changed, 58 insertions(+), 62 deletions(-)
>
> diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst
> index 5b36e45fef60bd..139320e35de81f 100644
> --- a/Documentation/riscv/vm-layout.rst
> +++ b/Documentation/riscv/vm-layout.rst
> @@ -30,70 +30,66 @@ the RISC-V Linux Kernel resides.
> RISC-V Linux Kernel SV39
> ------------------------
>
> -::
> -
> - ========================================================================================================================
> - Start addr | Offset | End addr | Size | VM area description
> - ========================================================================================================================
> - | | | |
> - 0000000000000000 | 0 | 0000003fffffffff | 256 GB | user-space virtual memory, different per mm
> - __________________|____________|__________________|_________|___________________________________________________________
> - | | | |
> - 0000004000000000 | +256 GB | ffffffbfffffffff | ~16M TB | ... huge, almost 64 bits wide hole of non-canonical
> - | | | | virtual memory addresses up to the -256 GB
> - | | | | starting offset of kernel mappings.
> - __________________|____________|__________________|_________|___________________________________________________________
> - |
> - | Kernel-space virtual memory, shared between all processes:
> - ____________________________________________________________|___________________________________________________________
> - | | | |
> - ffffffc6fee00000 | -228 GB | ffffffc6feffffff | 2 MB | fixmap
> - ffffffc6ff000000 | -228 GB | ffffffc6ffffffff | 16 MB | PCI io
> - ffffffc700000000 | -228 GB | ffffffc7ffffffff | 4 GB | vmemmap
> - ffffffc800000000 | -224 GB | ffffffd7ffffffff | 64 GB | vmalloc/ioremap space
> - ffffffd800000000 | -160 GB | fffffff6ffffffff | 124 GB | direct mapping of all physical memory
> - fffffff700000000 | -36 GB | fffffffeffffffff | 32 GB | kasan
> - __________________|____________|__________________|_________|____________________________________________________________
> - |
> - |
> - ____________________________________________________________|____________________________________________________________
> - | | | |
> - ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | modules, BPF
> - ffffffff80000000 | -2 GB | ffffffffffffffff | 2 GB | kernel
> - __________________|____________|__________________|_________|____________________________________________________________
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | Start addr | Offset | End addr | Size | VM area description |
> + +==================+=========+==================+=========+==========================================================+
> + | 0000000000000000 | 0 | 0000003fffffffff | 256 GB | user-space virtual memory, different per mm |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | 0000004000000000 | +256 GB | ffffffbfffffffff | ~16M TB | ... huge, almost 64 bits wide hole of non-canonical |
> + | | | | | virtual memory addresses up to the -256 GB |
> + | | | | | starting offset of kernel mappings. |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | Kernel-space virtual memory, shared between all processes: |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | ffffffc6fee00000 | -228 GB | ffffffc6feffffff | 2 MB | fixmap |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | ffffffc6ff000000 | -228 GB | ffffffc6ffffffff | 16 MB | PCI io |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
^
Will these numbers remain right-aligned in the formatted doc? They were
aligned before in the text form & no longer appear to be.
> + | ffffffc700000000 | -228 GB | ffffffc7ffffffff | 4 GB | vmemmap |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | ffffffc800000000 | -224 GB | ffffffd7ffffffff | 64 GB | vmalloc/ioremap space |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | ffffffd800000000 | -160 GB | fffffff6ffffffff | 124 GB | direct mapping of all physical memory |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | fffffff700000000 | -36 GB | fffffffeffffffff | 32 GB | kasan |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | Identical layout to the 39-bit one from here on: |
This one /is/ sv39. I'd leave this as a blank to match the styling in
the original document.
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | modules, BPF |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | ffffffff80000000 | -2 GB | ffffffffffffffff | 2 GB | kernel |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
>
>
Powered by blists - more mailing lists