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

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

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 be > > > 5 when we split data into rw data, ro data, ro after init data. I wonder > > > whether we sh

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

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 be > > > > 5 when we split data i

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

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 ties all subsystems > that need to allocate code, such as ftrace, kprobes and BP