Dropping netdev because this is a storage patch.
On 5/5/25 5:09 PM, Sasha Levin wrote:
> From: Mike Christie
>
> [ Upstream commit 891b99eab0f89dbe08d216f4ab71acbeaf7a3102 ]
>
> This has us return queue full if we can't allocate a page during the
> copy operation so
On 4/7/25 3:17 AM, Michael S. Tsirkin wrote:
> On Fri, Mar 28, 2025 at 06:02:48PM +0800, Cindy Lu wrote:
>> Abstract vhost worker operations (create/stop/wakeup) into an ops
>> structure to prepare for kthread mode support.
>>
>> Signed-off-by: Cindy Lu
>
> I worry about the overhead of indirect
On 4/8/25 4:45 AM, Cindy Lu wrote:
> On Tue, Apr 8, 2025 at 12:06 AM Mike Christie
> wrote:
>>
>> On 4/7/25 3:17 AM, Michael S. Tsirkin wrote:
>>> On Fri, Mar 28, 2025 at 06:02:48PM +0800, Cindy Lu wrote:
>>>> Abstract vhost worker operations (create/sto
On 3/28/25 5:02 AM, Cindy Lu wrote:
> +static int vhost_kthread_worker_create(struct vhost_worker *worker,
> +struct vhost_dev *dev, const char *name)
> +{
> + struct task_struct *task;
> + u32 id;
> + int ret;
> +
> + task = kthread_create(vhost_
, store the log
> buffer during the submission path and log it in the completion or error
> handling path.
>
> For Asynchronous Notifications, only the submission path is involved.
>
> Suggested-by: Joao Martins
> Signed-off-by: Dongli Zhang
>
Reviewed-by: Mike Christie
nt
> VHOST_SET_FEATURES/VHOST_SCSI_SET_ENDPOINT.
> - Encapsulate the one-time on-demand per-cmd log buffer alloc/copy in a
> helper, as suggested by Mike.
Reviewed-by: Mike Christie
-off-by: Dongli Zhang
Reviewed-by: Mike Christie
-off-by: Dongli Zhang
Reviewed-by: Mike Christie
On 3/17/25 7:04 PM, Dongli Zhang wrote:
> @@ -1390,6 +1424,24 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct
> vhost_virtqueue *vq)
> goto err;
> }
>
> + if (unlikely(vq_log && log_num)) {
> + if (!cmd->tvc_log)
> +
() may reset it only
> after certain condition checks.
>
> Suggested-by: Joao Martins
> Signed-off-by: Dongli Zhang
Reviewed-by: Mike Christie
MM is QEMU. The vq->log_base is from QEMU userpace and can be
> reclaimed via gfree(). As a result, this causes invalid memory writes to
> QEMU userspace.
>
> The control queue path has the same issue.
>
> Signed-off-by: Dongli Zhang
> ---
Reviewed-by: Mike Christie
e response in a single
> descriptor.
>
> Similar issue in vhost_scsi_send_bad_target() has been fixed in previous
> commit.
>
> Fixes: 3ca51662f818 ("vhost-scsi: Add better resource allocation failure
> handling")
> Signed-off-by: Dongli Zhang
Reviewed-by: Mike Christie
queue.
>
> Fixes: 664ed90e621c ("vhost/scsi: Set VIRTIO_F_ANY_LAYOUT +
> VIRTIO_F_VERSION_1 feature bits")
> Signed-off-by: Dongli Zhang
Reviewed-by: Mike Christie
From: "Mike Rapoport (Microsoft)"
The ROX memory allocations are part of a larger vmalloc allocation and
annotating them with kmemleak_not_leak() confuses kmemleak.
Skip kmemleak_not_leak() annotations for the ROX areas.
Fixes: c287c0723329 ("module: switch to execmem API for
On 2/7/25 12:41 PM, Dongli Zhang wrote:
> @@ -378,6 +384,11 @@ static void vhost_scsi_release_tmf_res(struct
> vhost_scsi_tmf *tmf)
> {
> struct vhost_scsi_inflight *inflight = tmf->inflight;
>
> + if (tmf->tmf_log_num) {
> + kfree(tmf->tmf_log);
> + tmf->tmf_l
On 2/7/25 12:41 PM, Dongli Zhang wrote:
> The vhost-scsi I/O queue uses vhost_scsi_cmd. Pre-allocate the log buffer
> during vhost_scsi_cmd allocation, and free it when vhost_scsi_cmd is
> reclaimed.
>
> The cached log buffer will be uses in upcoming patches to log write
> descriptors for the I/O
MU that can toggle the
inherit owner bit so I could test both modes.
Tested-by: Mike Christie
On 12/30/24 6:43 AM, Cindy Lu wrote:
> The vhost_scsi VHOST_NEW_WORKER requires the inherit_owner
> setting to be true. So we need to implement a check for this.
>
> Signed-off-by: Cindy Lu
> ---
> drivers/vhost/scsi.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/vho
On 1/17/25 10:50 AM, Mike Christie wrote:
>> You are welcome. There is another bug I was about to report, but I'm not
>> sure whether I should create a new thread. I feel that the original design
>> of dynamically allocating new vs_tpgs in vhost_scsi_set_endpoint is not
&g
equest.
>
I saw that while reviewing the code. Here is my patch. I just added a new
goto, because we don't need to do the undepend since we never did any
depend calls.
>From 0474c5d41968095ea911d48159e4f6a129f1a862 Mon Sep 17 00:00:00 2001
From: Mike Christie
Date: Wed, 15 Jan 2025 19:0
On 1/14/25 1:40 AM, 张浩然 wrote:
> After reevaluating the PoC, I realized that my initial claim was incorrect.
> The target WWN in the second vhost_scsi_set_endpoint() call is not the same
> as in the first one. Below is my targetcli status:
>
> o- vhost . [
On 1/14/25 5:26 AM, Michael S. Tsirkin wrote:
>
> Wanna post the patch, Mike?
>
Yeah, I'll send a patch.
On 1/12/25 11:35 AM, michael.chris...@oracle.com wrote:
> So I think to fix the issue, we would want to:
>
> 1. move the
>
> memcpy(vs_tpg, vs->vs_tpg, len);
>
> to the end of the function after we do the vhost_scsi_flush. This will
> be more complicated than the current memcpy though. We will w
but still be running a guest
in clear text
* Some guests could be encrypted while others are clear text
To remedy the disadvantage, the write function would need to check if guest
encryption is
currently active for a specific guest.
Mike
+static ssize_t kvm_kmem_gmem_wri
On 11/5/24 1:25 AM, Cindy Lu wrote:
> +static int vhost_attach_cgroups(struct vhost_dev *dev)
> +{
> + struct vhost_worker *worker;
> + unsigned long i;
> + int ret;
> +
> + /*
> + * Free the default worker we created and cleanup workers userspace
> + * created but couldn'
On 11/5/24 3:39 AM, Jason Wang wrote:
> On Tue, Nov 5, 2024 at 3:28 PM Cindy Lu wrote:
>>
>> Add a new UAPI to enable setting the vhost device to task mode.
>> The userspace application can use VHOST_SET_INHERIT_FROM_OWNER
>> to configure the mode if necessary.
>> This setting must be applied befo
On 11/5/24 1:25 AM, Cindy Lu wrote:
> The vhost_scsi VHOST_NEW_WORKER requires the inherit_owner
> setting to be true. So we need to implement a check for this.
>
> Signed-off-by: Cindy Lu
> ---
> drivers/vhost/scsi.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/vhost/s
On 10/3/24 8:58 PM, Cindy Lu wrote:
> Add back the previously removed vhost_worker function to support the kthread
> and rename it vhost_run_work_kthread_list.
>
> The old function vhost_worker was change to support task in
> commit 6e890c5d5021 ("vhost: use vhost_tasks for worker threads")
> chan
On 10/3/24 8:58 PM, Cindy Lu wrote:
> +static void vhost_workers_free(struct vhost_dev *dev)
> +{
> + if (enforce_inherit_owner)
> + vhost_workers_free_task(dev);
> + else
> + vhost_workers_free_kthread(dev);
> +}
With patch 7, userspace could change enforce_inherit
On 10/3/24 8:58 PM, Cindy Lu wrote:
> +static struct vhost_worker *vhost_worker_create(struct vhost_dev *dev)
> +{
> + if (enforce_inherit_owner)
> + return vhost_worker_create_task(dev);
> + else
> + return vhost_worker_create_kthread(dev);
> +}
The reason we are i
On 10/3/24 8:58 PM, Cindy Lu wrote:
> Add a new UAPI to support setting the vhost device to
> use task mode. The user space application needs to use
> VHOST_SET_INHERIT_FROM_OWNER to set the mode.
> This setting must be set before VHOST_SET_OWNER is set.
>
> Signed-off-by: Cindy Lu
> ---
> drive
On 9/10/24 2:41 AM, Michael S. Tsirkin wrote:
> On Mon, Sep 09, 2024 at 10:00:38AM +0800, Cindy Lu wrote:
>> In commit 6e890c5d5021 ("vhost: use vhost_tasks for worker threads"),
>> vhost removed the support for the kthread API. However, there are
>> still situations where there is a request to use
On 9/10/24 10:45 PM, Jason Wang wrote:
>>> It depends on how we define "secure". There's plenty of users of
>>> kthread and if I was not wrong, mike may still need to fix some bugs.
>>>
>>
>> which bugs?
>
> https://lore.kernel.org
On 8/16/24 1:17 PM, Michael S. Tsirkin wrote:
> On Fri, Aug 16, 2024 at 11:10:32AM -0700, Sean Christopherson wrote:
>> On Fri, Aug 16, 2024, syzbot wrote:
On Wed, May 29, 2024, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:9b62e02e6336
On Fri, Jul 19, 2024 at 02:33:47PM +0100, Jonathan Cameron wrote:
> On Tue, 16 Jul 2024 14:13:29 +0300
> Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Hi,
> >
> > Following the discussion about handling of CXL fixed memo
On Fri, Jul 19, 2024 at 07:07:12PM +0100, Jonathan Cameron wrote:
> On Tue, 16 Jul 2024 14:13:44 +0300
> Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Introduce numa_memblks_init() and move some code around to avoid several
> >
On Fri, Jul 19, 2024 at 07:16:47PM +0100, Jonathan Cameron wrote:
> On Tue, 16 Jul 2024 14:13:41 +0300
> Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Move code dealing with numa_memblks from arch/x86 to mm/ and add Kconfig
> >
On Fri, Jul 19, 2024 at 05:28:49PM +0100, Jonathan Cameron wrote:
> On Tue, 16 Jul 2024 14:13:35 +0300
> Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Allocation of numa_distance uses memblock_phys_alloc_range() to limit
> >
On Fri, Jul 19, 2024 at 03:38:52PM +0100, Jonathan Cameron wrote:
> On Wed, 17 Jul 2024 16:32:59 +0200
> David Hildenbrand wrote:
>
> > On 16.07.24 13:13, Mike Rapoport wrote:
> > > From: "Mike Rapoport (Microsoft)"
> > >
> > > sgi-ip27 is
On Fri, Jul 19, 2024 at 07:07:12PM +0100, Jonathan Cameron wrote:
> On Tue, 16 Jul 2024 14:13:44 +0300
> Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Introduce numa_memblks_init() and move some code around to avoid several
> >
On Fri, Jul 19, 2024 at 06:48:42PM +0100, Jonathan Cameron wrote:
> On Tue, 16 Jul 2024 14:13:42 +0300
> Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Move code dealing with numa_distance array from arch/x86 to
> > mm/numa_m
On Fri, Jul 19, 2024 at 12:03:11PM -0400, Zi Yan wrote:
> On 16 Jul 2024, at 7:13, Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Move numa_emulation codfrom arch/x86 to mm/numa_emulation.c
> >
> > This code will be later reus
On Wed, Jul 17, 2024 at 04:42:48PM +0200, David Hildenbrand wrote:
> On 16.07.24 13:13, Mike Rapoport wrote:
> > From: "Mike Rapoport (Microsoft)"
> >
> > Architectures that support NUMA duplicate the code that allocates
> > NODE_DATA on the node-local memor
itialize */
+ pr_info("NODE_DATA(%d) allocated [mem %#010Lx-%#010Lx]\n", nid,
+ nd_pa, nd_pa + nd_size - 1);
+ tnid = early_pfn_to_nid(nd_pa >> PAGE_SHIFT);
+ if (tnid != nid)
+ pr_info("NODE_DATA(%d) on node %d\n", nid, tnid);
+
+ node_data[nid] = nd;
+ memset(NODE_DATA(nid), 0, sizeof(pg_data_t));
+}
I might have missed some architecture except x86 that calls
node_set_online() in its alloc_node_data(), but the intention was to leave
that call outside the alloc and explicitly add it after the call to
alloc_node_data() if needed like in x86.
> --
> Cheers,
>
> David / dhildenb
>
>
--
Sincerely yours,
Mike.
On Thu, Jul 18, 2024 at 04:46:17PM -0500, Samuel Holland wrote:
> On 2024-07-16 6:13 AM, Mike Rapoport wrote:
> > From: "Mike Rapoport (Microsoft)"
> >
> > Move code dealing with numa_distance array from arch/x86 to
> > mm/numa_memblks.c
> >
>
On Wed, Jul 17, 2024 at 04:42:48PM +0200, David Hildenbrand wrote:
> On 16.07.24 13:13, Mike Rapoport wrote:
> > From: "Mike Rapoport (Microsoft)"
> >
> > Architectures that support NUMA duplicate the code that allocates
> > NODE_DATA on the node-local memor
From: "Mike Rapoport (Microsoft)"
The x86 implementation of range-to-target_node lookup (i.e.
phys_to_target_node() and memory_add_physaddr_to_nid()) relies on
numa_memblks.
Since numa_memblks are now part of the generic code, move these
functions from x86 to mm/numa_memblks.c
From: "Mike Rapoport (Microsoft)"
Until now arch_numa was directly translating firmware NUMA information
to memblock.
Using numa_memblks as an intermediate step has a few advantages:
* alignment with more battle tested x86 implementation
* availability of NUMA emulation
* mainta
From: "Mike Rapoport (Microsoft)"
Introduce numa_memblks_init() and move some code around to avoid several
global variables in numa_memblks.
Signed-off-by: Mike Rapoport (Microsoft)
---
arch/x86/mm/numa.c | 53 -
include/linux/numa_memblks.h | 9
From: "Mike Rapoport (Microsoft)"
Move numa_emulation codfrom arch/x86 to mm/numa_emulation.c
This code will be later reused by arch_numa.
No functional changes.
Signed-off-by: Mike Rapoport (Microsoft)
---
arch/x86/Kconfig | 8
arch/x86/include/asm/nu
From: "Mike Rapoport (Microsoft)"
Move code dealing with numa_distance array from arch/x86 to
mm/numa_memblks.c
This code will be later reused by arch_numa.
No functional changes.
Signed-off-by: Mike Rapoport (Microsoft)
---
arch/x86/mm/numa.c
From: "Mike Rapoport (Microsoft)"
Move code dealing with numa_memblks from arch/x86 to mm/ and add Kconfig
options to let x86 select it in its Kconfig.
This code will be later reused by arch_numa.
No functional changes.
Signed-off-by: Mike Rapoport (Microsoft)
---
arch/x
From: "Mike Rapoport (Microsoft)"
CPU id cannot be negative.
Making it unsigned also aligns with declarations in
include/asm-generic/numa.h used by arm64 and riscv and allows sharing
numa emulation code with these architectures.
Signed-off-by: Mike Rapoport (Microsoft)
---
arch/x
From: "Mike Rapoport (Microsoft)"
This is required to make numa emulation code architecture independent s
that it can be moved to generic code in following commits.
Signed-off-by: Mike Rapoport (Microsoft)
---
arch/x86/include/asm/numa.h | 1 +
arch/x86/mm/numa.c | 5 +
From: "Mike Rapoport (Microsoft)"
This is required to make numa emulation code architecture independent so
that it can be moved to generic code in following commits.
Signed-off-by: Mike Rapoport (Microsoft)
---
arch/x86/include/asm/numa.h | 2 ++
arch/x86/mm/numa.c
From: "Mike Rapoport (Microsoft)"
By the time numa_emulation() is called, all physical memory is already
mapped in the direct map and there is no need to define limits for
memblock allocation.
Replace memblock_phys_alloc_range() with memblock_alloc().
Signed-off-by: Mike Rapoport
From: "Mike Rapoport (Microsoft)"
The definitions of FAKE_NODE_MIN_SIZE and FAKE_NODE_MIN_HASH_MASK are
only used by numa emulation code, make them local to
arch/x86/mm/numa_emulation.c
Signed-off-by: Mike Rapoport (Microsoft)
---
arch/x86/include/asm/numa.h | 2 --
a
From: "Mike Rapoport (Microsoft)"
Allocation of numa_distance uses memblock_phys_alloc_range() to limit
allocation to be below the last mapped page.
But NUMA initializaition runs after the direct map is populated and
there is also code in setup_arch() that adjusts memblock limit to
r
From: "Mike Rapoport (Microsoft)"
Architectures that support NUMA duplicate the code that allocates
NODE_DATA on the node-local memory with slight variations in reporting
of the addresses where the memory was allocated.
Use x86 version as the basis for the generic alloc_node_data() fu
From: "Mike Rapoport (Microsoft)"
Every architecture that supports NUMA defines node_data in the same way:
struct pglist_data *node_data[MAX_NUMNODES];
No reason to keep multiple copies of this definition and its forward
declarations, especially when such forward declarat
From: "Mike Rapoport (Microsoft)"
Make definition of node_data match other architectures.
This will allow pulling declaration of node_data to the generic mm code in
the following commit.
Signed-off-by: Mike Rapoport (Microsoft)
---
arch/mips/include/asm/mach-loongson64/mmzone.h | 4
From: "Mike Rapoport (Microsoft)"
sgi-ip27 is the only system that defines NODE_DATA() differently than
the rest of NUMA machines.
Add node_data array of struct pglist pointers that will point to
__node_data[node]->pglist and redefine NODE_DATA() to use node_data
array.
This will
From: "Mike Rapoport (Microsoft)"
The stub functions in kernel/numa.c belong to mm/ rather than to kernel/
Signed-off-by: Mike Rapoport (Microsoft)
---
kernel/Makefile | 1 -
mm/Makefile | 1 +
{kernel => mm}/numa.c | 0
3 files changed, 1 insertion(+), 1 deleti
From: "Mike Rapoport (Microsoft)"
Hi,
Following the discussion about handling of CXL fixed memory windows on
arm64 [1] I decided to bite the bullet and move numa_memblks from x86 to
the generic code so they will be available on arm64/riscv and maybe on
loongarch sometime later.
Whil
From: Mike Rapoport (IBM)
On Thu, 13 Jun 2024 11:55:06 -0400, Steven Rostedt wrote:
> Reserve unspecified location of physical memory from kernel command line
>
> Background:
>
> In ChromeOS, we have 1 MB of pstore ramoops reserved so that we can extract
> dmesg out
physical addresses.
--
Sincerely yours,
Mike.
+
> > > + reserved_mem_add(start, size, name);
> > > +
> > > + return 0;
> >
> > Hi, steve, should here return 1 ? Other __setup functions
> > return 1 when it success.
>
> Ug, you're correct.
>
> Mike, want me to send a v7?
I can fix it up while applying.
> -- Steve
--
Sincerely yours,
Mike.
This is embarrassing, but these patches were from a wrong branch :(
Please ignore.
On Sun, May 05, 2024 at 05:25:43PM +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> Hi,
>
> The patches are also available in git:
> https://git.kernel.org/pub/scm/lin
From: "Mike Rapoport (IBM)"
BPF just-in-time compiler depended on CONFIG_MODULES because it used
module_alloc() to allocate memory for the generated code.
Since code allocations are now implemented with execmem, drop dependency of
CONFIG_BPF_JIT on CONFIG_MODULES and make
From: "Mike Rapoport (IBM)"
kprobes depended on CONFIG_MODULES because it has to allocate memory for
code.
Since code allocations are now implemented with execmem, kprobes can be
enabled in non-modular kernels.
Add #ifdef CONFIG_MODULE guards for the code dealing with kprobes insi
From: "Mike Rapoport (IBM)"
There are places where CONFIG_MODULES guards the code that depends on
memory allocation being done with module_alloc().
Replace CONFIG_MODULES with CONFIG_EXECMEM in such places.
Signed-off-by: Mike Rapoport (IBM)
---
arch/powerpc/Kconfig
From: "Mike Rapoport (IBM)"
Dynamic ftrace must allocate memory for code and this was impossible
without CONFIG_MODULES.
With execmem separated from the modules code, execmem_text_alloc() is
available regardless of CONFIG_MODULES.
Remove dependency of dynamic ftrace on CONFIG_MODULE
From: "Mike Rapoport (IBM)"
execmem does not depend on modules, on the contrary modules use
execmem.
To make execmem available when CONFIG_MODULES=n, for instance for
kprobes, split execmem_params initialization out from
arch/*/kernel/module.c and compile it when CONFIG_EXECMEM=y
Sig
From: "Mike Rapoport (IBM)"
powerpc overrides kprobes::alloc_insn_page() to remove writable
permissions when STRICT_MODULE_RWX is on.
Add definition of EXECMEM_KRPOBES to execmem_params to allow using the
generic kprobes::alloc_insn_page() with the desired permissions.
As po
From: "Mike Rapoport (IBM)"
The memory allocations for kprobes and BPF on arm64 can be placed
anywhere in vmalloc address space and currently this is implemented with
overrides of alloc_insn_page() and bpf_jit_alloc_exec() in arm64.
Define EXECMEM_KPROBES and EXECMEM_BPF range
From: "Mike Rapoport (IBM)"
The memory allocations for kprobes and BPF on RISC-V are not placed in
the modules area and these custom allocations are implemented with
overrides of alloc_insn_page() and bpf_jit_alloc_exec().
Define MODULES_VADDR and MODULES_END as VMALLOC_START and V
From: "Mike Rapoport (IBM)"
Extend execmem parameters to accommodate more complex overrides of
module_alloc() by architectures.
This includes specification of a fallback range required by arm, arm64
and powerpc, EXECMEM_MODULE_DATA type required by powerpc, support for
allocatio
From: "Mike Rapoport (IBM)"
Several architectures override module_alloc() only to define address
range for code allocations different than VMALLOC address space.
Provide a generic implementation in execmem that uses the parameters for
address space ranges, required alignmen
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 BPF to modules and
puts the burden of code allocat
From: "Mike Rapoport (IBM)"
Move the logic related to the memory allocation and freeing into
module_memory_alloc() and module_memory_free().
Signed-off-by: Mike Rapoport (IBM)
Reviewed-by: Philippe Mathieu-Daudé
---
kernel/module/main.c | 64 +++--
From: "Mike Rapoport (IBM)"
Define MODULES_VADDR and MODULES_END as VMALLOC_START and VMALLOC_END
for 32-bit and reduce module_alloc() to
__vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END, ...)
as with the new defines the allocations becomes identical for both 32
a
From: "Mike Rapoport (IBM)"
nios2 uses kmalloc() to implement module_alloc() because CALL26/PCREL26
cannot reach all of vmalloc address space.
Define module space as 32MiB below the kernel base and switch nios2 to
use vmalloc for module allocations.
Suggested-by: Thomas Gleixner
From: "Mike Rapoport (IBM)"
and MODULE_END to MODULES_END to match other architectures that define
custom address space for modules.
Signed-off-by: Mike Rapoport (IBM)
---
arch/mips/include/asm/pgtable-64.h | 4 ++--
arch/mips/kernel/module.c | 4 ++--
arch/mips/
From: "Mike Rapoport (IBM)"
Since commit f6f37d9320a1 ("arm64: select KASAN_VMALLOC for SW/HW_TAGS
modes") KASAN_VMALLOC is always enabled when KASAN is on. This means
that allocations in module_alloc() will be tracked by KASAN protection
for vmalloc() and that kasan_alloc_
From: "Mike Rapoport (IBM)"
Hi,
The patches are also available in git:
https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git/log/?h=execmem/v8
v8:
* fix intialization of default_execmem_info
v7: https://lore.kernel.org/all/20240429121620.1186447-1-r...@kernel.org
* defi
From: "Mike Rapoport (IBM)"
Signed-off-by: Mike Rapoport (IBM)
---
mm/execmem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/mm/execmem.c b/mm/execmem.c
index f6dc3fabc1ca..0c4b36bc6d10 100644
--- a/mm/execmem.c
+++ b/mm/execmem.c
@@ -118,7 +118,6 @@ static void __init __ex
From: "Mike Rapoport (IBM)"
BPF just-in-time compiler depended on CONFIG_MODULES because it used
module_alloc() to allocate memory for the generated code.
Since code allocations are now implemented with execmem, drop dependency of
CONFIG_BPF_JIT on CONFIG_MODULES and make
From: "Mike Rapoport (IBM)"
kprobes depended on CONFIG_MODULES because it has to allocate memory for
code.
Since code allocations are now implemented with execmem, kprobes can be
enabled in non-modular kernels.
Add #ifdef CONFIG_MODULE guards for the code dealing with kprobes insi
From: "Mike Rapoport (IBM)"
There are places where CONFIG_MODULES guards the code that depends on
memory allocation being done with module_alloc().
Replace CONFIG_MODULES with CONFIG_EXECMEM in such places.
Signed-off-by: Mike Rapoport (IBM)
---
arch/powerpc/Kconfig
From: "Mike Rapoport (IBM)"
Dynamic ftrace must allocate memory for code and this was impossible
without CONFIG_MODULES.
With execmem separated from the modules code, execmem_text_alloc() is
available regardless of CONFIG_MODULES.
Remove dependency of dynamic ftrace on CONFIG_MODULE
From: "Mike Rapoport (IBM)"
execmem does not depend on modules, on the contrary modules use
execmem.
To make execmem available when CONFIG_MODULES=n, for instance for
kprobes, split execmem_params initialization out from
arch/*/kernel/module.c and compile it when CONFIG_EXECMEM=y
Sig
From: "Mike Rapoport (IBM)"
powerpc overrides kprobes::alloc_insn_page() to remove writable
permissions when STRICT_MODULE_RWX is on.
Add definition of EXECMEM_KRPOBES to execmem_params to allow using the
generic kprobes::alloc_insn_page() with the desired permissions.
As po
From: "Mike Rapoport (IBM)"
The memory allocations for kprobes and BPF on arm64 can be placed
anywhere in vmalloc address space and currently this is implemented with
overrides of alloc_insn_page() and bpf_jit_alloc_exec() in arm64.
Define EXECMEM_KPROBES and EXECMEM_BPF range
From: "Mike Rapoport (IBM)"
The memory allocations for kprobes and BPF on RISC-V are not placed in
the modules area and these custom allocations are implemented with
overrides of alloc_insn_page() and bpf_jit_alloc_exec().
Define MODULES_VADDR and MODULES_END as VMALLOC_START and V
From: "Mike Rapoport (IBM)"
Extend execmem parameters to accommodate more complex overrides of
module_alloc() by architectures.
This includes specification of a fallback range required by arm, arm64
and powerpc, EXECMEM_MODULE_DATA type required by powerpc, support for
allocatio
From: "Mike Rapoport (IBM)"
Several architectures override module_alloc() only to define address
range for code allocations different than VMALLOC address space.
Provide a generic implementation in execmem that uses the parameters for
address space ranges, required alignmen
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 BPF to modules and
puts the burden of code allocat
From: "Mike Rapoport (IBM)"
Move the logic related to the memory allocation and freeing into
module_memory_alloc() and module_memory_free().
Signed-off-by: Mike Rapoport (IBM)
Reviewed-by: Philippe Mathieu-Daudé
---
kernel/module/main.c | 64 +++--
From: "Mike Rapoport (IBM)"
Define MODULES_VADDR and MODULES_END as VMALLOC_START and VMALLOC_END
for 32-bit and reduce module_alloc() to
__vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END, ...)
as with the new defines the allocations becomes identical for both 32
a
From: "Mike Rapoport (IBM)"
nios2 uses kmalloc() to implement module_alloc() because CALL26/PCREL26
cannot reach all of vmalloc address space.
Define module space as 32MiB below the kernel base and switch nios2 to
use vmalloc for module allocations.
Suggested-by: Thomas Gleixner
1 - 100 of 4125 matches
Mail list logo
