RISC-V: mm: do not treat hint addr on mmap as the upper bound to search #490
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Upstream branch: e5075d8 |
|
Upstream branch: e5075d8 |
bjoto
force-pushed
the
series/818329=>for-next
branch
from
168e31d
to
517cdd0
Compare
|
Upstream branch: 3a6dd5f |
bjoto
force-pushed
the
series/818329=>for-next
branch
from
517cdd0
to
f5a1269
Compare
|
Upstream branch: e2d6b54 |
bjoto
force-pushed
the
series/818329=>for-next
branch
from
f5a1269
to
a1b0a9b
Compare
|
Upstream branch: e2d6b54 |
bjoto
force-pushed
the
series/818329=>for-next
branch
from
a1b0a9b
to
fab04b6
Compare
|
Upstream branch: cb4ede9 |
bjoto
force-pushed
the
series/818329=>for-next
branch
from
fab04b6
to
6b486c7
Compare
bjoto
force-pushed
the
for-next_base
branch
3 times, most recently
from
86689b1
to
43a5b17
Compare
|
Upstream branch: 45e0b0f |
This patch reverted the meaning of the addr parameter in the mmap syscall change from the previous commit add2cc6 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57") from patch[1] which treats hint addr as the upper bound of the mmap return address. However, some userspace software assumes mmap will attempt to create mapping on the hint address if possible without MAP_FIXED set, thus these software will always use the fallback path as the return address is not the same as the hint, which may lead to some performance overhead. Other ISAs like x86, arm64, and powerpc also meet this issue which has userspace virtual address bits larger than 48-bit and userspace software may use the MSB beyond 48-bit to store some information. Still, these ISAs didn't change the meaning of the hint address and only limited the address space to 48-bit when the hint address did not go beyond the default map window. Thus, this patch makes the behavior of mmap syscall on RISC-V sv57 capable system align with x86, arm64, powerpc by only limiting the address space to DEFAULT_MAP_WINDOW which is defined as not larger than 47-bit. If a user program wants to use sv57 address space, it can use mmap with a hint address larger than BIT(47) as it is already documented in x86 and arm64. And this code is copied from kernel source code on powerpc. [1]. https://lore.kernel.org/r/20230809232218.849726-2-charlie@rivosinc.com Signed-off-by: Yangyu Chen <cyy@cyyself.name> Signed-off-by: Björn Töpel <bjorn@rivosinc.com>
The original test from the previous patchset[1] assumes the hint address on mmap is treated as the upper bound of the return address. As we reverted this special behavior, this test should be updated to reflect the change. [1]. https://lore.kernel.org/linux-riscv/20230809232218.849726-1-charlie@rivosinc.com/ Signed-off-by: Yangyu Chen <cyy@cyyself.name> Signed-off-by: Björn Töpel <bjorn@rivosinc.com>
The original documentation from the previous patchset[1] treated the hint address on mmap as the upper bound, since we have already removed this behavior, this document should be updated. Most of the content is copied from the corresponding feature in x86_64 with some modifications to align with the current kernel's behavior on RISC-V. [1]. https://lore.kernel.org/linux-riscv/20230809232218.849726-1-charlie@rivosinc.com/ Signed-off-by: Yangyu Chen <cyy@cyyself.name> Signed-off-by: Björn Töpel <bjorn@rivosinc.com>
bjoto
force-pushed
the
series/818329=>for-next
branch
from
6b486c7
to
ec4ad68
Compare
bjoto
pushed a commit
that referenced
this pull request
May 17, 2024
Recent additions in BPF like cpu v4 instructions, test_bpf module exhibits the following failures: test_bpf: #82 ALU_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #83 ALU_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #84 ALU64_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #85 ALU64_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #86 ALU64_MOVSX | BPF_W jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #165 ALU_SDIV_X: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times) test_bpf: #166 ALU_SDIV_K: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times) test_bpf: #169 ALU_SMOD_X: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) test_bpf: #170 ALU_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) test_bpf: #172 ALU64_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) test_bpf: #313 BSWAP 16: 0x0123456789abcdef -> 0xefcd eBPF filter opcode 00d7 (@2) unsupported jited:0 301 PASS test_bpf: #314 BSWAP 32: 0x0123456789abcdef -> 0xefcdab89 eBPF filter opcode 00d7 (@2) unsupported jited:0 555 PASS test_bpf: #315 BSWAP 64: 0x0123456789abcdef -> 0x67452301 eBPF filter opcode 00d7 (@2) unsupported jited:0 268 PASS test_bpf: #316 BSWAP 64: 0x0123456789abcdef >> 32 -> 0xefcdab89 eBPF filter opcode 00d7 (@2) unsupported jited:0 269 PASS test_bpf: #317 BSWAP 16: 0xfedcba9876543210 -> 0x1032 eBPF filter opcode 00d7 (@2) unsupported jited:0 460 PASS test_bpf: #318 BSWAP 32: 0xfedcba9876543210 -> 0x10325476 eBPF filter opcode 00d7 (@2) unsupported jited:0 320 PASS test_bpf: #319 BSWAP 64: 0xfedcba9876543210 -> 0x98badcfe eBPF filter opcode 00d7 (@2) unsupported jited:0 222 PASS test_bpf: #320 BSWAP 64: 0xfedcba9876543210 >> 32 -> 0x10325476 eBPF filter opcode 00d7 (@2) unsupported jited:0 273 PASS test_bpf: #344 BPF_LDX_MEMSX | BPF_B eBPF filter opcode 0091 (@5) unsupported jited:0 432 PASS test_bpf: #345 BPF_LDX_MEMSX | BPF_H eBPF filter opcode 0089 (@5) unsupported jited:0 381 PASS test_bpf: #346 BPF_LDX_MEMSX | BPF_W eBPF filter opcode 0081 (@5) unsupported jited:0 505 PASS test_bpf: #490 JMP32_JA: Unconditional jump: if (true) return 1 eBPF filter opcode 0006 (@1) unsupported jited:0 261 PASS test_bpf: Summary: 1040 PASSED, 10 FAILED, [924/1038 JIT'ed] Fix them by adding missing processing. Fixes: daabb2b ("bpf/tests: add tests for cpuv4 instructions") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/91de862dda99d170697eb79ffb478678af7e0b27.1709652689.git.christophe.leroy@csgroup.eu
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull request for series with
subject: RISC-V: mm: do not treat hint addr on mmap as the upper bound to search
version: 2
url: https://patchwork.kernel.org/project/linux-riscv/list/?series=818329