Received-SPF: pass (google.com: domain of linux-kernel+bounces-86674-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <tencent_3E8D4B7CAE824BDA238EA2B821310F21EE08@qq.com>
From: Yangyu Chen <cyy@cyyself.name>
To: cyy@cyyself.name
Cc: alexghiti@rivosinc.com,
	andy.chiu@sifive.com,
	charlie@rivosinc.com,
	conor.dooley@microchip.com,
	guoren@kernel.org,
	jszhang@kernel.org,
	linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org,
	linux-mm@kvack.org,
	linux-riscv@lists.infradead.org,
	palmer@dabbelt.com,
	paul.walmsley@sifive.com
Subject: Re: [PATCH v2 0/3] RISC-V: mm: do not treat hint addr on mmap as the upper bound to search
Date: Thu, 29 Feb 2024 20:10:03 +0800
In-Reply-To: <tencent_B2D0435BC011135736262764B511994F4805@qq.com>
References: <tencent_B2D0435BC011135736262764B511994F4805@qq.com>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

This patch has not been reviewed for more than a month. There is another patch that did the same fix but in another way and still has not been reviewed like this. I'm here to do a comparison of some choices briefly to let the maintainer understand the issues and the solutions. I think it's time to make a decision before the next Linux LTS v6.9. As a number of sv48 chips will be released this year.

Issues:

Since commit add2cc6b6515 ("RISC-V: mm: Restrict address space for sv39,sv48,sv57") from patch [1], userspace software cannot create virtual address memory mapping on the hint address if the address larger than (1<<38) on sv48, sv57 capable CPU using mmap without MAP_FIXED set. 

This is because since that commit, the hint address is treated as the upper bound to create the mapping when the hint address is larger than (1<<38).

Existing regression for userspace software since that commit:
- box64 [2]

Some choices are:

1. Do not change it

Con:

This behavior is not the same as x86, arm64, and powerpc when treating memory address space larger than 48-bit. On x86, arm64, and powerpc, if the hint address is larger than 48-bit, mmap will not limit the upper bound to use.

Also, these ISAs limit the mmap to 48-bit by default. However, RISC-V currently uses sv39 by default, which is not the same as the document and commit message.

2. Use my patch

which limits the upper bound of mmap to 47-bit by default, if the hint address is larger than (1<<47), then no limit.

Pros: Let the behavior of mmap align with x86, arm64, powerpc

Cons: A new regression for software that assumes mmap will not return an address larger than the hint address if the hint address is larger than (1<<38) as it has been documented on RISC-V since v6.6. However, there is no change in the widespread sv39 systems we use now.

3. Use Charlie's patch [3]

which adjusts the upper bound to hint address + size.

Pros: Still has upper-bound limit using hint address but allows userspace to create mapping on the hint address without MAP_FIXED set.

Cons: That patch will introduce a new regression even for the sv39 system when creating mmap with the same hint address more than one time if the hint address is less than round-gap.

4. Some new ideas currently are not on the mailing list

Hope this issue can be fixed before the Linux v6.9 release.

Thanks,
Yangyu Chen

[1] https://lore.kernel.org/linux-riscv/20230809232218.849726-2-charlie@rivosinc.com/
[2] https://github.com/ptitSeb/box64/commit/5b700cb6e6f397d2074c49659f7f9915f4a33c5f
[3] https://lore.kernel.org/linux-riscv/20240130-use_mmap_hint_address-v3-0-8a655cfa8bcb@rivosinc.com/