<dramforever[m]>
is the linux man-pages at binding https://man7.org/linux/man-pages/man2/mmap.2.html ? if not, that's kinda weird... and if it is why don't we just implement the "nearby page boundary" behavior, plus something like limiting to sv39/sv48 by default like other architectures
<dramforever[m]>
i meant, is the manpage at mmap(2) "binding" in the sense that it documents how mmap(2) should work
<dramforever[m]>
as mentioned somewhere in the bunch of threads, at least box64 broke because it expects the "use hint if possible" behavior without specifying MAP_FIXED
<YangyuChen[m]>
<dramforever[m]> "is the linux man-pages at..." <- > why don't we just implement the "nearby page boundary" behavior, plus something like limiting to sv39/sv48 by default like other architectures
<YangyuChen[m]>
Charlie did this before. However, that patch does not use addr+size to select the nearby page boundary but uses the address itself, which causes some problems.
ganboing has quit [Quit: Client closed]
<dramforever[m]>
i still feel this scheme is kinda insane, like why can't we just do what x86 already did
<YangyuChen[m]>
At that time, I suggested using SV48 by default and using size to select, and then Charlie came up with the idea to limit the upper bound based on the address and the size, which caused the problem we see now.
<dramforever[m]>
> When a hint address is passed to mmap, the returned address will never use more bits than the hint address.
<dramforever[m]>
did charlie just invent this out of nowhere ... ? i don't think this is how things work anywhere else
<dramforever[m]>
hmmm "If another mapping already exists there, the kernel picks a new address that may or may not depend on the hint."
levitating has quit [Remote host closed the connection]
<dramforever[m]>
so i don't think using hint+size as an upper bound makes much sense either but i guess it technically just "depends on the hint"
<dramforever[m]>
so basically the question is still "why can't we just do what x86 did"
n_crm has quit [Changing host]
n_crm has joined #riscv
<YangyuChen[m]>
On x86 and aarch64, the kernel also limits the address to 47 bits by default; if there is no space below 47 bits, we will also get an ENOMEM error. However, it does not break the userspace since we are not limiting the upper bound.
<dramforever[m]>
yeah just do that
<dramforever[m]>
there literally is precedence
ganboing has joined #riscv
kxxt[m] has joined #riscv
<kxxt[m]>
Yes, we should get it right in one go, instead of fixing things after it reaches a kernel release and breaks userspace.