* Re: [PATCH] fsl-edma: tracing: no ptr dereference during log output
From: Steven Rostedt @ 2026-06-30 20:44 UTC (permalink / raw)
To: Martin Kaiser
Cc: Frank Li, Vinod Koul, Masami Hiramatsu, linux-kernel,
linux-trace-kernel, imx, dmaengine
In-Reply-To: <20260630160544.4211ae88@gandalf.local.home>
On Tue, 30 Jun 2026 16:05:44 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> > TP_printk("offset %08x: value %08x",
> > - (u32)(__entry->addr - __entry->edma->membase), __entry->value)
> > + (u32)(__entry->addr - __entry->membase), __entry->value)
>
> Hmm, I think I should update the TP_printk checks at boot to cover this too.
I created the following to catch this:
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index c46e623e7e0d..2da3c02bea54 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -400,10 +400,37 @@ static bool process_string(const char *fmt, int len, struct trace_event_call *ca
return true;
}
+static void test_double_dereference(const char *str, int len,
+ struct trace_event_call *call)
+{
+ const char *ptr;
+ const char *end = str + len;
+
+ ptr = strstr(str, "REC->");
+
+ while (ptr && ptr < end) {
+
+ ptr += 5;
+ for (; ptr < end; ptr++) {
+ if (ptr[0] == '-' && ptr[1] == '>') {
+ WARN_ONCE(1, "Event %s has double dereference in TP_printk: %*s\n",
+ trace_event_name(call), len, str);
+ return;
+ }
+ if (!isalnum(*ptr) && *ptr != '_')
+ break;
+ }
+
+ ptr = strstr(ptr, "REC->");
+ }
+}
+
static void handle_dereference_arg(const char *arg_str, u64 string_flags, int len,
u64 *dereference_flags, int arg,
struct trace_event_call *call)
{
+ test_double_dereference(arg_str, len, call);
+
if (string_flags & (1ULL << arg)) {
if (process_string(arg_str, len, call))
*dereference_flags &= ~(1ULL << arg);
Enabled this event to see if it would trigger, but instead it found *another* BUG!
[ 0.719012][ T0] ------------[ cut here ]------------
[ 0.720850][ T0] Event ufshcd_exception_event has double dereference in TP_printk: dev_name(REC->hba->dev), REC->status
[ 0.724646][ T0] WARNING: kernel/trace/trace_events.c:416 at handle_dereference_arg+0x342/0x5a0, CPU#0: swapper/0/0
I'll go make a fix for the ufshcd_exception_event event, and then I will
definitely add this patch to make sure this bug isn't in other places.
-- Steve
^ permalink raw reply related
* Re: [PATCH] ring-buffer: serialize read-page order with subbuffer resize
From: Yousef Alhouseen @ 2026-06-30 20:38 UTC (permalink / raw)
To: rostedt
Cc: mhiramat, mathieu.desnoyers, petr.pavlu, linux-trace-kernel,
linux-kernel
In-Reply-To: <20260630101425.2f7cfbea@robin>
Thanks, Steve. Moving the order reads under the existing per-CPU locks
is much tighter and avoids extending the allocation critical path.
I’ll compile and test this direction and send v2.
On Tue, 30 Jun 2026 10:14:25 -0400, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Sun, 28 Jun 2026 02:46:53 +0200
> Yousef Alhouseen <alhouseenyousef@gmail.com> wrote:
>
> > ring_buffer_read_page() checks that its spare page has the current
> > subbuffer order before taking cpu_buffer->reader_lock. A concurrent
> > ring_buffer_subbuf_order_set() can change the order and replace the
> > reader page after that check. The reader then copies a larger subbuffer
> > into the old allocation, causing an out-of-bounds write.
> >
> > Keep spare-page allocation and release under buffer->mutex, which already
> > serializes order changes. Move the read-side order check under
> > reader_lock, the lock used by resize when replacing per-CPU pages.
> >
> > Fixes: f9b94daa542a ("ring-buffer: Set new size of the ring buffer sub page")
> > Reported-by: syzbot+2dd9d02f60775ce5c1fb@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=2dd9d02f60775ce5c1fb
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
> > ---
> > kernel/trace/ring_buffer.c | 9 ++++++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> > index 56a328e94395..eed5d7cffdee 100644
> > --- a/kernel/trace/ring_buffer.c
> > +++ b/kernel/trace/ring_buffer.c
> > @@ -6950,6 +6950,8 @@ ring_buffer_alloc_read_page(struct trace_buffer *buffer, int cpu)
> > if (!cpumask_test_cpu(cpu, buffer->cpumask))
> > return ERR_PTR(-ENODEV);
> >
> > + guard(mutex)(&buffer->mutex);
> > +
> > bpage = kzalloc_obj(*bpage);
>
> First, do not grab locks around allocations unless the are really needed.
> This is bad practice, as it extends the critical section and may even add
> the allocation locking to the lock chain.
>
> That said, just moving things around the current locks should work.
>
> Like this (not compiled nor tested):
>
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 56a328e94395..8352f935a223 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -6954,11 +6954,11 @@ ring_buffer_alloc_read_page(struct trace_buffer *buffer, int cpu)
> if (!bpage)
> return ERR_PTR(-ENOMEM);
>
> - bpage->order = buffer->subbuf_order;
> cpu_buffer = buffer->buffers[cpu];
> local_irq_save(flags);
> arch_spin_lock(&cpu_buffer->lock);
>
> + bpage->order = buffer->subbuf_order;
> if (cpu_buffer->free_page) {
> bpage->data = cpu_buffer->free_page;
> cpu_buffer->free_page = NULL;
> @@ -7007,13 +7007,13 @@ void ring_buffer_free_read_page(struct trace_buffer *buffer, int cpu,
> * is different from the subbuffer order of the buffer -
> * we can't reuse it
> */
> - if (page_ref_count(page) > 1 || data_page->order != buffer->subbuf_order)
> + if (page_ref_count(page) > 1)
> goto out;
>
> local_irq_save(flags);
> arch_spin_lock(&cpu_buffer->lock);
>
> - if (!cpu_buffer->free_page) {
> + if (!cpu_buffer->free_page && data_page->order == buffer->subbuf_order)
> cpu_buffer->free_page = dpage;
> dpage = NULL;
> }
> @@ -7091,15 +7091,15 @@ int ring_buffer_read_page(struct trace_buffer *buffer,
> if (!data_page || !data_page->data)
> return -1;
>
> - if (data_page->order != buffer->subbuf_order)
> - return -1;
> -
> dpage = data_page->data;
> if (!dpage)
> return -1;
>
> guard(raw_spinlock_irqsave)(&cpu_buffer->reader_lock);
>
> + if (data_page->order != buffer->subbuf_order)
> + return -1;
> +
> reader = rb_get_reader_page(cpu_buffer);
> if (!reader)
> return -1;
>
> -- Steve
^ permalink raw reply
* Re: [PATCH] fsl-edma: tracing: no ptr dereference during log output
From: Frank Li @ 2026-06-30 20:36 UTC (permalink / raw)
To: Martin Kaiser
Cc: Frank Li, Vinod Koul, Steven Rostedt, Masami Hiramatsu,
linux-kernel, linux-trace-kernel, imx, dmaengine
In-Reply-To: <20260630200022.1826420-1-martin@kaiser.cx>
On Tue, Jun 30, 2026 at 10:00:11PM +0200, Martin Kaiser wrote:
subject need a tag to identify subsystem
dmaengine: fsl-edma: tracing: remove ptr dereference during log output
>
> The fsl edma events store a pointer to a struct fsl_edma_engine in the
> ringbuffer and dereference it when a log entry is printed. At this time,
> the pointer may no longer be valid.
>
> Event injection can be used to trigger a crash:
>
> $ cd /sys/kernel/tracing
> $ echo 'value = 0' > events/fsl_edma/edma_writeb/inject
> $ cat trace
>
> The log output needs only edma->membase. Add a membase field at the end
> of the event and use the new field for log output. Keep the existing
> fields for backward compatibility.
thanks you for your fix.
Frank
>
> Fixes: 11102d0c343b ("dmaengine: fsl-edma: add trace event support")
> Signed-off-by: Martin Kaiser <martin@kaiser.cx>
> ---
> drivers/dma/fsl-edma-trace.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/fsl-edma-trace.h b/drivers/dma/fsl-edma-trace.h
> index d3541301a247..45d964a3726d 100644
> --- a/drivers/dma/fsl-edma-trace.h
> +++ b/drivers/dma/fsl-edma-trace.h
> @@ -19,14 +19,16 @@ DECLARE_EVENT_CLASS(edma_log_io,
> __field(struct fsl_edma_engine *, edma)
> __field(void __iomem *, addr)
> __field(u32, value)
> + __field(void __iomem *, membase)
> ),
> TP_fast_assign(
> __entry->edma = edma;
> __entry->addr = addr;
> __entry->value = value;
> + __entry->membase = edma->membase;
> ),
> TP_printk("offset %08x: value %08x",
> - (u32)(__entry->addr - __entry->edma->membase), __entry->value)
> + (u32)(__entry->addr - __entry->membase), __entry->value)
> );
>
> DEFINE_EVENT(edma_log_io, edma_readl,
> --
> 2.43.7
>
>
^ permalink raw reply
* Re: [PATCH] fsl-edma: tracing: no ptr dereference during log output
From: Steven Rostedt @ 2026-06-30 20:05 UTC (permalink / raw)
To: Martin Kaiser
Cc: Frank Li, Vinod Koul, Masami Hiramatsu, linux-kernel,
linux-trace-kernel, imx, dmaengine
In-Reply-To: <20260630200022.1826420-1-martin@kaiser.cx>
On Tue, 30 Jun 2026 22:00:11 +0200
Martin Kaiser <martin@kaiser.cx> wrote:
> The fsl edma events store a pointer to a struct fsl_edma_engine in the
> ringbuffer and dereference it when a log entry is printed. At this time,
> the pointer may no longer be valid.
Nice catch.
>
> Event injection can be used to trigger a crash:
>
> $ cd /sys/kernel/tracing
> $ echo 'value = 0' > events/fsl_edma/edma_writeb/inject
> $ cat trace
>
> The log output needs only edma->membase. Add a membase field at the end
> of the event and use the new field for log output. Keep the existing
> fields for backward compatibility.
>
Cc: stable@vger.kernel.org
> Fixes: 11102d0c343b ("dmaengine: fsl-edma: add trace event support")
> Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
> ---
> drivers/dma/fsl-edma-trace.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/fsl-edma-trace.h b/drivers/dma/fsl-edma-trace.h
> index d3541301a247..45d964a3726d 100644
> --- a/drivers/dma/fsl-edma-trace.h
> +++ b/drivers/dma/fsl-edma-trace.h
> @@ -19,14 +19,16 @@ DECLARE_EVENT_CLASS(edma_log_io,
> __field(struct fsl_edma_engine *, edma)
> __field(void __iomem *, addr)
> __field(u32, value)
> + __field(void __iomem *, membase)
> ),
> TP_fast_assign(
> __entry->edma = edma;
> __entry->addr = addr;
> __entry->value = value;
> + __entry->membase = edma->membase;
> ),
> TP_printk("offset %08x: value %08x",
> - (u32)(__entry->addr - __entry->edma->membase), __entry->value)
> + (u32)(__entry->addr - __entry->membase), __entry->value)
Hmm, I think I should update the TP_printk checks at boot to cover this too.
-- Steve
> );
>
> DEFINE_EVENT(edma_log_io, edma_readl,
^ permalink raw reply
* [PATCH] fsl-edma: tracing: no ptr dereference during log output
From: Martin Kaiser @ 2026-06-30 20:00 UTC (permalink / raw)
To: Frank Li, Vinod Koul
Cc: Steven Rostedt, Masami Hiramatsu, linux-kernel,
linux-trace-kernel, imx, dmaengine, Martin Kaiser
The fsl edma events store a pointer to a struct fsl_edma_engine in the
ringbuffer and dereference it when a log entry is printed. At this time,
the pointer may no longer be valid.
Event injection can be used to trigger a crash:
$ cd /sys/kernel/tracing
$ echo 'value = 0' > events/fsl_edma/edma_writeb/inject
$ cat trace
The log output needs only edma->membase. Add a membase field at the end
of the event and use the new field for log output. Keep the existing
fields for backward compatibility.
Fixes: 11102d0c343b ("dmaengine: fsl-edma: add trace event support")
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
---
drivers/dma/fsl-edma-trace.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/fsl-edma-trace.h b/drivers/dma/fsl-edma-trace.h
index d3541301a247..45d964a3726d 100644
--- a/drivers/dma/fsl-edma-trace.h
+++ b/drivers/dma/fsl-edma-trace.h
@@ -19,14 +19,16 @@ DECLARE_EVENT_CLASS(edma_log_io,
__field(struct fsl_edma_engine *, edma)
__field(void __iomem *, addr)
__field(u32, value)
+ __field(void __iomem *, membase)
),
TP_fast_assign(
__entry->edma = edma;
__entry->addr = addr;
__entry->value = value;
+ __entry->membase = edma->membase;
),
TP_printk("offset %08x: value %08x",
- (u32)(__entry->addr - __entry->edma->membase), __entry->value)
+ (u32)(__entry->addr - __entry->membase), __entry->value)
);
DEFINE_EVENT(edma_log_io, edma_readl,
--
2.43.7
^ permalink raw reply related
* [PATCH] riscv: probes: save original sp in rethook trampoline
From: Martin Kaiser @ 2026-06-30 19:40 UTC (permalink / raw)
To: Paul Walmsley, Palmer Dabbelt, Albert Ou
Cc: Steven Rostedt, Masami Hiramatsu, linux-riscv, linux-kernel,
linux-trace-kernel, Martin Kaiser
Reading a word from the stack in a kretprobe crashes a risc-v kernel.
$ cd /sys/kernel/tracing/
$ echo 'r n_tty_write $stack0' > dynamic_events
$ echo 1 > events/kprobes/enable
Unable to handle kernel paging request at virtual address 0000000200000128
...
[<ffffffff80016d16>] regs_get_kernel_stack_nth+0x26/0x38
[<ffffffff80177196>] process_fetch_insn+0x3ee/0x760
[<ffffffff80177836>] kretprobe_trace_func+0x116/0x1f0
[<ffffffff8017795a>] kretprobe_dispatcher+0x4a/0x58
[<ffffffff8013572e>] kretprobe_rethook_handler+0x5e/0x90
[<ffffffff80180838>] rethook_trampoline_handler+0x70/0x108
[<ffffffff8001ba32>] arch_rethook_trampoline_callback+0x12/0x1c
[<ffffffff8001ba84>] arch_rethook_trampoline+0x48/0x94
[<ffffffff8067872a>] tty_write+0x1a/0x30
In regs_get_kernel_stack_nth, regs->sp contains an arbitrary value.
arch_rethook_trampoline saves the registers from the probed function in a
struct pt_regs. sp is not saved. Instead, sp is decremented for
arch_rethook_trampoline's local stack.
Fix this crash and save the original sp along with the other registers.
Use a0 as a temporary register, it is overwritten anyway.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
---
arch/riscv/kernel/probes/rethook_trampoline.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/riscv/kernel/probes/rethook_trampoline.S b/arch/riscv/kernel/probes/rethook_trampoline.S
index f2cd83d9b0f0..c3aa8d8cf5af 100644
--- a/arch/riscv/kernel/probes/rethook_trampoline.S
+++ b/arch/riscv/kernel/probes/rethook_trampoline.S
@@ -41,6 +41,9 @@
REG_S x29, PT_T4(sp)
REG_S x30, PT_T5(sp)
REG_S x31, PT_T6(sp)
+ /* save original sp */
+ addi a0, sp, PT_SIZE_ON_STACK
+ REG_S a0, PT_SP(sp)
.endm
.macro restore_all_base_regs
--
2.43.7
^ permalink raw reply related
* Re: [PATCH 2/2] tracing: Keep pid and comm[] in the same structure
From: Steven Rostedt @ 2026-06-30 19:03 UTC (permalink / raw)
To: David Laight
Cc: Masami Hiramatsu, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel, Michal Koutný
In-Reply-To: <20260630110156.5314e2e6@pumpkin>
On Tue, 30 Jun 2026 11:01:56 +0100
David Laight <david.laight.linux@gmail.com> wrote:
> > It's been a long time since I worked on this, but IIRC, it was to keep
> > the pressure down on the TLB when tracing. It updates at every
> > sched_switch that has a trace event occurring so, I likely used normal
> > pages which are part of the huge pages the kernel sets up and doesn't
> > affect the TLB as much. vmalloc does have impact on the TLB pressure,
> > and tracing should always try to avoid that.
>
> Isn't this a cache so that the pid numbers can be converted to strings
> when the trace is read out after the actual process has exited?
> That does mean that cache doesn't need to be updated on every trace
> request - it might be enough to just save on process exit and lookup the
> pid itself for running processes (the whole thing relies on pids not
> being reused).
Yes it's a cache but it only gets filled when needed. That is, after a
trace event occurred. Tracing is very commonly used with filtering, where
events can be seldom triggered. What is in the saved_cmdlines file should
only be tasks that were running when a trace occurred.
Now what we could do is add a flag to the task struct and only set that
when tracing happens. Only tasks that exit would be saved in this array.
The other tasks could be queried via iterating the tasks and reporting any
task with this bit set.
>
> >
> > > map_pid_to_cmdline[] is 64k*sizeof(int) so the whole structure
> > > expands to 512k with about 64k/20 (about 3200) pid entries even
> > > though the default is 128.
> >
> > That's because it is not dynamic. That array needs to be able to hold
> > most PIDs. The default is 128 but it will expand to how much it can
> > hold to allocate the full map_pid_to_cmdline. The real default for 4098
> > page sized architectures is 6552 entries.
>
> That is double my 'quick calculation' - but both are a lot of entries.
I got the number by looking at saved_cmdlines_size after boot ;-)
>
> > > AFAICT there is only one copy of the data - so it could be static.
> > > Perhaps with pointers to map_pid_cmdline[] and (after this patch)
> > > pid_comm[], both of which could be separately resized.
> >
> > map_pid_t_cmdline[] is to hold the PID_MAX_DEFAULT amount of PIDs to
> > avoid collisions. I wouldn't resize it.
>
> If comm[] is only saved on process exit you'd likely get away with far
> fewer entries - getting collisions for processes that have exited is
> rather unlikely.
> (I wonder if I could make that work.)
>
> Does that memory get allocated at boot time?
> 512k is a lot to allocated for a feature that won't usually be used.
> OTOH you won't reliably get that much contiguous memory later on.
> Deferring to a later time (maybe as late as the first tracing_on())
> might be more reasonable - but that would have to use vmalloc().
>
> I'm also not sure about the code that lets you trace from boot.
> That must be able to initialise early - but I'm not sure how early.
Well tracing can start before init, so pretty early.
-- Steve
^ permalink raw reply
* Re: [PATCH v3 2/9] rv: add generic uprobe infrastructure for RV monitors
From: Wen Yang @ 2026-06-30 18:44 UTC (permalink / raw)
To: Gabriele Monaco; +Cc: linux-trace-kernel, linux-kernel
In-Reply-To: <ebde84b7c65cd6b01a1e8d124de0b1eaf0793006.camel@redhat.com>
On 6/30/26 16:48, Gabriele Monaco wrote:
> On Mon, 2026-06-29 at 00:47 +0800, Wen Yang wrote:
>> On [2-1]~[2-5]: embedded consumer causes UAF on PREEMPT_RT
>> -----------------------------------------------------------
>>
>> The uprobe_bind selftest oopses on PREEMPT_RT(full):
>>
>> handler_chain+0xc9: mov rax, [r15+0x18] ; advance list iterator
>> RAX: 000015ec00001f28 ; garbage — &uprobe->consumers after kfree
>>
>> handler_chain() reads uc->cons_node.next after uc->handler() returns,
>> still inside rcu_read_lock_trace(). That pointer is &uprobe->consumers
>> (the list head embedded in struct uprobe), which gets freed through:
>>
>> put_uprobe()
>> -> schedule_work(uprobe_free_deferred) /* async */
>> -> call_srcu(&uretprobes_srcu, ...)
>> -> call_rcu_tasks_trace(kfree_uprobe)
>> -> kfree(uprobe)
>>
>> rv_uprobe_sync() calls uprobe_unregister_sync() which calls
>> synchronize_srcu(&uretprobes_srcu), but that only matters after the
>> kworker has submitted work to uretprobes_srcu. On a loaded PREEMPT_RT
>> box the kworker may not have run yet, so synchronize_srcu() returns
>> immediately and kfree(uprobe) races with the still-iterating
>> handler_chain():
>>
>> CPU A CPU B
>> consumer_del() → list_del_rcu rcu_read_lock_trace()
>> put_uprobe() → schedule_work uc->handler() returns
>> rv_uprobe_sync(): reading cons_node.next...
>> synchronize_srcu(&uretprobes_srcu)
>
> If CPU B is in an RCU trace read-side critical section this doesn't
> return immediately, it returns after readers are done, doesn't it?
> (well, what you really care here is the synchronize_rcu_tasks_trace()
> but we do both).
>
>> ← idle; returns immediately
>> [kworker fires later]
>> kfree(uprobe) ← frees &uprobe->consumers
>> cons_node.next = freed mem → CRASH
>>
>
> So I had a bit of a look and as far as I understand, we don't have any
> control over the uprobe allocation pattern (workqueues and whatnot) and
> we don't really care as long as we deregister it appropriately.
>
> What we do control is the uprobe_consumer, that must be freed only after
> the uprobe was synchronously deregistered, that should guarantee no
> reader is going to reference it, shouldn't it?
>
> uprobe_unregister_nosync() removes it from the cons_node list, so it's
> safe to assume any handler_chain() after the next RCU-trace grace period
> won't see it.
>
> In the sketch I sent this is happening (all kfree(b) are after
> rv_uprobe_unregister() which does the sync). What am I missing here?
>
>
> uprobe is also freed after both grace periods, so no reader should use
> that either.
>
> The situation you're seeing isn't fully clear to me, I applied my sketch
> and don't see any splat on a vng box.
>
>> With uc embedded in the binding (as [2-1] suggests), no amount of
>> delaying kfree(binding) helps: uprobe->consumers is freed by a chain we
>> don't control. The fix is to keep uc->cons_node in memory that outlives
>> the handler_chain() iteration, which means a separate allocation freed
>> only after rv_uprobe_sync():
>>
>> rv_uprobe_unregister_nosync() /* list_del_rcu + schedule_work */
>> rv_uprobe_sync() /* waits for any already-submitted
>> srcu work */
>
> We of course need to do any free after this sync, but I don't get why we
> need an additional allocation since the following are both plain
> synchronous frees, why isn't a single one (on b) enough?
>
Thank you for the patient explanation.
You are right, and v4 implements the embedded approach.
struct rv_uprobe directly embeds struct uprobe_consumer:
struct rv_uprobe {
struct uprobe_consumer uc;
struct uprobe *uprobe;
struct inode *inode;
void *priv;
int (*handler)(...);
int (*ret_handler)(...);
};
rv_uprobe_free() is gone — no allocation means no explicit free. After
rv_uprobe_unregister() (or rv_uprobe_unregister_nosync() +
rv_uprobe_sync()), the caller frees the containing struct directly. In
tlob:
rv_uprobe_unregister_nosync(&b->start_probe);
rv_uprobe_unregister_nosync(&b->stop_probe);
rv_uprobe_sync();
kfree(b); /* frees both embedded consumers */
This is the pattern from your sketch.
Regarding my earlier reply that argued for the separate allocation: I
was wrong. The key barrier is synchronize_rcu_tasks_trace() (called
first in uprobe_unregister_sync()), which waits for all
rcu_read_lock_trace() readers including handler_chain(). After it
returns, no cons_node.next read is in flight and embedding is safe.
We appreciate your thorough review. All of your comments have been
addressed in v4.
We'll run local tests for one or two days, and then it will be sent out
shortly.
--
Best wishes,
Wen
^ permalink raw reply
* [PATCH v2] lib/bootconfig: fix undefined behavior involving NULL pointer arithmetic
From: Bradley Morgan @ 2026-06-30 17:47 UTC (permalink / raw)
To: akpm, mhiramat; +Cc: linux-kernel, linux-trace-kernel, stable, Bradley Morgan
When xbc_snprint_cmdline() is called during the size-probing phase
(with buf = NULL and size = 0), the function computes the end pointer
as 'buf + size' (NULL + 0) and repeatedly advances 'buf' via 'buf += ret'.
Under the C standard, performing pointer arithmetic on a NULL pointer is
undefined behavior. While harmless inside the kernel, this code is also
compiled into the userspace host tool 'tools/bootconfig', where host
compilers with UBSan or FORTIFY_SOURCE enabled abort the build when they
detect NULL pointer arithmetic.
Fix this by guarding the pointer arithmetic so 'buf' is only advanced when
non-NULL, and track the running written length in a separate 'len' counter
for the return value (which cannot be recovered from pointer math when
'buf' is NULL). The rest() helper and snprintf call sites are unchanged.
Fixes: 51887d03aca1 ("bootconfig: init: Allow admin to use bootconfig for kernel command line")
Cc: stable@vger.kernel.org
Assisted-by: GLM:glm-5.2
Signed-off-by: Bradley Morgan <include@grrlz.net>
---
lib/bootconfig.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
Changes since v1:
- Got the big guns out! :) (see Assisted-by).
- Addressed review from Masami Hiramatsu and Breno Leitao.
diff --git a/lib/bootconfig.c b/lib/bootconfig.c
index f445b7703fdd..c913259c80ce 100644
--- a/lib/bootconfig.c
+++ b/lib/bootconfig.c
@@ -427,8 +427,9 @@ static char xbc_namebuf[XBC_KEYLEN_MAX] __initdata;
int __init xbc_snprint_cmdline(char *buf, size_t size, struct xbc_node *root)
{
struct xbc_node *knode, *vnode;
- char *end = buf + size;
+ char *end = buf ? buf + size : NULL;
const char *val, *q;
+ size_t len = 0;
int ret;
xbc_node_for_each_key_value(root, knode, val) {
@@ -442,7 +443,9 @@ int __init xbc_snprint_cmdline(char *buf, size_t size, struct xbc_node *root)
ret = snprintf(buf, rest(buf, end), "%s ", xbc_namebuf);
if (ret < 0)
return ret;
- buf += ret;
+ len += ret;
+ if (buf)
+ buf += ret;
continue;
}
xbc_array_for_each_value(vnode, val) {
@@ -456,11 +459,13 @@ int __init xbc_snprint_cmdline(char *buf, size_t size, struct xbc_node *root)
xbc_namebuf, q, val, q);
if (ret < 0)
return ret;
- buf += ret;
+ len += ret;
+ if (buf)
+ buf += ret;
}
}
- return buf - (end - size);
+ return len;
}
#undef rest
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v8 07/46] KVM: Rename memory attribute APIs to prepare for in-place gmem conversion
From: Sean Christopherson @ 2026-06-30 17:30 UTC (permalink / raw)
To: Xiaoyao Li
Cc: ackerleytng, aik, andrew.jones, binbin.wu, brauner, chao.p.peng,
david, jmattson, jthoughton, michael.roth, oupton, pankaj.gupta,
qperret, rick.p.edgecombe, rientjes, shivankg, steven.price,
tabba, willy, wyihan, yan.y.zhao, forkloop, pratyush,
suzuki.poulose, aneesh.kumar, liam, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Jonathan Corbet, Shuah Khan, Shuah Khan,
Vishal Annapurve, Andrew Morton, Chris Li, Kairui Song,
Kemeng Shi, Nhat Pham, Barry Song, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt, Kiryl Shutsemau,
Baoquan He, Jason Gunthorpe, Vlastimil Babka, kvm, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest, linux-mm,
linux-coco
In-Reply-To: <a1b06afb-af6e-4666-8c7d-990e7fa150fa@intel.com>
On Tue, Jun 30, 2026, Xiaoyao Li wrote:
> On 6/19/2026 8:31 AM, Ackerley Tng via B4 Relay wrote:
> > -bool kvm_range_has_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
> > - unsigned long mask, unsigned long attrs);
> > +bool kvm_range_has_vm_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
> > + unsigned long mask, unsigned long attrs);
> > bool kvm_arch_pre_set_memory_attributes(struct kvm *kvm,
> > struct kvm_gfn_range *range);
> > bool kvm_arch_post_set_memory_attributes(struct kvm *kvm,
>
> We have
>
> - kvm_pre_set_memory_attributes()
> - kvm_arch_pre_set_memory_attributes()
> - kvm_arch_post_set_memory_attributes()
Yeah, that's probably for the best.
> left, do they need to be renamed as well?
>
> then the interesting one is kvm_vm_set_mem_attributes(), which contains "vm"
> already while it means "vm ioctl". Do we need to rename it to
> kvm_vm_set_vm_mem_attributes()?
I say "no" on this last one, the fact that the function is scoped to a VM ioctl
is enough to communicate that it applies to per-VM attributes.
Actually, since it's a local helper, we could go with kvm_set_vm_mem_attributes()
to be consistent with the other functions. That just leaves
kvm_vm_ioctl_set_mem_attributes(), which I think it appropriately scoped.
^ permalink raw reply
* Re: [PATCH 12/30] mm/vma: clean up anon_vma_compatible()
From: Pedro Falcato @ 2026-06-30 16:36 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <5a7a07bd2a774989849b0fea84f758059ed914df.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:23PM +0100, Lorenzo Stoakes wrote:
> Break up the existing very large conditional, add comments and use
> vma_[start/end]_pgoff() to make clearer what we're doing here.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> mm/vma.c | 21 ++++++++++++++++-----
> 1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/mm/vma.c b/mm/vma.c
> index b60375c6c5c3..6296acecf3b7 100644
> --- a/mm/vma.c
> +++ b/mm/vma.c
> @@ -1967,14 +1967,25 @@ static int anon_vma_compatible(struct vm_area_struct *a, struct vm_area_struct *
> {
> vma_flags_t diff = vma_flags_diff_pair(&a->flags, &b->flags);
>
> + /* Ignore flags that mprotect() can change. */
> vma_flags_clear_mask(&diff, VMA_ACCESS_FLAGS);
> + /* Ignore flags that do not impact merging. */
> vma_flags_clear_mask(&diff, VMA_IGNORE_MERGE_FLAGS);
>
> - return a->vm_end == b->vm_start &&
> - mpol_equal(vma_policy(a), vma_policy(b)) &&
> - a->vm_file == b->vm_file &&
> - vma_flags_empty(&diff) &&
> - b->vm_pgoff == a->vm_pgoff + ((b->vm_start - a->vm_start) >> PAGE_SHIFT);
> + /* Must be adjacent. */
> + if (a->vm_end != b->vm_start)
> + return false;
> + /* Must have matching policy. */
> + if (!mpol_equal(vma_policy(a), vma_policy(b)))
> + return false;
> + /* Must both be anon or map the same file (MAP_PRIVATE case). */
> + if (a->vm_file != b->vm_file)
> + return false;
> + /* Flags must be equivalent modulo mprotect(). */
> + if (!vma_flags_empty(&diff))
> + return false;
> + /* Page offset must align. */
> + return vma_end_pgoff(a) == vma_start_pgoff(b);
Very nice.
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
--
Pedro
^ permalink raw reply
* Re: [PATCH 11/30] mm/vma: introduce and use vmg_pages(), vmg_[start, end]_pgoff()
From: Pedro Falcato @ 2026-06-30 16:35 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <f7b4f8a611ab4d36eb3cf2e394610a3744a93895.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:22PM +0100, Lorenzo Stoakes wrote:
> In the VMA logic we often need to determine the number of pages in the
> specified merge range, as well as the start and end page offsets of that
> range.
>
> Introduce and use helpers for these purposes.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
--
Pedro
^ permalink raw reply
* Re: [PATCH 10/30] MAINTAINERS: Move mm/interval_tree.c to rmap section
From: Pedro Falcato @ 2026-06-30 16:33 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <91dde21e9084bd04b626a1f073c3b9b3a23cb663.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:21PM +0100, Lorenzo Stoakes wrote:
> This file implements code for the interval trees used by the file and anon
> rmap implementation, so belongs in the rmap section.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Acked-by: Pedro Falcato <pfalcato@suse.de>
--
Pedro
^ permalink raw reply
* Re: [PATCH 09/30] mm/rmap: parameterise anon_vma_interval_tree_*() by anon_vma
From: Pedro Falcato @ 2026-06-30 16:32 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <1c1df7b905ef340cbf2effef769a4e770a8e0eb1.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:20PM +0100, Lorenzo Stoakes wrote:
> Similar to what we did with mapping_interval_tree*(), let's declare
> anon_vma_interval_tree*() in terms of anon_vma rather than rb_root_cached.
>
> In each case the rb tree referenced is &anon_vma->rb_root, so just pass
> anon_vma and the functions can figure this out themselves.
>
> Additionally, rename 'node' to 'avc', 'index' to 'pgoff_start', and 'last'
> to 'pgoff_last' to make clear what is being passed.
>
> Finally express page offsets in terms of pgoff_t to be consistent.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Yay!
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
I have a vaguely similar comment as for the file part (names could be
simpler, doesn't really matter whether it's an interval tree or possibly
even a tree), but I care less strongly about anon rmap :)
--
Pedro
^ permalink raw reply
* Re: [PATCH 08/30] mm/rmap: rename vma_interval_tree_*() to mapping_interval_tree_*()
From: Pedro Falcato @ 2026-06-30 16:28 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <f95462457025370efd047b9dfb039e76bbddf58b.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:19PM +0100, Lorenzo Stoakes wrote:
> The family of vma_interval_tree_() functions manipulate the
> address_space (which, of course, is generally referred to as 'mapping')
> reverse mapping, but are named the 'VMA' interval tree.
>
> VMAs may be mapped by an anon_vma, an address_space, or both. Therefore
> calling the mapping interval tree a 'VMA' interval tree is rather
> confusing.
>
> This is also inconsistent with the anon_vma_interval_tree_*() functions
> which explicitly reference the rmap object to which they pertain.
>
> Rename the vma_interval_tree_*() functions to mapping_interval_tree_*() to
> correct this.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
I'll have to nitpick this and say that I prefer [1] file_rmap_tree_, or
mapping_rmap_tree. Or possibly even better - mapping_ (so
mapping_for_each_vma, mapping_insert_vma, etc).
A bit of bikeshedding never hurts ;)
[1] locally I was naming things file_rmap, but I never actually got to
churn these names away
--
Pedro
^ permalink raw reply
* Re: [PATCH v8 04/46] KVM: Decouple kvm_has_arch_private_mem from CONFIG_KVM_VM_MEMORY_ATTRIBUTES
From: Xiaoyao Li @ 2026-06-30 16:24 UTC (permalink / raw)
To: Sean Christopherson
Cc: ackerleytng, aik, andrew.jones, binbin.wu, brauner, chao.p.peng,
david, jmattson, jthoughton, michael.roth, oupton, pankaj.gupta,
qperret, rick.p.edgecombe, rientjes, shivankg, steven.price,
tabba, willy, wyihan, yan.y.zhao, forkloop, pratyush,
suzuki.poulose, aneesh.kumar, liam, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Jonathan Corbet, Shuah Khan, Shuah Khan,
Vishal Annapurve, Andrew Morton, Chris Li, Kairui Song,
Kemeng Shi, Nhat Pham, Barry Song, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt, Kiryl Shutsemau,
Baoquan He, Jason Gunthorpe, Vlastimil Babka, kvm, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest, linux-mm,
linux-coco
In-Reply-To: <akO_Y0-ERgBoCqoQ@google.com>
On 6/30/2026 9:06 PM, Sean Christopherson wrote:
> On Tue, Jun 30, 2026, Xiaoyao Li wrote:
>> On 6/19/2026 8:31 AM, Ackerley Tng via B4 Relay wrote:
>>> arch/x86/include/asm/kvm_host.h | 4 +++-
>>> include/linux/kvm_host.h | 2 +-
>>> 2 files changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
>>> index 8e8eb8a5e8a6b..1bde67cf6eb0e 100644
>>> --- a/arch/x86/include/asm/kvm_host.h
>>> +++ b/arch/x86/include/asm/kvm_host.h
>>> @@ -2394,7 +2394,9 @@ void kvm_configure_mmu(bool enable_tdp, int tdp_forced_root_level,
>>> int tdp_max_root_level, int tdp_huge_page_level);
>>> -#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
>>> +#if defined(CONFIG_KVM_SW_PROTECTED_VM) || \
>>> + defined(CONFIG_KVM_INTEL_TDX) || \
>>> + defined(CONFIG_KVM_AMD_SEV)
>>
>> Maybe we can just remove the #ifdef and make it always avaiable?
>
> No, because common KVM keys off the macro to determine whether or not PRIVATE is
> a supported attribute:
>
> #ifdef kvm_arch_has_private_mem
> static u64 kvm_supports_private_mem(struct kvm *kvm)
> {
> return !kvm || kvm_arch_has_private_mem(kvm);
> }
> #else
> #define kvm_supports_private_mem(kvm) false
> #endif
>
> And also whether or not to provide the in-place conversion param (without PRIVATE,
> conversions aren't supported in general):
>
> #ifdef kvm_arch_has_private_mem
> bool __ro_after_init gmem_in_place_conversion = !IS_ENABLED(CONFIG_KVM_VM_MEMORY_ATTRIBUTES);
> module_param(gmem_in_place_conversion, bool, 0444);
> EXPORT_SYMBOL_FOR_KVM_INTERNAL(gmem_in_place_conversion);
> #endif
>
> I agree the #ifdeffery is ugly, but kvm_supports_private_mem() in particular
> needs to evaluate to false if PRIVATE memory isn't supported.
I agree with the above after seeing the later patches. But just to the
state where this patch applies on top, the #ifdef is not necessary.
Maybe add some log to explain it will be helpful.
^ permalink raw reply
* Re: [PATCH 07/30] mm/rmap: elide unnecessary static inline's in interval_tree.c
From: Pedro Falcato @ 2026-06-30 16:22 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <ed5fd5358382217a92f0a6afddcfaa030c933055.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:18PM +0100, Lorenzo Stoakes wrote:
> It's not necessary to declare these functions static inline as they are
> contained within a single compilation unit.
FWIW I don't think it's technically strictly equivalent (I have a vague
memory of inline lightly suggesting inlining a function to GCC, because of
compat reasons). Anyway, doesn't really matter, practically any static
function gets inlined with -O2 anyway.
>
> This makes the anonymous interval tree code consistent with the newly
> updated file-backed interval tree code.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
--
Pedro
^ permalink raw reply
* Re: [PATCH 06/30] mm/rmap: parameterise vma_interval_tree_*() by address_space
From: Pedro Falcato @ 2026-06-30 16:19 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <43050b10b53cdfc3627440e6b14ae2a9730b2a5c.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:17PM +0100, Lorenzo Stoakes wrote:
> The file-backed mapping interval tree functions vma_interval_tree_*()
> accept a raw rb_root_cached pointer to determine the tree in which they are
> operating.
>
> However, in each case, this is always associated with an address_space data
> type.
>
> So simply pass a pointer to that instead to simplify the code, and more
> clearly differentiate between these operations and those concerning
> anonymous mappings.
>
> While we're here, make the generated interval tree functions static as they
> do not need to be used externally (any previously existing external users
> have now been removed).
>
> We also rename VMA parameters from 'node' to 'vma' as calling this a node
> is simply confusing, update the input index types to pgoff_t since they
> reference page offsets and rename the parameters to pgoff_start and
> pgoff_last.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
1) This is fantastic
2) I need to rebase my local work :)
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
--
Pedro
^ permalink raw reply
* Re: [PATCH 05/30] mm/rmap: update mm/interval_tree.c comments
From: Pedro Falcato @ 2026-06-30 16:16 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <80d482a927b2e9862487b812e0ab48ebc1289a70.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:16PM +0100, Lorenzo Stoakes wrote:
> Update the file comment to clarify that both file-backed and anonymous
> interval trees are provided, referencing the relevant data types for
> clarity.
>
> Also add comments to indicate which parts of the file apply to each.
>
> While we're here, convert the VM_BUG_ON_VMA() to VM_WARN_ON_ONCE_VMA().
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
This is fine for now, but I'm wondering if it doesn't make sense to, in the
long term, have:
mm/rmap.c - common rmap mechanisms
mm/anon_rmap.c - anon rmap gunk
mm/file_rmap.c - file rmap gunk
or even something like mm/rmap/{core,anon,file,ksm??}.c
While working on my file rmap patches I noticed there's so much stuff just
splurged all over rmap.c - interval_tree.c - fs.h - fs/inode.c.
It's a little silly.
--
Pedro
^ permalink raw reply
* Re: [PATCH 04/30] mm: introduce and use vma_end_pgoff()
From: Pedro Falcato @ 2026-06-30 16:13 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <e379a1cb6a897126ad96e3a263fdb91d6c11f6cb.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:15PM +0100, Lorenzo Stoakes wrote:
> We already have vma_last_pgoff() which retrieves the last page offset
> within a VMA.
>
> However, code often wishes to span a page offset range, which requires the
> exclusive end of this range.
>
> So provide this in vma_end_pgoff() and update vma_last_pgoff() to use this
> function.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
--
Pedro
^ permalink raw reply
* Re: [PATCH 03/30] tools/testing/vma: use vma_start_pgoff() in merge tests
From: Pedro Falcato @ 2026-06-30 16:12 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <b501eca378b9d9734e83838102aadc9276590fba.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:14PM +0100, Lorenzo Stoakes wrote:
> Now we have the vma_start_pgoff() helper, update the merge tests to make
> use of it for consistency.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
--
Pedro
^ permalink raw reply
* Re: [PATCH 02/30] mm: add kdoc comments for vma_start/last_pgoff()
From: Pedro Falcato @ 2026-06-30 16:11 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <8c618dfd7de419e3b797b8bd1cd921d4c5b8878b.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:13PM +0100, Lorenzo Stoakes wrote:
> Describe what vma_start_pgoff() and vma_last_pgoff() actually provide in
> detail.
>
> This is in order that we can differentiate this between functions that will
> be added in a subsequent patch which provide a different page offset.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
--
Pedro
^ permalink raw reply
* Re: [PATCH 01/30] mm: move vma_start_pgoff() into mm.h and clean up
From: Pedro Falcato @ 2026-06-30 16:10 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <b28b698df4c009e85c4728446ca5863d8e633164.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:12PM +0100, Lorenzo Stoakes wrote:
> vma_last_pgoff() already lives there, so it's a bit odd to keep
> vma_start_pgoff() in mm/interval_tree.c. Move them together.
Hmm, a part of me wonders if this is the part where we should start cleaning
up mm.h into vma.h or something. Probably not, it would be extra churn right
now.
>
> These each return unsigned long, which pgoff_t is typedef'd to. Make this
> consistent and have these functions return pgoff_t instead.
>
> Additionally, express vma_last_pgoff() in terms of vma_start_pgoff(), since
> we wrap the vma->vm_pgoff access, we may as well use it here.
>
> Also while we're here, const-ify the VMA and cleanup a bit.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
> ---
> include/linux/mm.h | 9 +++++++--
> mm/interval_tree.c | 5 -----
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 485df9c2dbdd..059144435729 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -4278,9 +4278,14 @@ static inline unsigned long vma_pages(const struct vm_area_struct *vma)
> return (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> }
>
> -static inline unsigned long vma_last_pgoff(struct vm_area_struct *vma)
> +static inline pgoff_t vma_start_pgoff(const struct vm_area_struct *vma)
> {
> - return vma->vm_pgoff + vma_pages(vma) - 1;
> + return vma->vm_pgoff;
> +}
> +
> +static inline pgoff_t vma_last_pgoff(const struct vm_area_struct *vma)
> +{
> + return vma_start_pgoff(vma) + vma_pages(vma) - 1;
> }
>
> static inline unsigned long vma_desc_size(const struct vm_area_desc *desc)
> diff --git a/mm/interval_tree.c b/mm/interval_tree.c
> index 32bcfbfcf15f..344d1f5946c7 100644
> --- a/mm/interval_tree.c
> +++ b/mm/interval_tree.c
> @@ -10,11 +10,6 @@
> #include <linux/rmap.h>
> #include <linux/interval_tree_generic.h>
>
> -static inline unsigned long vma_start_pgoff(struct vm_area_struct *v)
> -{
> - return v->vm_pgoff;
> -}
> -
> INTERVAL_TREE_DEFINE(struct vm_area_struct, shared.rb,
> unsigned long, shared.rb_subtree_last,
> vma_start_pgoff, vma_last_pgoff, /* empty */, vma_interval_tree)
> --
> 2.54.0
>
--
Pedro
^ permalink raw reply
* Re: [PATCH 09/30] mm/rmap: parameterise anon_vma_interval_tree_*() by anon_vma
From: Lorenzo Stoakes @ 2026-06-30 15:59 UTC (permalink / raw)
To: Gregory Price
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Pedro Falcato, Rik van Riel,
Harry Yoo, Jann Horn
In-Reply-To: <akPm4FlwTj0FsZU9@gourry-fedora-PF4VCD3F>
On Tue, Jun 30, 2026 at 11:55:12AM -0400, Gregory Price wrote:
> On Tue, Jun 30, 2026 at 04:49:45PM +0100, Lorenzo Stoakes wrote:
> > On Tue, Jun 30, 2026 at 11:46:46AM -0400, Gregory Price wrote:
> > > On Mon, Jun 29, 2026 at 01:23:20PM +0100, Lorenzo Stoakes wrote:
> > > > Similar to what we did with mapping_interval_tree*(), let's declare
> > > > anon_vma_interval_tree*() in terms of anon_vma rather than rb_root_cached.
> > > >
> > > > In each case the rb tree referenced is &anon_vma->rb_root, so just pass
> > > > anon_vma and the functions can figure this out themselves.
> > > >
> > > > Additionally, rename 'node' to 'avc', 'index' to 'pgoff_start', and 'last'
> > > > to 'pgoff_last' to make clear what is being passed.
> > > >
> > >
> > > would it be possible to split the pure rename changes out from the
> > > changed function declarations? It's hard to pick out this as something
> > > that needs to be looked at as more than just a %s/x/y/
> >
> > Hmmm do I have to? :P
>
> I mean, no :]
>
> > I mean sure I can on a respin potentially, but it is a
> > pretty trivial change? Just mechnically as above.
> >
>
> And yeah certainly not worth a respin. Just learning some of the
> friction points of reviewing as I spend a little more time doing it
> every day.
Oh in the end you will be driven absolutely insane, David and I are already
there and soon you will join us! :) <- nervous smiley
But yeah, sorry if that made it harder to track what I'm doing here! Usually I
really try to split up to make each patch as easy as possibel to review, but
this one I thought 'why not at the same time' :P
>
> ~Gregory
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH 09/30] mm/rmap: parameterise anon_vma_interval_tree_*() by anon_vma
From: Gregory Price @ 2026-06-30 15:55 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Pedro Falcato, Rik van Riel,
Harry Yoo, Jann Horn
In-Reply-To: <akPlUrNWzl1ZPw1S@lucifer>
On Tue, Jun 30, 2026 at 04:49:45PM +0100, Lorenzo Stoakes wrote:
> On Tue, Jun 30, 2026 at 11:46:46AM -0400, Gregory Price wrote:
> > On Mon, Jun 29, 2026 at 01:23:20PM +0100, Lorenzo Stoakes wrote:
> > > Similar to what we did with mapping_interval_tree*(), let's declare
> > > anon_vma_interval_tree*() in terms of anon_vma rather than rb_root_cached.
> > >
> > > In each case the rb tree referenced is &anon_vma->rb_root, so just pass
> > > anon_vma and the functions can figure this out themselves.
> > >
> > > Additionally, rename 'node' to 'avc', 'index' to 'pgoff_start', and 'last'
> > > to 'pgoff_last' to make clear what is being passed.
> > >
> >
> > would it be possible to split the pure rename changes out from the
> > changed function declarations? It's hard to pick out this as something
> > that needs to be looked at as more than just a %s/x/y/
>
> Hmmm do I have to? :P
I mean, no :]
> I mean sure I can on a respin potentially, but it is a
> pretty trivial change? Just mechnically as above.
>
And yeah certainly not worth a respin. Just learning some of the
friction points of reviewing as I spend a little more time doing it
every day.
~Gregory
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox