From: Song Liu <song@kernel.org>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Mark Rutland <mark.rutland@arm.com>,
Mike Rapoport <rppt@kernel.org>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
"David S. Miller" <davem@davemloft.net>,
Dinh Nguyen <dinguyen@kernel.org>,
Heiko Carstens <hca@linux.ibm.com>, Helge Deller <deller@gmx.de>,
Huacai Chen <chenhuacai@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Michael Ellerman <mpe@ellerman.id.au>,
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Russell King <linux@armlinux.org.uk>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Thomas Gleixner <tglx@linutronix.de>,
Will Deacon <will@kernel.org>,
bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-parisc@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev,
netdev@vger.kernel.org, sparclinux@vger.kernel.org,
x86@kernel.org, Puranjay Mohan <puranjay12@gmail.com>
Subject: Re: [PATCH 00/13] mm: jit/text allocator
Date: Sun, 4 Jun 2023 14:22:30 -0700 [thread overview]
Message-ID: <CAPhsuW7iEDa44jxc_7Cj4KnVhtct-UTO2JtVK-U7o2ynn2iX8Q@mail.gmail.com> (raw)
In-Reply-To: <ZHzRxE5V6YzGVsHy@moria.home.lan>
On Sun, Jun 4, 2023 at 11:02 AM Kent Overstreet
<kent.overstreet@linux.dev> wrote:
>
> On Fri, Jun 02, 2023 at 11:20:58AM -0700, Song Liu wrote:
> > IIUC, arm64 uses VMALLOC address space for BPF programs. The reason
> > is each BPF program uses at least 64kB (one page) out of the 128MB
> > address space. Puranjay Mohan (CC'ed) is working on enabling
> > bpf_prog_pack for arm64. Once this work is done, multiple BPF programs
> > will be able to share a page. Will this improvement remove the need to
> > specify a different address range for BPF programs?
>
> Can we please stop working on BPF specific sub page allocation and focus
> on doing this in mm/? This never should have been in BPF in the first
> place.
That work is mostly independent of the allocator work we are discussing here.
The goal Puranjay's work is to enable the arm64 BPF JIT engine to use a
ROX allocator. The allocator could be the bpf_prog_pack allocator, or jitalloc,
or module_alloc_type. Puranjay is using bpf_prog_alloc for now. But once
jitalloc or module_alloc_type (either one) is merged, we will migrate BPF
JIT engines (x86_64 and arm64) to the new allocator and then tear down
bpf_prog_pack.
Does this make sense?
Thanks,
Song
WARNING: multiple messages have this Message-ID (diff)
From: Song Liu <song@kernel.org>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Mark Rutland <mark.rutland@arm.com>,
Mike Rapoport <rppt@kernel.org>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
"David S. Miller" <davem@davemloft.net>,
Dinh Nguyen <dinguyen@kernel.org>,
Heiko Carstens <hca@linux.ibm.com>, Helge Deller <deller@gmx.de>,
Huacai Chen <chenhuacai@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Michael Ellerman <mpe@ellerman.id.au>,
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Russell King <linux@armlinux.org.uk>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Thomas Gleixner <tglx@linutronix.de>,
Will Deacon <will@kernel.org>,
bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-parisc@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev,
netdev@vger.kernel.org, sparclinux@vger.kernel.org,
x86@kernel.org, Puranjay Mohan <puranjay12@gmail.com>
Subject: Re: [PATCH 00/13] mm: jit/text allocator
Date: Sun, 4 Jun 2023 14:22:30 -0700 [thread overview]
Message-ID: <CAPhsuW7iEDa44jxc_7Cj4KnVhtct-UTO2JtVK-U7o2ynn2iX8Q@mail.gmail.com> (raw)
In-Reply-To: <ZHzRxE5V6YzGVsHy@moria.home.lan>
On Sun, Jun 4, 2023 at 11:02 AM Kent Overstreet
<kent.overstreet@linux.dev> wrote:
>
> On Fri, Jun 02, 2023 at 11:20:58AM -0700, Song Liu wrote:
> > IIUC, arm64 uses VMALLOC address space for BPF programs. The reason
> > is each BPF program uses at least 64kB (one page) out of the 128MB
> > address space. Puranjay Mohan (CC'ed) is working on enabling
> > bpf_prog_pack for arm64. Once this work is done, multiple BPF programs
> > will be able to share a page. Will this improvement remove the need to
> > specify a different address range for BPF programs?
>
> Can we please stop working on BPF specific sub page allocation and focus
> on doing this in mm/? This never should have been in BPF in the first
> place.
That work is mostly independent of the allocator work we are discussing here.
The goal Puranjay's work is to enable the arm64 BPF JIT engine to use a
ROX allocator. The allocator could be the bpf_prog_pack allocator, or jitalloc,
or module_alloc_type. Puranjay is using bpf_prog_alloc for now. But once
jitalloc or module_alloc_type (either one) is merged, we will migrate BPF
JIT engines (x86_64 and arm64) to the new allocator and then tear down
bpf_prog_pack.
Does this make sense?
Thanks,
Song
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Song Liu <song@kernel.org>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Mark Rutland <mark.rutland@arm.com>,
Mike Rapoport <rppt@kernel.org>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
"David S. Miller" <davem@davemloft.net>,
Dinh Nguyen <dinguyen@kernel.org>,
Heiko Carstens <hca@linux.ibm.com>, Helge Deller <deller@gmx.de>,
Huacai Chen <chenhuacai@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Michael Ellerman <mpe@ellerman.id.au>,
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Russell King <linux@armlinux.org.uk>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Thomas Gleixner <tglx@linutronix.de>,
Will Deacon <will@kernel.org>,
bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-parisc@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev,
netdev@vger.kernel.org, sparclinux@vger.kernel.org,
x86@kernel.org, Puranjay Mohan <puranjay12@gmail.com>
Subject: Re: [PATCH 00/13] mm: jit/text allocator
Date: Sun, 4 Jun 2023 14:22:30 -0700 [thread overview]
Message-ID: <CAPhsuW7iEDa44jxc_7Cj4KnVhtct-UTO2JtVK-U7o2ynn2iX8Q@mail.gmail.com> (raw)
In-Reply-To: <ZHzRxE5V6YzGVsHy@moria.home.lan>
On Sun, Jun 4, 2023 at 11:02 AM Kent Overstreet
<kent.overstreet@linux.dev> wrote:
>
> On Fri, Jun 02, 2023 at 11:20:58AM -0700, Song Liu wrote:
> > IIUC, arm64 uses VMALLOC address space for BPF programs. The reason
> > is each BPF program uses at least 64kB (one page) out of the 128MB
> > address space. Puranjay Mohan (CC'ed) is working on enabling
> > bpf_prog_pack for arm64. Once this work is done, multiple BPF programs
> > will be able to share a page. Will this improvement remove the need to
> > specify a different address range for BPF programs?
>
> Can we please stop working on BPF specific sub page allocation and focus
> on doing this in mm/? This never should have been in BPF in the first
> place.
That work is mostly independent of the allocator work we are discussing here.
The goal Puranjay's work is to enable the arm64 BPF JIT engine to use a
ROX allocator. The allocator could be the bpf_prog_pack allocator, or jitalloc,
or module_alloc_type. Puranjay is using bpf_prog_alloc for now. But once
jitalloc or module_alloc_type (either one) is merged, we will migrate BPF
JIT engines (x86_64 and arm64) to the new allocator and then tear down
bpf_prog_pack.
Does this make sense?
Thanks,
Song
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Song Liu <song@kernel.org>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Mark Rutland <mark.rutland@arm.com>,
x86@kernel.org, Catalin Marinas <catalin.marinas@arm.com>,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
Will Deacon <will@kernel.org>,
linux-s390@vger.kernel.org, Helge Deller <deller@gmx.de>,
Huacai Chen <chenhuacai@kernel.org>,
Russell King <linux@armlinux.org.uk>,
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
linux-trace-kernel@vger.kernel.org,
Heiko Carstens <hca@linux.ibm.com>,
Steven Rostedt <rostedt@goodmis.org>,
loongarch@lists.linux.dev, Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>,
linux-arm-kernel@lists.infradead.org,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Puranjay Mohan <puranjay12@gmail.com>,
linux-parisc@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Dinh Nguyen <dinguyen@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
linux-modules@vger.kernel.org, bpf@vger.k ernel.org,
linuxppc-dev@lists.ozlabs.org,
"David S. Miller" <davem@davemloft.net>,
Mike Rapoport <rppt@kernel.org>
Subject: Re: [PATCH 00/13] mm: jit/text allocator
Date: Sun, 4 Jun 2023 14:22:30 -0700 [thread overview]
Message-ID: <CAPhsuW7iEDa44jxc_7Cj4KnVhtct-UTO2JtVK-U7o2ynn2iX8Q@mail.gmail.com> (raw)
In-Reply-To: <ZHzRxE5V6YzGVsHy@moria.home.lan>
On Sun, Jun 4, 2023 at 11:02 AM Kent Overstreet
<kent.overstreet@linux.dev> wrote:
>
> On Fri, Jun 02, 2023 at 11:20:58AM -0700, Song Liu wrote:
> > IIUC, arm64 uses VMALLOC address space for BPF programs. The reason
> > is each BPF program uses at least 64kB (one page) out of the 128MB
> > address space. Puranjay Mohan (CC'ed) is working on enabling
> > bpf_prog_pack for arm64. Once this work is done, multiple BPF programs
> > will be able to share a page. Will this improvement remove the need to
> > specify a different address range for BPF programs?
>
> Can we please stop working on BPF specific sub page allocation and focus
> on doing this in mm/? This never should have been in BPF in the first
> place.
That work is mostly independent of the allocator work we are discussing here.
The goal Puranjay's work is to enable the arm64 BPF JIT engine to use a
ROX allocator. The allocator could be the bpf_prog_pack allocator, or jitalloc,
or module_alloc_type. Puranjay is using bpf_prog_alloc for now. But once
jitalloc or module_alloc_type (either one) is merged, we will migrate BPF
JIT engines (x86_64 and arm64) to the new allocator and then tear down
bpf_prog_pack.
Does this make sense?
Thanks,
Song
next prev parent reply other threads:[~2023-06-04 21:22 UTC|newest]
Thread overview: 220+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-01 10:12 [PATCH 00/13] mm: jit/text allocator Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` [PATCH 01/13] nios2: define virtual address space for modules Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-13 22:16 ` Dinh Nguyen
2023-06-13 22:16 ` Dinh Nguyen
2023-06-13 22:16 ` Dinh Nguyen
2023-06-13 22:16 ` Dinh Nguyen
2023-06-01 10:12 ` [PATCH 02/13] mm: introduce jit_text_alloc() and use it instead of module_alloc() Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` [PATCH 03/13] mm/jitalloc, arch: convert simple overrides of module_alloc to jitalloc Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` [PATCH 04/13] mm/jitalloc, arch: convert remaining " Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 22:35 ` Song Liu
2023-06-01 22:35 ` Song Liu
2023-06-01 22:35 ` Song Liu
2023-06-01 22:35 ` Song Liu
2023-06-01 10:12 ` [PATCH 05/13] module, jitalloc: drop module_alloc Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` [PATCH 06/13] mm/jitalloc: introduce jit_data_alloc() Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` [PATCH 07/13] x86/ftrace: enable dynamic ftrace without CONFIG_MODULES Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` [PATCH 08/13] arch: make jitalloc setup available regardless of CONFIG_MODULES Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` [PATCH 09/13] kprobes: remove dependcy on CONFIG_MODULES Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` [PATCH 10/13] modules, jitalloc: prepare to allocate executable memory as ROX Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` [PATCH 11/13] ftrace: Add swap_func to ftrace_process_locs() Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` [PATCH 12/13] x86/jitalloc: prepare to allocate exectuatble memory as ROX Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:30 ` Peter Zijlstra
2023-06-01 10:30 ` Peter Zijlstra
2023-06-01 10:30 ` Peter Zijlstra
2023-06-01 10:30 ` Peter Zijlstra
2023-06-01 11:07 ` Mike Rapoport
2023-06-01 11:07 ` Mike Rapoport
2023-06-01 11:07 ` Mike Rapoport
2023-06-01 11:07 ` Mike Rapoport
2023-06-02 0:02 ` Song Liu
2023-06-02 0:02 ` Song Liu
2023-06-02 0:02 ` Song Liu
2023-06-02 0:02 ` Song Liu
2023-06-01 17:52 ` Kent Overstreet
2023-06-01 17:52 ` Kent Overstreet
2023-06-01 17:52 ` Kent Overstreet
2023-06-01 17:52 ` Kent Overstreet
2023-06-01 16:54 ` Edgecombe, Rick P
2023-06-01 16:54 ` Edgecombe, Rick P
2023-06-01 16:54 ` Edgecombe, Rick P
2023-06-01 16:54 ` Edgecombe, Rick P
2023-06-01 18:00 ` Kent Overstreet
2023-06-01 18:00 ` Kent Overstreet
2023-06-01 18:00 ` Kent Overstreet
2023-06-01 18:00 ` Kent Overstreet
2023-06-01 18:13 ` Edgecombe, Rick P
2023-06-01 18:13 ` Edgecombe, Rick P
2023-06-01 18:13 ` Edgecombe, Rick P
2023-06-01 18:13 ` Edgecombe, Rick P
2023-06-01 18:38 ` Kent Overstreet
2023-06-01 18:38 ` Kent Overstreet
2023-06-01 18:38 ` Kent Overstreet
2023-06-01 18:38 ` Kent Overstreet
2023-06-01 20:50 ` Edgecombe, Rick P
2023-06-01 20:50 ` Edgecombe, Rick P
2023-06-01 20:50 ` Edgecombe, Rick P
2023-06-01 20:50 ` Edgecombe, Rick P
2023-06-01 23:54 ` Nadav Amit
2023-06-01 23:54 ` Nadav Amit
2023-06-01 23:54 ` Nadav Amit
2023-06-01 23:54 ` Nadav Amit
2023-06-05 2:52 ` Steven Rostedt
2023-06-05 2:52 ` Steven Rostedt
2023-06-05 2:52 ` Steven Rostedt
2023-06-05 2:52 ` Steven Rostedt
2023-06-05 8:11 ` Mike Rapoport
2023-06-05 8:11 ` Mike Rapoport
2023-06-05 8:11 ` Mike Rapoport
2023-06-05 8:11 ` Mike Rapoport
2023-06-05 16:10 ` Edgecombe, Rick P
2023-06-05 16:10 ` Edgecombe, Rick P
2023-06-05 16:10 ` Edgecombe, Rick P
2023-06-05 16:10 ` Edgecombe, Rick P
2023-06-05 20:42 ` Mike Rapoport
2023-06-05 20:42 ` Mike Rapoport
2023-06-05 20:42 ` Mike Rapoport
2023-06-05 20:42 ` Mike Rapoport
2023-06-05 21:01 ` Edgecombe, Rick P
2023-06-05 21:01 ` Edgecombe, Rick P
2023-06-05 21:01 ` Edgecombe, Rick P
2023-06-05 21:01 ` Edgecombe, Rick P
2023-06-05 21:11 ` Nadav Amit
2023-06-05 21:11 ` Nadav Amit
2023-06-05 21:11 ` Nadav Amit
2023-06-05 21:11 ` Nadav Amit
2023-06-04 21:47 ` Kent Overstreet
2023-06-04 21:47 ` Kent Overstreet
2023-06-04 21:47 ` Kent Overstreet
2023-06-04 21:47 ` Kent Overstreet
2023-06-01 22:49 ` Song Liu
2023-06-01 22:49 ` Song Liu
2023-06-01 22:49 ` Song Liu
2023-06-01 22:49 ` Song Liu
2023-06-01 10:12 ` [PATCH 13/13] x86/jitalloc: make memory allocated for code ROX Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 10:12 ` Mike Rapoport
2023-06-01 16:12 ` [PATCH 00/13] mm: jit/text allocator Mark Rutland
2023-06-01 16:12 ` Mark Rutland
2023-06-01 16:12 ` Mark Rutland
2023-06-01 16:12 ` Mark Rutland
2023-06-01 18:14 ` Kent Overstreet
2023-06-01 18:14 ` Kent Overstreet
2023-06-01 18:14 ` Kent Overstreet
2023-06-01 18:14 ` Kent Overstreet
2023-06-02 9:35 ` Mark Rutland
2023-06-02 9:35 ` Mark Rutland
2023-06-02 9:35 ` Mark Rutland
2023-06-02 9:35 ` Mark Rutland
2023-06-02 18:20 ` Song Liu
2023-06-02 18:20 ` Song Liu
2023-06-02 18:20 ` Song Liu
2023-06-02 18:20 ` Song Liu
2023-06-03 21:11 ` Puranjay Mohan
2023-06-03 21:11 ` Puranjay Mohan
2023-06-03 21:11 ` Puranjay Mohan
2023-06-03 21:11 ` Puranjay Mohan
2023-06-04 18:02 ` Kent Overstreet
2023-06-04 18:02 ` Kent Overstreet
2023-06-04 18:02 ` Kent Overstreet
2023-06-04 18:02 ` Kent Overstreet
2023-06-04 21:22 ` Song Liu [this message]
2023-06-04 21:22 ` Song Liu
2023-06-04 21:22 ` Song Liu
2023-06-04 21:22 ` Song Liu
2023-06-04 21:40 ` Kent Overstreet
2023-06-04 21:40 ` Kent Overstreet
2023-06-04 21:40 ` Kent Overstreet
2023-06-04 21:40 ` Kent Overstreet
2023-06-05 4:05 ` Song Liu
2023-06-05 4:05 ` Song Liu
2023-06-05 4:05 ` Song Liu
2023-06-05 4:05 ` Song Liu
2023-06-05 9:20 ` Mike Rapoport
2023-06-05 9:20 ` Mike Rapoport
2023-06-05 9:20 ` Mike Rapoport
2023-06-05 9:20 ` Mike Rapoport
2023-06-05 10:09 ` Mark Rutland
2023-06-05 10:09 ` Mark Rutland
2023-06-05 10:09 ` Mark Rutland
2023-06-05 10:09 ` Mark Rutland
2023-06-06 10:16 ` Mike Rapoport
2023-06-06 10:16 ` Mike Rapoport
2023-06-06 10:16 ` Mike Rapoport
2023-06-06 10:16 ` Mike Rapoport
2023-06-06 18:21 ` Song Liu
2023-06-06 18:21 ` Song Liu
2023-06-06 18:21 ` Song Liu
2023-06-06 18:21 ` Song Liu
2023-06-08 18:41 ` Mike Rapoport
2023-06-08 18:41 ` Mike Rapoport
2023-06-08 18:41 ` Mike Rapoport
2023-06-08 18:41 ` Mike Rapoport
2023-06-09 17:02 ` Song Liu
2023-06-09 17:02 ` Song Liu
2023-06-09 17:02 ` Song Liu
2023-06-09 17:02 ` Song Liu
2023-06-12 21:34 ` Mike Rapoport
2023-06-12 21:34 ` Mike Rapoport
2023-06-12 21:34 ` Mike Rapoport
2023-06-12 21:34 ` Mike Rapoport
2023-06-13 18:56 ` Kent Overstreet
2023-06-13 18:56 ` Kent Overstreet
2023-06-13 18:56 ` Kent Overstreet
2023-06-13 18:56 ` Kent Overstreet
2023-06-13 21:09 ` Mike Rapoport
2023-06-13 21:09 ` Mike Rapoport
2023-06-13 21:09 ` Mike Rapoport
2023-06-13 21:09 ` Mike Rapoport
2023-07-20 8:53 ` Mike Rapoport
2023-07-20 8:53 ` Mike Rapoport
2023-07-20 8:53 ` Mike Rapoport
2023-07-20 8:53 ` Mike Rapoport
2023-06-05 21:13 ` Kent Overstreet
2023-06-05 21:13 ` Kent Overstreet
2023-06-05 21:13 ` Kent Overstreet
2023-06-05 21:13 ` Kent Overstreet
2023-06-02 0:36 ` Song Liu
2023-06-02 0:36 ` Song Liu
2023-06-02 0:36 ` Song Liu
2023-06-02 0:36 ` Song Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPhsuW7iEDa44jxc_7Cj4KnVhtct-UTO2JtVK-U7o2ynn2iX8Q@mail.gmail.com \
--to=song@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bpf@vger.kernel.org \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=dinguyen@kernel.org \
--cc=hca@linux.ibm.com \
--cc=kent.overstreet@linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-modules@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=mcgrof@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=naveen.n.rao@linux.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=palmer@dabbelt.com \
--cc=puranjay12@gmail.com \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=sparclinux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tsbogend@alpha.franken.de \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.