Skip to content

Commit 371a3c2

Browse files
charlie-rivospalmer-dabbelt
authored andcommitted
docs: riscv: Define behavior of mmap
Define mmap on riscv to not provide an address that uses more bits than the hint address, if provided. Signed-off-by: Charlie Jenkins <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]>
1 parent 73d0526 commit 371a3c2

File tree

1 file changed

+5
-11
lines changed

1 file changed

+5
-11
lines changed

Documentation/arch/riscv/vm-layout.rst

Lines changed: 5 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -144,14 +144,8 @@ passing 0 into the hint address parameter of mmap. On CPUs with an address space
144144
smaller than sv48, the CPU maximum supported address space will be the default.
145145

146146
Software can "opt-in" to receiving VAs from another VA space by providing
147-
a hint address to mmap. A hint address passed to mmap will cause the largest
148-
address space that fits entirely into the hint to be used, unless there is no
149-
space left in the address space. If there is no space available in the requested
150-
address space, an address in the next smallest available address space will be
151-
returned.
152-
153-
For example, in order to obtain 48-bit VA space, a hint address greater than
154-
:code:`1 << 47` must be provided. Note that this is 47 due to sv48 userspace
155-
ending at :code:`1 << 47` and the addresses beyond this are reserved for the
156-
kernel. Similarly, to obtain 57-bit VA space addresses, a hint address greater
157-
than or equal to :code:`1 << 56` must be provided.
147+
a hint address to mmap. When a hint address is passed to mmap, the returned
148+
address will never use more bits than the hint address. For example, if a hint
149+
address of `1 << 40` is passed to mmap, a valid returned address will never use
150+
bits 41 through 63. If no mappable addresses are available in that range, mmap
151+
will return `MAP_FAILED`.

0 commit comments

Comments
 (0)