On 09/07/24 at 10:30am, Sourabh Jain wrote:
> Hello Baoquan,
>
> Do you think this patch would help reduce lock contention when
> CPU/Memory resources are removed in bulk from a system?
.snip...
--
> > include/linux/kexec.h | 11 ---
> > kernel/crash_core.c | 27 +-
On 09/05/24 at 02:07pm, Sourabh Jain wrote:
> Hello Baoquan,
>
> On 05/09/24 08:53, Baoquan He wrote:
> > On 09/04/24 at 02:55pm, Sourabh Jain wrote:
> > > Hello Baoquan,
> > >
> > > On 30/08/24 16:47, Baoquan He wrote:
> > > > On 08/20/24 at 12:10pm, Sourabh Jain wrote:
> > > > > Hello Baoquan,
Le 07/09/2024 à 16:35, Jason A. Donenfeld a écrit :
On Fri, Sep 06, 2024 at 08:54:49PM +0200, Jason A. Donenfeld wrote:
On Fri, Sep 06, 2024 at 05:14:43PM +0200, Christophe Leroy wrote:
Le 06/09/2024 à 16:46, Jason A. Donenfeld a écrit :
On Fri, Sep 06, 2024 at 04:26:32PM +0200, Christoph
Following query shows that architectures that don't provide
asm/set_memory.h don't use set_memory_...() functions.
$ git grep set_memory_ alpha arc csky hexagon loongarch m68k microblaze mips
nios2 openrisc parisc sh sparc um xtensa
Following query shows that all core users of set_memory_...()
After the following powerpc commits, all calls to set_memory_...()
functions check returned value.
- Commit 8f17bd2f4196 ("powerpc: Handle error in mark_rodata_ro() and
mark_initmem_nx()")
- Commit f7f18e30b468 ("powerpc/kprobes: Handle error returned by
set_memory_rox()")
- Commit 009cf11d4aab ("p
On Fri, 06 Sep 2024 21:52:52 +1000
Michael Ellerman wrote:
> On Fri, 30 Aug 2024 07:31:31 -0400, Abhishek Dubey wrote:
> > This is an adaptation of commit f3a112c0c40d ("x86,rethook,kprobes:
> > Replace kretprobe with rethook on x86") to powerpc.
> >
> > Rethook follows the existing kretprobe im
I received a notification from Patchwork that my patch is now in the state
"Handled Elsewhere".[0] Does that mean someone merged it somewhere? Or that I
should be using a different mailing list? Or something else?
I'd appreciate some guidance.
Thanks,
Dave
[0]
http://patchwork.ozlabs.org/pro
在2024年9月5日九月 下午10:15，Charlie Jenkins写道：
> Some applications rely on placing data in free bits addresses allocated
> by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
> address returned by mmap to be less than the 48-bit address space,
> unless the hint address uses more than
On Sun, Sep 8, 2024 at 6:11 AM Masami Hiramatsu wrote:
>
> On Fri, 06 Sep 2024 21:52:52 +1000
> Michael Ellerman wrote:
>
> > On Fri, 30 Aug 2024 07:31:31 -0400, Abhishek Dubey wrote:
> > > This is an adaptation of commit f3a112c0c40d ("x86,rethook,kprobes:
> > > Replace kretprobe with rethook on
On 09/08/24 at 03:57pm, Dave Vasilevsky wrote:
> I received a notification from Patchwork that my patch is now in the state
> "Handled Elsewhere".[0] Does that mean someone merged it somewhere? Or that I
> should be using a different mailing list? Or something else?
I guess it's powerpc dev's pa
On 08/09/24 16:00, Baoquan He wrote:
On 09/05/24 at 02:07pm, Sourabh Jain wrote:
Hello Baoquan,
On 05/09/24 08:53, Baoquan He wrote:
On 09/04/24 at 02:55pm, Sourabh Jain wrote:
Hello Baoquan,
On 30/08/24 16:47, Baoquan He wrote:
On 08/20/24 at 12:10pm, Sourabh Jain wrote:
Hello Baoquan,
On 09/09/24 at 10:35am, Sourabh Jain wrote:
>
>
> On 08/09/24 16:00, Baoquan He wrote:
> > On 09/05/24 at 02:07pm, Sourabh Jain wrote:
> > > Hello Baoquan,
> > >
> > > On 05/09/24 08:53, Baoquan He wrote:
> > > > On 09/04/24 at 02:55pm, Sourabh Jain wrote:
> > > > > Hello Baoquan,
> > > > >
> >
"Jason A. Donenfeld" writes:
> On Fri, Sep 06, 2024 at 03:43:17PM +0200, Jason A. Donenfeld wrote:
>> On Fri, Sep 06, 2024 at 10:23:08PM +1000, Michael Ellerman wrote:
>> > Christophe Leroy writes:
>> > > When running in a non-root time namespace, the global VDSO data page
>> > > is replaced by a
Costa Shulyupin writes:
> Replace `cpumask_any_and(a, b) >= nr_cpu_ids`
> with the more readable `!cpumask_intersects(a, b)`.
I agree it's more readable.
It would be nice if the change log told me that both functions have
similar performance behaviour. I'm not saying this is a super hot path,
bu
Hello Baoquan,
On 09/09/24 10:53, Baoquan He wrote:
On 09/09/24 at 10:35am, Sourabh Jain wrote:
On 08/09/24 16:00, Baoquan He wrote:
On 09/05/24 at 02:07pm, Sourabh Jain wrote:
Hello Baoquan,
On 05/09/24 08:53, Baoquan He wrote:
On 09/04/24 at 02:55pm, Sourabh Jain wrote:
Hello Baoquan,
Dave Vasilevsky writes:
> I received a notification from Patchwork that my patch is now in the
> state "Handled Elsewhere".[0] Does that mean someone merged it
> somewhere? Or that I should be using a different mailing list? Or
> something else?
>
> I'd appreciate some guidance.
It was sent/Cc'ed
Masami Hiramatsu (Google) writes:
> On Fri, 06 Sep 2024 21:52:52 +1000
> Michael Ellerman wrote:
>
>> On Fri, 30 Aug 2024 07:31:31 -0400, Abhishek Dubey wrote:
>> > This is an adaptation of commit f3a112c0c40d ("x86,rethook,kprobes:
>> > Replace kretprobe with rethook on x86") to powerpc.
>> >
>
From: "Mike Rapoport (Microsoft)"
Hi,
These patches add support for using large ROX pages for allocations of
executable memory on x86.
They address Andy's comments [1] about having executable mappings for code
that was not completely formed.
The approach taken is to allocate ROX memory along w
From: "Mike Rapoport (Microsoft)"
There are a couple of declarations that depend on CONFIG_MMU in
include/linux/vmalloc.h spread all over the file.
Group them all together to improve code readability.
No functional changes.
Signed-off-by: Mike Rapoport (Microsoft)
---
include/linux/vmalloc.h
From: "Mike Rapoport (Microsoft)"
vmalloc allocations with VM_ALLOW_HUGE_VMAP that do not explicitly
specify node ID will use huge pages only if size_per_node is larger than
a huge page.
Still the actual allocated memory is not distributed between nodes and
there is no advantage in such approach.
From: "Mike Rapoport (Microsoft)"
Several architectures support text patching, but they name the header
files that declare patching functions differently.
Make all such headers consistently named text-patching.h and add an empty
header in asm-generic for architectures that do not support text pa
From: "Mike Rapoport (Microsoft)"
In order to support ROX allocations for module text, it is necessary to
handle modifications to the code, such as relocations and alternatives
patching, without write access to that memory.
One option is to use text patching, but this would make module loading
e
From: Song Liu
ftrace_process_locs sorts module mcount, which is inside RO memory. Add a
ftrace_swap_func so that archs can use RO-memory-poke function to do the
sorting.
Signed-off-by: Song Liu
Signed-off-by: Mike Rapoport (Microsoft)
---
include/linux/ftrace.h | 2 ++
kernel/trace/ftrace.c
From: "Mike Rapoport (Microsoft)"
When module text memory will be allocated with ROX permissions, the
memory at the actual address where the module will live will contain
invalid instructions and there will be a writable copy that contains the
actual module code.
Update relocations and alternati
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 the cache, a writable large page is allocated from
From: "Mike Rapoport (Microsoft)"
Enable execmem's cache of PMD_SIZE'ed pages mapped as ROX for module
text allocations.
Signed-off-by: Mike Rapoport (Microsoft)
---
arch/x86/mm/init.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/x86/mm/in
26 matches
Mail list logo
