Re: [PATCH mm-unstable v2 00/16] mm: Introduce arch_mmap_hint()

On Fri, Dec 13, 2024 at 10:06:55AM -0500, Kalesh Singh wrote: > On Fri, Dec 13, 2024 at 4:00 AM Lorenzo Stoakes > wrote: > > > > On Thu, Dec 12, 2024 at 05:36:09PM -0800, Andrew Morton wrote: > > > On Thu, 12 Dec 2024 22:51:34 + Lorenzo Stoakes > &g

Re: [PATCH mm-unstable v2 00/16] mm: Introduce arch_mmap_hint()

On Thu, Dec 12, 2024 at 05:36:09PM -0800, Andrew Morton wrote: > On Thu, 12 Dec 2024 22:51:34 +0000 Lorenzo Stoakes > wrote: > > > You've fundamentally violated kernel process and etiquette. I'd be more > > forgiving, but this is at v2 and you've not cc'

Re: [PATCH mm-unstable v2 00/16] mm: Introduce arch_mmap_hint()

NACK. Resend this _as an RFC_, _with the correct maintainers and reviewers cc'd_. You've fundamentally violated kernel process and etiquette. I'd be more forgiving, but this is at v2 and you've not cc'd KEY people. Twice. This is totally unacceptable. See [0] if you are unsure of how to do so. Y

Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits

On Wed, Sep 11, 2024 at 11:18:12PM GMT, Charlie Jenkins wrote: > 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 [2

Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits

(Sorry having issues with my IPv6 setup that duplicated the original email... On Fri, Sep 06, 2024 at 09:14:08AM GMT, Arnd Bergmann wrote: > On Fri, Sep 6, 2024, at 08:14, Lorenzo Stoakes wrote: > > On Fri, Sep 06, 2024 at 07:17:44AM GMT, Arnd Bergmann wrote: > >> On Thu, Sep

Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits

On Fri, Sep 06, 2024 at 07:17:44AM GMT, Arnd Bergmann wrote: > On Thu, Sep 5, 2024, at 21:15, Charlie Jenkins wrote: > > 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 th

Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits

On Fri, Sep 06, 2024 at 07:17:44AM GMT, Arnd Bergmann wrote: > On Thu, Sep 5, 2024, at 21:15, Charlie Jenkins wrote: > > 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 th

Re: [PATCH 3/3] mm: Care about shadow stack guard gap when getting an unmapped area

On Tue, Sep 03, 2024 at 07:20:02PM GMT, Mark Brown wrote: > On Tue, Sep 03, 2024 at 06:49:46PM +0100, Lorenzo Stoakes wrote: > > On Mon, Sep 02, 2024 at 08:08:15PM GMT, Mark Brown wrote: > > > > On x86 there is a custom arch_get_unmapped_area() which was updated by the > &

Re: [PATCH 3/3] mm: Care about shadow stack guard gap when getting an unmapped area

On Mon, Sep 02, 2024 at 08:08:15PM GMT, Mark Brown wrote: > As covered in the commit log for c44357c2e76b ("x86/mm: care about shadow > stack guard gap during placement") our current mmap() implementation does > not take care to ensure that a new mapping isn't placed with existing > mappings inside

Re: [PATCH 2/3] mm: Pass vm_flags to generic_get_unmapped_area()

t; trivially wrapping the generic implementation in the radix_enabled() case. > > Signed-off-by: Mark Brown Acked-by: Lorenzo Stoakes (for mm/mmap.c part) > --- > arch/powerpc/mm/book3s64/slice.c | 4 ++-- > include/linux/sched/mm.h | 4 ++-- > mm/mmap.c

Re: [PATCH 1/3] mm: Make arch_get_unmapped_area() take vm_flags by default

_get_unmapped_area(), as for the x86 implementation and the wrapper used > on other architectures this is modified to supply no flags. > > No functional changes. > > Signed-off-by: Mark Brown mm/mmap.c bit looks reasonable to me! Nice cleanup! :) Acked-by: Lorenzo Stoakes (for mm/mmap.

Re: [PATCH RFC v2 0/4] mm: Introduce MAP_BELOW_HINT

On Fri, Aug 30, 2024 at 08:03:25AM GMT, Dave Hansen wrote: > On 8/29/24 01:42, Lorenzo Stoakes wrote: > >> These applications work on x86 because x86 does an implicit 47-bit > >> restriction of mmap() address that contain a hint address that is less > >> than 48 b

Re: [PATCH RFC v2 0/4] mm: Introduce MAP_BELOW_HINT

On Thu, Aug 29, 2024 at 03:16:53PM GMT, Charlie Jenkins wrote: > On Thu, Aug 29, 2024 at 10:54:25AM +0100, Lorenzo Stoakes wrote: > > On Thu, Aug 29, 2024 at 09:42:22AM GMT, Lorenzo Stoakes wrote: > > > On Thu, Aug 29, 2024 at 12:15:57AM GMT, Charlie Jenkins wrote: > > &g

Re: [PATCH RFC v2 0/4] mm: Introduce MAP_BELOW_HINT

On Thu, Aug 29, 2024 at 09:42:22AM GMT, Lorenzo Stoakes wrote: > On Thu, Aug 29, 2024 at 12:15:57AM GMT, Charlie Jenkins wrote: > > Some applications rely on placing data in free bits addresses allocated > > by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the >

Re: [PATCH RFC v2 0/4] mm: Introduce MAP_BELOW_HINT

iller > To: Andreas Larsson > To: Thomas Gleixner > To: Ingo Molnar > To: Borislav Petkov > To: Dave Hansen > To: x...@kernel.org > To: H. Peter Anvin > To: Andy Lutomirski > To: Peter Zijlstra > To: Muchun Song > To: Andrew Morton > To: Liam R. Howl

Re: [PATCH RFC v2 2/4] mm: Add hint and mmap_flags to struct vm_unmapped_area_info

On Thu, Aug 29, 2024 at 12:15:59AM GMT, Charlie Jenkins wrote: [snip] > diff --git a/mm/mmap.c b/mm/mmap.c > index d0dfc85b209b..34ba0db23678 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -1796,6 +1796,9 @@ generic_get_unmapped_area(struct file *filp, unsigned > long addr, > struct vm_un