Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits
On Wed, Sep 11, 2024, at 00:45, Charlie Jenkins wrote:
> On Tue, Sep 10, 2024 at 03:08:14PM -0400, Liam R. Howlett wrote:
>
> I responded to Arnd in the other thread, but I am still not convinced
> that the solution that x86 and arm64 have selected is the best solution.
> The solution of defaulting to 47 bits does allow applications the
> ability to get addresses that are below 47 bits. However, due to
> differences across architectures it doesn't seem possible to have all
> architectures default to the same value. Additionally, this flag will be
> able to help users avoid potential bugs where a hint address is passed
> that causes upper bits of a VA to be used.
>
> The other issue I have with this is that if there is not a hint address
> specified to be greater than 47 bits on x86, then mmap() may return an
> address that is greater than 47-bits. The documentation in
> Documentation/arch/x86/x86_64/5level-paging.rst says:
>
> "If hint address set above 47-bit, but MAP_FIXED is not specified, we try
> to look for unmapped area by specified address. If it's already
> occupied, we look for unmapped area in *full* address space, rather than
> from 47-bit window."
This is also in the commit message of b569bab78d8d ("x86/mm: Prepare
to expose larger address space to userspace"), which introduced it.
However, I don't actually see the fallback to the full address space,
instead the actual behavior seems to be the same as arm64.
Am I missing something in the x86 implementation, or do we just
need to update the documentation?
Arnd
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 6/8] x86/module: perpare module loading for ROX allocations of text
On Mon, Sep 09, 2024 at 10:49:40AM -0400, Steven Rostedt wrote: > On Mon, 9 Sep 2024 17:34:48 +0300 > Mike Rapoport wrote: > > > > This is insane, just force BUILDTIME_MCOUNT_SORT > > > > The comment in ftrace.c says "... while mcount loc in modules can not be > > sorted at build time" > > > > I don't know enough about objtool, but I'd presume it's because the sorting > > should happen after relocations, no? > > > > IIRC, the sorting at build time uses scripts/sorttable.c, which from what I > can tell, only gets called on vmlinux. Regardless of the tool, the sorting should be done after relocation, no? But isn't mcount loc is in data section? Then there should be no problem just drop this patch > -- Steve -- Sincerely yours, Mike. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits
Geert Uytterhoeven writes:
> Hi Christophe,
>
> On Tue, Sep 10, 2024 at 11:21 AM Christophe Leroy
> wrote:
>> >>> diff --git a/include/uapi/linux/personality.h
>> >>> b/include/uapi/linux/personality.h
>> >>> index 49796b7756af..cd3b8c154d9b 100644
>> >>> --- a/include/uapi/linux/personality.h
>> >>> +++ b/include/uapi/linux/personality.h
>> >>> @@ -22,6 +22,7 @@ enum {
>> >>> WHOLE_SECONDS = 0x200,
>> >>> STICKY_TIMEOUTS = 0x400,
>> >>> ADDR_LIMIT_3GB =0x800,
>> >>> + ADDR_LIMIT_47BIT = 0x1000,
>> >>> };
>> >>
>> >> I wonder if ADDR_LIMIT_128T would be clearer?
>> >>
>> >
>> > I don't follow, what does 128T represent?
>>
>> 128T is 128 Terabytes, that's the maximum size achievable with a 47BIT
>> address, that naming would be more consistant with the ADDR_LIMIT_3GB
>> just above that means a 3 Gigabytes limit.
>
> Hence ADDR_LIMIT_128TB?
Yes it should be 128TB. Typo by me.
cheers
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits
Charlie Jenkins writes:
> On Fri, Sep 06, 2024 at 04:59:40PM +1000, Michael Ellerman wrote:
>> Charlie Jenkins writes:
>> > Create a personality flag ADDR_LIMIT_47BIT to support applications
>> > that wish to transition from running in environments that support at
>> > most 47-bit VAs to environments that support larger VAs. This
>> > personality can be set to cause all allocations to be below the 47-bit
>> > boundary. Using MAP_FIXED with mmap() will bypass this restriction.
>> >
>> > Signed-off-by: Charlie Jenkins
>> > ---
>> > include/uapi/linux/personality.h | 1 +
>> > mm/mmap.c| 3 +++
>> > 2 files changed, 4 insertions(+)
>> >
>> > diff --git a/include/uapi/linux/personality.h
>> > b/include/uapi/linux/personality.h
>> > index 49796b7756af..cd3b8c154d9b 100644
>> > --- a/include/uapi/linux/personality.h
>> > +++ b/include/uapi/linux/personality.h
>> > @@ -22,6 +22,7 @@ enum {
>> >WHOLE_SECONDS = 0x200,
>> >STICKY_TIMEOUTS = 0x400,
>> >ADDR_LIMIT_3GB =0x800,
>> > + ADDR_LIMIT_47BIT = 0x1000,
>> > };
>>
>> I wonder if ADDR_LIMIT_128T would be clearer?
>>
>
> I don't follow, what does 128T represent?
Sorry, as Christophe explained it's 128 Terabytes, which is the actual
value of the address limit.
I think expressing it as the address value is probably more widely
understood, and would also match ADDR_LIMIT_3GB.
>> Have you looked at writing an update for the personality(2) man page? :)
>
> I will write an update to the man page if this patch is approved!
Yeah fair enough.
My (poorly expressed) point was that trying to describe the flag for the
man page might highlight that using the 47BIT name requires more
explanation.
cheers
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits
"Arnd Bergmann" writes: > On Mon, Sep 9, 2024, at 23:22, Charlie Jenkins wrote: >> On Fri, Sep 06, 2024 at 10:52:34AM +0100, Lorenzo Stoakes wrote: >>> On Fri, Sep 06, 2024 at 09:14:08AM GMT, Arnd Bergmann wrote: >>> The intent is to optionally be able to run a process that keeps higher bits >>> free for tagging and to be sure no memory mapping in the process will >>> clobber these (correct me if I'm wrong Charlie! :) ... > Let's see what the other architectures do and then come up with > a way that fixes the pointer tagging case first on those that are > broken. We can see if there needs to be an extra flag after that. > Here is what I found: > > - x86_64 uses DEFAULT_MAP_WINDOW of BIT(47), uses a 57 bit > address space when an addr hint is passed. > - arm64 uses DEFAULT_MAP_WINDOW of BIT(47) or BIT(48), returns > higher 52-bit addresses when either a hint is passed or > CONFIG_EXPERT and CONFIG_ARM64_FORCE_52BIT is set (this > is a debugging option) > - ppc64 uses a DEFAULT_MAP_WINDOW of BIT(47) or BIT(48), > returns 52 bit address when an addr hint is passed It's 46 or 47 depending on PAGE_SIZE (4K or 64K): $ git grep "define DEFAULT_MAP_WINDOW_USER64" arch/powerpc/include/asm/task_size_64.h arch/powerpc/include/asm/task_size_64.h:#define DEFAULT_MAP_WINDOW_USER64 TASK_SIZE_128TB arch/powerpc/include/asm/task_size_64.h:#define DEFAULT_MAP_WINDOW_USER64 TASK_SIZE_64TB cheers ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits
On Tue, Sep 10, 2024 at 05:45:07PM -0700, Charlie Jenkins wrote: > On Tue, Sep 10, 2024 at 03:08:14PM -0400, Liam R. Howlett wrote: > > * Catalin Marinas [240906 07:44]: > > > On Fri, Sep 06, 2024 at 09:55:42AM +, Arnd Bergmann wrote: > > > > On Fri, Sep 6, 2024, at 09:14, Guo Ren wrote: > > > > > On Fri, Sep 6, 2024 at 3:18 PM Arnd Bergmann wrote: > > > > >> It's also unclear to me how we want this flag to interact with > > > > >> the existing logic in arch_get_mmap_end(), which attempts to > > > > >> limit the default mapping to a 47-bit address space already. > > > > > > > > > > To optimize RISC-V progress, I recommend: > > > > > > > > > > Step 1: Approve the patch. > > > > > Step 2: Update Go and OpenJDK's RISC-V backend to utilize it. > > > > > Step 3: Wait approximately several iterations for Go & OpenJDK > > > > > Step 4: Remove the 47-bit constraint in arch_get_mmap_end() Point 4 is an ABI change. What guarantees that there isn't still software out there that relies on the old behaviour? > > > > I really want to first see a plausible explanation about why > > > > RISC-V can't just implement this using a 47-bit DEFAULT_MAP_WINDOW > > > > like all the other major architectures (x86, arm64, powerpc64), > > > > > > FWIW arm64 actually limits DEFAULT_MAP_WINDOW to 48-bit in the default > > > configuration. We end up with a 47-bit with 16K pages but for a > > > different reason that has to do with LPA2 support (I doubt we need this > > > for the user mapping but we need to untangle some of the macros there; > > > that's for a separate discussion). > > > > > > That said, we haven't encountered any user space problems with a 48-bit > > > DEFAULT_MAP_WINDOW. So I also think RISC-V should follow a similar > > > approach (47 or 48 bit default limit). Better to have some ABI > > > consistency between architectures. One can still ask for addresses above > > > this default limit via mmap(). > > > > I think that is best as well. > > > > Can we please just do what x86 and arm64 does? > > I responded to Arnd in the other thread, but I am still not convinced > that the solution that x86 and arm64 have selected is the best solution. > The solution of defaulting to 47 bits does allow applications the > ability to get addresses that are below 47 bits. However, due to > differences across architectures it doesn't seem possible to have all > architectures default to the same value. Additionally, this flag will be > able to help users avoid potential bugs where a hint address is passed > that causes upper bits of a VA to be used. The reason we added this limit on arm64 is that we noticed programs using the top 8 bits of a 64-bit pointer for additional information. IIRC, it wasn't even openJDK but some JavaScript JIT. We could have taught those programs of a new flag but since we couldn't tell how many are out there, it was the safest to default to a smaller limit and opt in to the higher one. Such opt-in is via mmap() but if you prefer a prctl() flag, that's fine by me as well (though I think this should be opt-in to higher addresses rather than opt-out of the higher addresses). -- Catalin ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits
On Wed, Sep 11, 2024 at 07:21:27PM +0100, Catalin Marinas wrote: > On Tue, Sep 10, 2024 at 05:45:07PM -0700, Charlie Jenkins wrote: > > On Tue, Sep 10, 2024 at 03:08:14PM -0400, Liam R. Howlett wrote: > > > * Catalin Marinas [240906 07:44]: > > > > On Fri, Sep 06, 2024 at 09:55:42AM +, Arnd Bergmann wrote: > > > > > On Fri, Sep 6, 2024, at 09:14, Guo Ren wrote: > > > > > > On Fri, Sep 6, 2024 at 3:18 PM Arnd Bergmann wrote: > > > > > >> It's also unclear to me how we want this flag to interact with > > > > > >> the existing logic in arch_get_mmap_end(), which attempts to > > > > > >> limit the default mapping to a 47-bit address space already. > > > > > > > > > > > > To optimize RISC-V progress, I recommend: > > > > > > > > > > > > Step 1: Approve the patch. > > > > > > Step 2: Update Go and OpenJDK's RISC-V backend to utilize it. > > > > > > Step 3: Wait approximately several iterations for Go & OpenJDK > > > > > > Step 4: Remove the 47-bit constraint in arch_get_mmap_end() > > Point 4 is an ABI change. What guarantees that there isn't still > software out there that relies on the old behaviour? Yeah I don't think it would be desirable to remove the 47 bit constraint in architectures that already have it. > > > > > > I really want to first see a plausible explanation about why > > > > > RISC-V can't just implement this using a 47-bit DEFAULT_MAP_WINDOW > > > > > like all the other major architectures (x86, arm64, powerpc64), > > > > > > > > FWIW arm64 actually limits DEFAULT_MAP_WINDOW to 48-bit in the default > > > > configuration. We end up with a 47-bit with 16K pages but for a > > > > different reason that has to do with LPA2 support (I doubt we need this > > > > for the user mapping but we need to untangle some of the macros there; > > > > that's for a separate discussion). > > > > > > > > That said, we haven't encountered any user space problems with a 48-bit > > > > DEFAULT_MAP_WINDOW. So I also think RISC-V should follow a similar > > > > approach (47 or 48 bit default limit). Better to have some ABI > > > > consistency between architectures. One can still ask for addresses above > > > > this default limit via mmap(). > > > > > > I think that is best as well. > > > > > > Can we please just do what x86 and arm64 does? > > > > I responded to Arnd in the other thread, but I am still not convinced > > that the solution that x86 and arm64 have selected is the best solution. > > The solution of defaulting to 47 bits does allow applications the > > ability to get addresses that are below 47 bits. However, due to > > differences across architectures it doesn't seem possible to have all > > architectures default to the same value. Additionally, this flag will be > > able to help users avoid potential bugs where a hint address is passed > > that causes upper bits of a VA to be used. > > The reason we added this limit on arm64 is that we noticed programs > using the top 8 bits of a 64-bit pointer for additional information. > IIRC, it wasn't even openJDK but some JavaScript JIT. We could have > taught those programs of a new flag but since we couldn't tell how many > are out there, it was the safest to default to a smaller limit and opt > in to the higher one. Such opt-in is via mmap() but if you prefer a > prctl() flag, that's fine by me as well (though I think this should be > opt-in to higher addresses rather than opt-out of the higher addresses). The mmap() flag was used in previous versions but was decided against because this feature is more useful if it is process-wide. A personality() flag was chosen instead of a prctl() flag because there existed other flags in personality() that were similar. I am tempted to use prctl() however because then we could have an additional arg to select the exact number of bits that should be reserved (rather than being fixed at 47 bits). 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. - Charlie > > -- > Catalin ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits
On Wed, Sep 11, 2024 at 11:38:55PM +1000, Michael Ellerman wrote:
> Geert Uytterhoeven writes:
> > Hi Christophe,
> >
> > On Tue, Sep 10, 2024 at 11:21 AM Christophe Leroy
> > wrote:
> >> >>> diff --git a/include/uapi/linux/personality.h
> >> >>> b/include/uapi/linux/personality.h
> >> >>> index 49796b7756af..cd3b8c154d9b 100644
> >> >>> --- a/include/uapi/linux/personality.h
> >> >>> +++ b/include/uapi/linux/personality.h
> >> >>> @@ -22,6 +22,7 @@ enum {
> >> >>> WHOLE_SECONDS = 0x200,
> >> >>> STICKY_TIMEOUTS = 0x400,
> >> >>> ADDR_LIMIT_3GB =0x800,
> >> >>> + ADDR_LIMIT_47BIT = 0x1000,
> >> >>> };
> >> >>
> >> >> I wonder if ADDR_LIMIT_128T would be clearer?
> >> >>
> >> >
> >> > I don't follow, what does 128T represent?
> >>
> >> 128T is 128 Terabytes, that's the maximum size achievable with a 47BIT
> >> address, that naming would be more consistant with the ADDR_LIMIT_3GB
> >> just above that means a 3 Gigabytes limit.
> >
> > Hence ADDR_LIMIT_128TB?
>
> Yes it should be 128TB. Typo by me.
>
> cheers
47BIT was selected because the usecase for this flag is for applications
that want to store data in the upper bits of a virtual address space. In
this case, how large the virtual address space is irrelevant, and only
the number of bits that are being used, and hence the number of bits
that are free.
- Charlie
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
