[PATCH 04/22] block: Convert bio_for_each_segment() to bvec_iter

2013-03-27 Thread Kent Overstreet
quot; Cc: Greg Kroah-Hartman Cc: Alexander Viro Cc: Steven Whitehouse Cc: Kent Overstreet Cc: Herton Ronaldo Krzesinski Cc: Tejun Heo Cc: Andrew Morton Cc: Guo Chao Cc: Asai Thambi S P Cc: Selvan Mani Cc: Sam Bradshaw Cc: Matthew Wilcox Cc: Keith Busch Cc: Stephen Hemminger Cc: Quoc-Son

[PATCH] powerpc: Export kvm_guest static key, for bcachefs six locks

2023-09-13 Thread Kent Overstreet
bcachefs's six locks need kvm_guest, via ower_on_cpu() -> vcpu_is_preempted() -> is_kvm_guest() Signed-off-by: Kent Overstreet Cc: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/kernel/firmware.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/kernel/firmwa

Re: [PATCH] powerpc: Export kvm_guest static key, for bcachefs six locks

2023-09-14 Thread Kent Overstreet
On Thu, Sep 14, 2023 at 12:26:53PM +1000, Michael Ellerman wrote: > Kent Overstreet writes: > > bcachefs's six locks need kvm_guest, via > > ower_on_cpu() -> vcpu_is_preempted() -> is_kvm_guest() > > > > Signed-off-by: Kent Overstreet > > Cc: lin

Re: [PATCH 16/22] bcachefs: mark bch2_target_to_text_sb() static

