On Thu, Sep 12, 2024 at 02:15:59PM -0700, Charlie Jenkins wrote:
On Thu, Sep 12, 2024 at 11:53:49AM +0100, Catalin Marinas wrote:
On Wed, Sep 11, 2024 at 11:18:12PM -0700, Charlie Jenkins wrote:
Opting-in to the higher address space is reasonable. However, it is not my preference, because the purpose of this flag is to ensure that allocations do not exceed 47-bits, so it is a clearer ABI to have the applications that want this guarantee to be the ones setting the flag, rather than the applications that want the higher bits setting the flag.
Yes, this would be ideal. Unfortunately those applications don't know they need to set a flag in order to work.
It's not a regression, the applications never worked (on platforms that do not have this default). The 47-bit default would allow applications that didn't work to start working at the cost of a non-ideal ABI. That doesn't seem like a reasonable tradeoff to me. If applications want to run on new hardware that has different requirements, shouldn't they be required to update rather than expect the kernel will solve their problems for them?
That's a valid point but it depends on the application and how much you want to spend updating user-space. OpenJDK is fine, if you need a JIT you'll have to add support for that architecture anyway. But others are arch-agnostic, you just recompile to your target. It's not an ABI problem, more of an API one.
The x86 case (and powerpc/arm64) was different, the 47-bit worked for a long time before expanding it. So it made a lot of sense to keep the same default.
Anyway, the prctl() can go both ways, either expanding or limiting the default address space. So I'd be fine with such interface.