Re: [PATCH v3 05/12] csky: Use initializer for struct vm_unmapped_area_info

2024-03-13 Thread Christophe Leroy
truct this way tree wide. > This will zero any unspecified members. Move the member initializers to the > struct declaration when they are known at that time. Leave the members out > that were manually initialized to zero, as this would be redundant for > designated initializers. > > Sig

Re: [PATCH v3] kprobe/ftrace: bail out if ftrace was killed

2024-05-06 Thread Christophe Leroy
Le 01/05/2024 à 18:29, Stephen Brennan a écrit : > If an error happens in ftrace, ftrace_kill() will prevent disarming > kprobes. Eventually, the ftrace_ops associated with the kprobes will be > freed, yet the kprobes will still be active, and when triggered, they > will use the freed memory, lik

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

2024-09-03 Thread Christophe Leroy
Hi Charlie, Le 29/08/2024 à 09:15, Charlie Jenkins a écrit : The hint address and mmap_flags are necessary to determine if MAP_BELOW_HINT requirements are satisfied. Signed-off-by: Charlie Jenkins --- arch/alpha/kernel/osf_sys.c | 2 ++ arch/arc/mm/mmap.c | 3 +++ arch/a

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

2024-09-06 Thread Christophe Leroy
Le 26/08/2024 à 08:55, Mike Rapoport a écrit : 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 PMD_SIZE'ed pages with ROX permissions as a cache for smaller allocations. Why

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

2024-09-10 Thread Christophe Leroy
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 =

Re: [PATCH] asm-generic: provide generic page_to_phys and phys_to_page implementations

2024-10-09 Thread Christophe Leroy
Le 09/10/2024 à 13:43, Christoph Hellwig a écrit : page_to_phys is duplicated by all architectures, and from some strange reason placed in where it doesn't fit at all. phys_to_page is only provided by a few architectures despite having a lot of open coded users. Provide generic versions in

Re: [PATCH 00/28] vdso: Preparations for generic data storage

2024-11-05 Thread Christophe Leroy
Le 30/10/2024 à 12:39, Thomas Gleixner a écrit : Folks! On Thu, Oct 10 2024 at 09:01, Thomas Weißschuh wrote: Historically each architecture defined their own datapage to store the VDSO data. This stands in contrast to the generic nature of the VDSO code itself. We plan to introduce a generi

Re: [PATCH 2/2] asm-generic: add an optional pfn_valid check to page_to_phys

2024-11-05 Thread Christophe Leroy
Le 23/10/2024 à 07:36, Christoph Hellwig a écrit : page_to_pfn is usually implemented by pointer arithmetics on the memory map, which means that bogus input can lead to even more bogus output. Powerpc had a pfn_valid check on the intermediate pfn in the page_to_phys implementation when CONFIG

Re: [PATCH v3 14/18] powerpc/vdso: Switch to generic storage implementation

2025-02-05 Thread Christophe Leroy
Reviewed-by: Christophe Leroy --- arch/powerpc/Kconfig | 2 + arch/powerpc/include/asm/vdso.h | 1 + arch/powerpc/include/asm/vdso/arch_data.h| 37 + arch/powerpc/include/asm/vdso/getrandom.h| 11 +-- arch/powerpc/include/asm/vdso

Re: [PATCH v3 2/6] syscall.h: add syscall_set_arguments() and syscall_set_return_value()

2025-01-28 Thread Christophe Leroy
Le 28/01/2025 à 10:16, Dmitry V. Levin a écrit : These functions are going to be needed on all HAVE_ARCH_TRACEHOOK architectures to implement PTRACE_SET_SYSCALL_INFO API. The subject is misleading. syscall_set_return_value() already exists on most architectures and was not addressed by comm

Re: [PATCH v2 09/13] arch, mm: set max_mapnr when allocating memory map for FLATMEM

2025-04-08 Thread Christophe Leroy
Hi Mike, Le 14/03/2025 à 10:25, Christophe Leroy a écrit : Le 13/03/2025 à 14:49, Mike Rapoport a écrit : From: "Mike Rapoport (Microsoft)" max_mapnr is essentially the size of the memory map for systems that use FLATMEM. There is no reason to calculate it in each and every ar

Re: [PATCH v2 09/13] arch, mm: set max_mapnr when allocating memory map for FLATMEM

2025-03-14 Thread Christophe Leroy
Le 13/03/2025 à 14:49, Mike Rapoport a écrit : From: "Mike Rapoport (Microsoft)" max_mapnr is essentially the size of the memory map for systems that use FLATMEM. There is no reason to calculate it in each and every architecture when it's anyway calculated in alloc_node_mem_map(). Drop sett

Re: [PATCH] kmap: fix header include to reflect actual path

2025-06-27 Thread Christophe Leroy
Le 27/06/2025 à 17:32, Aurabindo Pillai a écrit : [Vous ne recevez pas souvent de courriers de aurabindo.pil...@amd.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ] There are plenty of header includes like: #include Yes and in reality