* [PATCH v3] uprobes: Use flexible array for xol_area bitmap
@ 2026-11-13 5:29 Rosen Penev
2026-11-13 11:05 ` Oleg Nesterov
0 siblings, 1 reply; 2+ messages in thread
From: Rosen Penev @ 2026-11-13 5:29 UTC (permalink / raw)
To: Masami Hiramatsu, Oleg Nesterov, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim
Cc: Mark Rutland, Alexander Shishkin, Jiri Olsa, Ian Rogers,
Adrian Hunter, James Clark, linux-kernel, linux-trace-kernel,
linux-perf-users
The XOL slot bitmap has the same lifetime as struct xol_area, but it
is currently allocated separately. That adds another allocation
failure path and a matching cleanup branch without buying any extra
flexibility.
Store the bitmap as a regular array and allocate it together
with the xol_area. The bitmap remains zero-initialized, while the
allocation and error handling become simpler.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
v3: use normal array
v2: add Acked-by. remove Assisted-by
kernel/events/uprobes.c | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index caf444762a27..c5c90b53d4cc 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -108,7 +108,6 @@ static LIST_HEAD(delayed_uprobe_list);
*/
struct xol_area {
wait_queue_head_t wq; /* if all slots are busy */
- unsigned long *bitmap; /* 0 = free slot */
struct page *page;
/*
@@ -117,6 +116,7 @@ struct xol_area {
* the vma go away, and we must handle that reasonably gracefully.
*/
unsigned long vaddr; /* Page(s) of instruction slots */
+ unsigned long bitmap[BITS_TO_LONGS(UINSNS_PER_PAGE)]; /* 0 = free slot */
};
static void uprobe_warn(struct task_struct *t, const char *msg)
@@ -1762,14 +1762,9 @@ static struct xol_area *__create_xol_area(unsigned long vaddr)
if (unlikely(!area))
goto out;
- area->bitmap = kcalloc(BITS_TO_LONGS(UINSNS_PER_PAGE), sizeof(long),
- GFP_KERNEL);
- if (!area->bitmap)
- goto free_area;
-
area->page = alloc_page(GFP_HIGHUSER | __GFP_ZERO);
if (!area->page)
- goto free_bitmap;
+ goto free_area;
area->vaddr = vaddr;
init_waitqueue_head(&area->wq);
@@ -1782,8 +1777,6 @@ static struct xol_area *__create_xol_area(unsigned long vaddr)
return area;
__free_page(area->page);
- free_bitmap:
- kfree(area->bitmap);
free_area:
kfree(area);
out:
@@ -1824,7 +1817,6 @@ void uprobe_clear_state(struct mm_struct *mm)
return;
put_page(area->page);
- kfree(area->bitmap);
kfree(area);
}
--
2.56.1
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH v3] uprobes: Use flexible array for xol_area bitmap
2026-11-13 5:29 [PATCH v3] uprobes: Use flexible array for xol_area bitmap Rosen Penev
@ 2026-11-13 11:05 ` Oleg Nesterov
0 siblings, 0 replies; 2+ messages in thread
From: Oleg Nesterov @ 2026-11-13 11:05 UTC (permalink / raw)
To: Rosen Penev
Cc: Masami Hiramatsu, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, linux-kernel, linux-trace-kernel, linux-perf-users
On 11/12, Rosen Penev wrote:
>
> The XOL slot bitmap has the same lifetime as struct xol_area, but it
> is currently allocated separately. That adds another allocation
> failure path and a matching cleanup branch without buying any extra
> flexibility.
>
> Store the bitmap as a regular array and allocate it together
> with the xol_area. The bitmap remains zero-initialized, while the
> allocation and error handling become simpler.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Acked-by: Oleg Nesterov <oleg@redhat.com>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-11-13 11:05 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-13 5:29 [PATCH v3] uprobes: Use flexible array for xol_area bitmap Rosen Penev
2026-11-13 11:05 ` Oleg Nesterov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).