2023-11-08 Thread Kent Overstreet
On Wed, Nov 08, 2023 at 01:58:37PM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > bch2_target_to_text_sb() is only called in the file it is defined in, > and it has no extern prototype: > > fs/bcachefs/disk_groups.c:583:6: error: no previous prototype for > 'bch2_target_to_text_sb' [-Wer

Re: [PATCH 12/13] x86/jitalloc: prepare to allocate exectuatble memory as ROX

2023-06-01 Thread Kent Overstreet
On Thu, Jun 01, 2023 at 12:30:50PM +0200, Peter Zijlstra wrote: > On Thu, Jun 01, 2023 at 01:12:56PM +0300, Mike Rapoport wrote: > > > +static void __init_or_module do_text_poke(void *addr, const void *opcode, > > size_t len) > > +{ > > + if (system_state < SYSTEM_RUNNING) { > > + tex

Re: [PATCH 12/13] x86/jitalloc: prepare to allocate exectuatble memory as ROX

2023-06-01 Thread Kent Overstreet
On Thu, Jun 01, 2023 at 04:54:27PM +, Edgecombe, Rick P wrote: > It is just a local flush, but I wonder how much text_poke()ing is too > much. A lot of the are even inside loops. Can't it do the batch version > at least? > > The other thing, and maybe this is in paranoia category, but it's > p

Re: [PATCH 00/13] mm: jit/text allocator

2023-06-01 Thread Kent Overstreet
On Thu, Jun 01, 2023 at 05:12:03PM +0100, Mark Rutland wrote: > For a while I have wanted to give kprobes its own allocator so that it can > work > even with CONFIG_MODULES=n, and so that it doesn't have to waste VA space in > the modules area. > > Given that, I think these should have their own

Re: [PATCH 12/13] x86/jitalloc: prepare to allocate exectuatble memory as ROX

2023-06-01 Thread Kent Overstreet
On Thu, Jun 01, 2023 at 06:13:44PM +, Edgecombe, Rick P wrote: > > text_poke() _does_ create a separate RW mapping. > > Sorry, I meant a separate RW allocation. Ah yes, that makes sense > > > > > The thing that sucks about text_poke() is that it always does a full > > TLB > > flush, and A

Re: [PATCH 00/13] mm: jit/text allocator

2023-06-04 Thread Kent Overstreet
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 wo

Re: [PATCH 12/13] x86/jitalloc: prepare to allocate exectuatble memory as ROX

2023-06-04 Thread Kent Overstreet
On Thu, Jun 01, 2023 at 08:50:39PM +, Edgecombe, Rick P wrote: > > Ahh! Thanks for that; perhaps the comment in text_poke() about IPIs > > could be a bit clearer. > > > > What is it (if anything) you don't like about text_poke() then? It > > looks > > like it's doing broadly similar things to

Re: [PATCH 00/13] mm: jit/text allocator

2023-06-04 Thread Kent Overstreet
On Sun, Jun 04, 2023 at 02:22:30PM -0700, Song Liu wrote: > On Sun, Jun 4, 2023 at 11:02 AM Kent Overstreet > 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 > > &g

Re: [PATCH 00/13] mm: jit/text allocator

2023-06-05 Thread Kent Overstreet
On Mon, Jun 05, 2023 at 12:20:40PM +0300, Mike Rapoport wrote: > On Fri, Jun 02, 2023 at 10:35:09AM +0100, Mark Rutland wrote: > > On Thu, Jun 01, 2023 at 02:14:56PM -0400, Kent Overstreet wrote: > > > On Thu, Jun 01, 2023 at 05:12:03PM +0100, Mark Rutland wrote: > > >

Re: [PATCH 00/13] mm: jit/text allocator

2023-06-13 Thread Kent Overstreet
On Thu, Jun 08, 2023 at 09:41:16PM +0300, Mike Rapoport wrote: > On Tue, Jun 06, 2023 at 11:21:59AM -0700, Song Liu wrote: > > On Mon, Jun 5, 2023 at 3:09 AM Mark Rutland wrote: > > > > [...] > > > > > > > > Can you give more detail on what parameters you need? If the only > > > > > > extra > >

Re: [PATCH v2 02/12] mm: introduce execmem_text_alloc() and jit_text_alloc()

2023-06-16 Thread Kent Overstreet
ke data sections of a module will use > execmem_data_alloc() interface that will be added later. I like the API split - at the risk of further bikeshedding, perhaps near_text_alloc() and far_text_alloc()? Would be more explicit. Reviewed-by: Kent Overstreet

Re: [PATCH v2 07/12] arm64, execmem: extend execmem_params for generated code definitions

2023-06-17 Thread Kent Overstreet
On Sat, Jun 17, 2023 at 09:57:59AM +0300, Mike Rapoport wrote: > > This is growing fast. :) We have 3 now: text, data, jit. And it will be > > 5 when we split data into rw data, ro data, ro after init data. I wonder > > whether we should still do some type enum here. But we can revisit > > this top

Re: [PATCH v2 07/12] arm64, execmem: extend execmem_params for generated code definitions

2023-06-17 Thread Kent Overstreet
On Sat, Jun 17, 2023 at 09:38:17AM -0700, Song Liu wrote: > On Sat, Jun 17, 2023 at 8:37 AM Kent Overstreet > wrote: > > > > On Sat, Jun 17, 2023 at 09:57:59AM +0300, Mike Rapoport wrote: > > > > This is growing fast. :) We have 3 now: text, data, jit. And it will b

Re: [PATCH v2 06/12] mm/execmem: introduce execmem_data_alloc()

2023-06-18 Thread Kent Overstreet
On Mon, Jun 19, 2023 at 12:32:55AM +0200, Thomas Gleixner wrote: > Mike! > > Sorry for being late on this ... > > On Fri, Jun 16 2023 at 11:50, Mike Rapoport wrote: > > > > +void *execmem_data_alloc(size_t size) > > +{ > > + unsigned long start = execmem_params.modules.data.start; > > + uns

Re: [PATCH v2 06/12] mm/execmem: introduce execmem_data_alloc()

2023-06-18 Thread Kent Overstreet
On Mon, Jun 19, 2023 at 02:43:58AM +0200, Thomas Gleixner wrote: > Kent! Hi Thomas :) > No. I am not. Ok. > Whether that's an internal function or not does not make any difference > at all. Well, at the risk of this discussion going completely off the rails, I have to disagree with you there.

Re: [PATCH v2 02/12] mm: introduce execmem_text_alloc() and jit_text_alloc()

2023-06-19 Thread Kent Overstreet
On Sat, Jun 17, 2023 at 01:38:29PM -0700, Andy Lutomirski wrote: > On Fri, Jun 16, 2023, at 1:50 AM, Mike Rapoport wrote: > > From: "Mike Rapoport (IBM)" > > > > module_alloc() is used everywhere as a mean to allocate memory for code. > > > > Beside being semantically wrong, this unnecessarily tie

Re: [PATCH v2 02/12] mm: introduce execmem_text_alloc() and jit_text_alloc()

2023-06-25 Thread Kent Overstreet
On Sun, Jun 25, 2023 at 08:42:57PM +0300, Mike Rapoport wrote: > On Sun, Jun 25, 2023 at 09:59:34AM -0700, Andy Lutomirski wrote: > > > > > > On Sun, Jun 25, 2023, at 9:14 AM, Mike Rapoport wrote: > > > On Mon, Jun 19, 2023 at 10:09:02AM -0700, Andy Lutomirski wrote: > > >> > > >> On Sun, Jun 18

Re: [RFC PATCH RESEND 23/28] x86/mm: define ARCH_SUPPORTS_PER_VMA_LOCK

2022-09-01 Thread Kent Overstreet
On Thu, Sep 01, 2022 at 10:35:11AM -0700, Suren Baghdasaryan wrote: > Set ARCH_SUPPORTS_PER_VMA_LOCK so that the per-VMA lock support can be > compiled on this architecture. > > Signed-off-by: Suren Baghdasaryan > --- > arch/x86/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/a

Re: [RFC PATCH RESEND 04/28] mm: move mmap_lock assert function definitions

2022-09-01 Thread Kent Overstreet
On Thu, Sep 01, 2022 at 10:34:52AM -0700, Suren Baghdasaryan wrote: > Move mmap_lock assert function definitions up so that they can be used > by other mmap_lock routines. > > Signed-off-by: Suren Baghdasaryan > --- > include/linux/mmap_lock.h | 24 > 1 file changed, 12

Re: [RFC PATCH RESEND 03/28] mm: introduce __find_vma to be used without mmap_lock protection

2022-09-01 Thread Kent Overstreet
it should be mentioned in the commit message that that's what you're doing and why it's safe, because it's not exactly common knowledge and lockless stuff deserves extra scrutiny. Probably worth a comment, too. Reviewed-by: Kent Overstreet

Re: [RFC PATCH RESEND 00/28] per-VMA locks proposal

2022-09-01 Thread Kent Overstreet
On Thu, Sep 01, 2022 at 10:34:48AM -0700, Suren Baghdasaryan wrote: > Resending to fix the issue with the In-Reply-To tag in the original > submission at [4]. > > This is a proof of concept for per-vma locks idea that was discussed > during SPF [1] discussion at LSF/MM this year [2], which conclud

Re: [RFC PATCH RESEND 00/28] per-VMA locks proposal

2022-09-05 Thread Kent Overstreet
On Mon, Sep 05, 2022 at 11:32:48AM -0700, Suren Baghdasaryan wrote: > On Mon, Sep 5, 2022 at 5:32 AM 'Michal Hocko' via kernel-team > wrote: > > > > Unless I am missing something, this is not based on the Maple tree > > rewrite, right? Does the change in the data structure makes any > > difference

Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()

2024-02-23 Thread Kent Overstreet
On Fri, Feb 23, 2024 at 01:46:53PM -0500, Steven Rostedt wrote: > On Fri, 23 Feb 2024 10:30:45 -0800 > Jeff Johnson wrote: > > > On 2/23/2024 9:56 AM, Steven Rostedt wrote: > > > From: "Steven Rostedt (Google)" > > > > > > [ > > >This is a treewide change. I will likely re-create this patch

Re: [PATCH v4 00/15] mm: jit/text allocator

2024-04-11 Thread Kent Overstreet
On Thu, Apr 11, 2024 at 07:00:36PM +0300, Mike Rapoport wrote: > From: "Mike Rapoport (IBM)" > > Hi, > > Since v3 I looked into making execmem more of an utility toolbox, as we > discussed at LPC with Mark Rutland, but it was getting more hairier than > having a struct describing architecture co

[PATCH v2 26/28] powerpc: Convert to printbuf

2022-05-19 Thread Kent Overstreet
This converts from seq_buf to printbuf. We're using printbuf in external buffer mode, so it's a direct conversion, aside from some trivial refactoring in cpu_show_meltdown() to make the code more consistent. Signed-off-by: Kent Overstreet Cc: linuxppc-dev@lists.ozlabs.org --- ar

[PATCH v3 27/33] powerpc: Convert to printbuf

2022-06-05 Thread Kent Overstreet
This converts from seq_buf to printbuf. We're using printbuf in external buffer mode, so it's a direct conversion, aside from some trivial refactoring in cpu_show_meltdown() to make the code more consistent. Signed-off-by: Kent Overstreet Cc: linuxppc-dev@lists.ozlabs.org --- ar

[PATCH v4 27/34] powerpc: Convert to printbuf

2022-06-19 Thread Kent Overstreet
This converts from seq_buf to printbuf. We're using printbuf in external buffer mode, so it's a direct conversion, aside from some trivial refactoring in cpu_show_meltdown() to make the code more consistent. Signed-off-by: Kent Overstreet Cc: linuxppc-dev@lists.ozlabs.org --- ar

[PATCH 04/11] powerpc: Convert to printbuf

2022-08-15 Thread Kent Overstreet
From: Kent Overstreet This converts from seq_buf to printbuf. We're using printbuf in external buffer mode, so it's a direct conversion, aside from some trivial refactoring in cpu_show_meltdown() to make the code more consistent. Signed-off-by: Kent Overstreet Cc: linuxppc-dev@lists.

Re: [PATCH 1/4] crypto: lib/chacha - strongly type the ChaCha state

2025-05-06 Thread Kent Overstreet
ntroduce struct chacha_state: > > struct chacha_state { > u32 x[16]; > }; > > Convert all ChaCha and HChaCha functions to use struct chacha_state. > No functional changes. > > Signed-off-by: Eric Biggers Acked-by: Kent Overstreet > --- > ar