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

* Lorenzo Stoakes [241213 10:16]: > 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 the technical side, Liam is right that the copy-pasted arch code > > has inconsistencies (missing checks, order of chec

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

* Kalesh Singh [241211 18:28]: > Introduce csky arch_mmap_hint() and define HAVE_ARCH_MMAP_HINT. > This is a preparatory patch, no functional change is introduced. This also looks like it has changed the validation order and potentially introduced functional changes? All these stem from the same

Re: [PATCH mm-unstable v2 05/16] mm: arc: Use generic_mmap_hint()

* Kalesh Singh [241211 18:28]: > Introduce arc arch_mmap_hint() and define HAVE_ARCH_MMAP_HINT. > This is a preparatory patch, no functional change is introduced. You have changed the order of the map fixed check and the len check. I *think* what you have done is correct, but your comment is cer

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

+ Lorenzo Can you please Cc the people listed in the maintainers on the files you are submitting against? You seemed to Cc everyone but the mmap.c file maintainers? * Kalesh Singh [241211 18:28]: > Hi all, > > This is v2 othe the arch_mmap_hint() series. > > Changes in v2: > - MAP_FIXED

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

* Steven Price [241023 05:31]: > >> * Box64 seems to have a custom allocator based on reading > >> /proc/self/maps to allocate a block of VA space with a low enough > >> address [1] > >> > >> * PHP has code reading /proc/self/maps - I think this is to find a > >> segment which i

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

* Steven Price [241021 09:23]: > On 09/09/2024 10:46, Kirill A. Shutemov wrote: > > On Thu, Sep 05, 2024 at 10:26:52AM -0700, Charlie Jenkins wrote: > >> On Thu, Sep 05, 2024 at 09:47:47AM +0300, Kirill A. Shutemov wrote: > >>> On Thu, Aug 29, 2024 at 12:15:57AM -0700, Charlie Jenkins wrote: > >>>

Re: [PATCH v3 7/8] execmem: add support for cache of large ROX pages

* Mike Rapoport [240909 02:49]: > From: "Mike Rapoport (Microsoft)" > > Using large pages to map text areas reduces iTLB pressure and improves > performance. > > Extend execmem_alloc() with an ability to use huge pages with ROX > permissions as a cache for smaller allocations. > > To populate

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

* 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

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

* Mark Brown [240902 15:09]: > 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 it's own guard gaps. This i

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

the generic implementation in the radix_enabled() case. > > Signed-off-by: Mark Brown It is interesting that book3s64 ppc is special in this regard. Reviewed-by: Liam R. Howlett > --- > arch/powerpc/mm/book3s64/slice.c | 4 ++-- > include/linux/sched/mm.h

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

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 I don't love sparc32/sparc64 requires a wide screen monitor, but it already broke the 80 char limit. Reviewed-by: L