* [PATCH v3 10/11] arm64: tegra: Hook up VPR to host1x
From: Thierry Reding @ 2026-07-01 16:08 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Sowjanya Komatineni,
Luca Ceresoli, Mikko Perttunen, Yury Norov, Rasmus Villemoes,
Russell King, Alexander Gordeev, Gerald Schaefer, Heiko Carstens,
Vasily Gorbik, Christian Borntraeger, Sven Schnelle,
Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Marek Szyprowski, Robin Murphy,
Sumit Semwal, Benjamin Gaignard, Brian Starkey, John Stultz,
T.J. Mercier, Christian König, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Catalin Marinas, Will Deacon
Cc: Thierry Reding, devicetree, linux-tegra, linux-kernel, dri-devel,
linux-media, linux-arm-kernel, linux-s390, linux-mm, iommu,
linaro-mm-sig, linux-trace-kernel, Thierry Reding
In-Reply-To: <20260701-tegra-vpr-v3-0-d80f7b871bb4@nvidia.com>
From: Thierry Reding <treding@nvidia.com>
The host1x needs access to the VPR region, so make sure to reference it
via the memory-region property.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra234.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra234.dtsi b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
index 52ff11873580..38637e8e6fc9 100644
--- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
@@ -4479,6 +4479,9 @@ vic@15340000 {
interconnect-names = "dma-mem", "write";
iommus = <&smmu_niso1 TEGRA234_SID_VIC>;
dma-coherent;
+
+ memory-region = <&vpr>;
+ memory-region-names = "protected";
};
nvdec@15480000 {
@@ -4497,6 +4500,9 @@ nvdec@15480000 {
iommus = <&smmu_niso1 TEGRA234_SID_NVDEC>;
dma-coherent;
+ memory-region = <&vpr>;
+ memory-region-names = "protected";
+
nvidia,memory-controller = <&mc>;
/*
--
2.54.0
^ permalink raw reply related
* [PATCH v3 11/11] arm64: tegra: Add VPR placeholder node on Tegra264
From: Thierry Reding @ 2026-07-01 16:08 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Sowjanya Komatineni,
Luca Ceresoli, Mikko Perttunen, Yury Norov, Rasmus Villemoes,
Russell King, Alexander Gordeev, Gerald Schaefer, Heiko Carstens,
Vasily Gorbik, Christian Borntraeger, Sven Schnelle,
Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Marek Szyprowski, Robin Murphy,
Sumit Semwal, Benjamin Gaignard, Brian Starkey, John Stultz,
T.J. Mercier, Christian König, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Catalin Marinas, Will Deacon
Cc: Thierry Reding, devicetree, linux-tegra, linux-kernel, dri-devel,
linux-media, linux-arm-kernel, linux-s390, linux-mm, iommu,
linaro-mm-sig, linux-trace-kernel, Thierry Reding
In-Reply-To: <20260701-tegra-vpr-v3-0-d80f7b871bb4@nvidia.com>
From: Thierry Reding <treding@nvidia.com>
This node contains two sets of properties, one for the case where the
VPR is resizable (in which case the VPR region will be dynamically
allocated at boot time) and another case where the VPR is fixed in size
and initialized by early firmware.
The firmware running on the device is responsible for updating the node
with the real physical address for the fixed VPR case and remove the
properties needed only for resizable VPR. Similarly, if the VPR is
resizable, the firmware should remove the "reg" property since it is no
longer needed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v3:
- comment out fixed VPR properties, assume resizable by default
- rename node to "protected"
---
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 33 ++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra264.dtsi b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
index 4c701abd25a8..85a18d99d643 100644
--- a/arch/arm64/boot/dts/nvidia/tegra264.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
@@ -24,6 +24,39 @@ shmem_bpmp: shmem@86070000 {
reg = <0x0 0x86070000 0x0 0x2000>;
no-map;
};
+
+ vpr: protected {
+ compatible = "nvidia,tegra-video-protection-region";
+ status = "disabled";
+
+ /*
+ * Two variants exist for this. For fixed VPR, the
+ * firmware is supposed to update the "reg" property
+ * with the fixed memory region configured as VPR.
+ *
+ * For resizable VPR we don't care about the exact
+ * address and instead want a reserved region to be
+ * allocated with a certain size and alignment at
+ * boot time.
+ *
+ * The below assumes resizable VPR by default. If the
+ * firmwares sets up fixed VPR, it is responsible for
+ * adding the missing "reg" property, removing any of
+ * the unused properties, as well as adding a unit-
+ * address matching the "reg" property.
+ */
+
+ /* fixed VPR */
+ /*
+ reg = <0x0 0x0 0x0 0x0>;
+ no-map;
+ */
+
+ /* resizable VPR */
+ size = <0x0 0x70000000>;
+ alignment = <0x0 0x100000>;
+ reusable;
+ };
};
/* SYSTEM MMIO */
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v8 17/46] KVM: guest_memfd: Advertise KVM_SET_MEMORY_ATTRIBUTES2 ioctl
From: Sean Christopherson @ 2026-07-01 16:09 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: <584a8f9a-1538-4f8b-b576-75ef0fa961c7@intel.com>
On Wed, Jul 01, 2026, Xiaoyao Li wrote:
> On 6/19/2026 8:31 AM, Ackerley Tng via B4 Relay wrote:
> > @@ -4969,6 +4973,11 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)
> > return 1;
> > case KVM_CAP_GUEST_MEMFD_FLAGS:
> > return kvm_gmem_get_supported_flags(kvm);
> > + case KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES:
> > + if (!gmem_in_place_conversion || !kvm_supports_private_mem(kvm))
> > + return 0;
> > +
> > + return KVM_MEMORY_ATTRIBUTE_PRIVATE;
> > #endif
> > default:
> > break;
>
> this looks inconsistent with the
>
> case KVM_SET_MEMORY_ATTRIBUTES2:
> if (!gmem_in_place_conversion)
> return -ENOTTY;
>
> Well, the check of
>
> if (!kvm_arch_has_private_mem(f->kvm))
> return -EINVAL;
>
> is buried in the following kvm_gmem_set_attributes(). How about moving of
> kvm_arch_has_private_mem() check to put it along with
> gmem_in_place_conversion check in kvm_gmem_ioctl() in Patch 13?
Me confused, patch 13 already adds the kvm_arch_has_private_mem() in
kvm_gmem_set_attributes().
That said, the ordering here is wonky and misleading. A cursory read of the series
would make one think that waiting to advertise KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES
makes it safe/ok for KVM to plumb in support for KVM_SET_MEMORY_ATTRIBUTES2 over
multiple patches. But that's not actually true, because the ioctl becomes live
the instant the code exists, userspace doesn't need to wait for KVM to formally
advertise support.
To further confuse matters, it is actually safe/ok to iteratively add support,
because it's all effectively dead code until "Let userspace disable per-VM mem
attributes, enable per-gmem attributes".
So, I think we should go a step further than what I think Xiaoyao is suggesting,
and fully squash patch 17 into patch 13. That way the reader doesn't have to jump
through as many mental hoops to piece together what is happening. It'll obviously
be a bigger patch, but should be easier to review/understand overall.
Oh, and that combined patch should carve out error_offset straightaway, so that
the full uAPI can be reviewed in a single patch.
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Keep pid and comm[] in the same structure
From: David Laight @ 2026-07-01 16:52 UTC (permalink / raw)
To: Steven Rostedt
Cc: Masami Hiramatsu, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel, Michal Koutný
In-Reply-To: <20260701082340.5b0bd4e7@gandalf.local.home>
On Wed, 1 Jul 2026 08:23:40 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 1 Jul 2026 13:04:04 +0100
> David Laight <david.laight.linux@gmail.com> wrote:
>
>
> > > Well, that would break trace-cmd. As reading the raw buffers clears the
> > > trace, and trace-cmd reads the saved_cmdlines file *after* it reads the
> > > trace, as during the trace it gets populated.
> >
> > So you'd need to clear it when tracing is enabled after the buffer is cleared.
> > Just a matter of getting the timing right.
>
> Why? Note, saved_cmdlines is for *all* instances. You can have multiple
> instances tracing different things and they still all use the one
> saved_cmdlines file. It's not tied to any specific buffer. It's a cache. It
> gets populated at the next schedule switch after an event occurs.
>
Mostly thoughts about the size of the cache and the difference between the
apparent default size of 128 and the actual size of 6300.
I had said that I'd not really looked at when it was used, just what
it contained.
None of that is relevant to this patch which just changes the data structures
a bit.
It also means that most updates will only dirty a single cache line.
Indeed it is probably worth comparing the comm[] strings and only doing
the write it they differ to avoid dirtying the cache line(s).
David
^ permalink raw reply
* Re: [PATCH v8 06/46] KVM: Enumerate support for PRIVATE memory iff kvm_arch_has_private_mem is defined
From: Sean Christopherson @ 2026-07-01 16:55 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: <739e6834-40b3-405b-ada4-d31c38d8416a@intel.com>
On Wed, Jul 01, 2026, Xiaoyao Li wrote:
> On 6/19/2026 8:31 AM, Ackerley Tng via B4 Relay wrote:
> > From: Ackerley Tng <ackerleytng@google.com>
> >
> > Explicitly guard reporting support for KVM_MEMORY_ATTRIBUTE_PRIVATE based
> > on kvm_arch_has_private_mem being #defined in anticipation of decoupling
> > kvm_supported_mem_attributes() from CONFIG_KVM_VM_MEMORY_ATTRIBUTES.
>
> Well, after this series, kvm_supported_mem_attributes() is renamed to
> kvm_supported_vm_mem_attributes(), and it's still under
> CONFIG_KVM_VM_MEMORY_ATTRIBUTES.
>
> > guest_memfd support for memory attributes will be unconditional to avoid
> > yet more macros (all architectures that support guest_memfd are expected to
> > use per-gmem attributes at some point), at which point enumerating support
> > KVM_MEMORY_ATTRIBUTE_PRIVATE based solely on memory attributes being
> > supported _somewhere_ would result in KVM over-reporting support on arm64.
>
> I don't understand it. This patch only changes the behavior of
> kvm_supported_mem_attributes(), the usage of which is guarded by
> CONFIG_KVM_VM_MEMORY_ATTRIBUTESq. This is config is only visible to x86 due
> to patch 03. How does it affect arm64?
Hrm, yeah, this is messed up. Ahh, I think Ackerley shuffled things around and
"broke" stuff in the process. In v7[1] and earlier, the diff was this:
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 091f201251159..68142bc962953 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -722,7 +722,7 @@ static inline int kvm_arch_vcpu_memslots_id(struct kvm_vcpu *vcpu)
}
#endif
-#ifndef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
+#ifndef kvm_arch_has_private_mem
static inline bool kvm_arch_has_private_mem(struct kvm *kvm)
{
return false;
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 306153abbafa5..abb9cfa3eb04d 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2421,8 +2421,10 @@ static int kvm_vm_ioctl_clear_dirty_log(struct kvm *kvm,
#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
static u64 kvm_supported_mem_attributes(struct kvm *kvm)
{
+#ifdef kvm_arch_has_private_mem
if (!kvm || kvm_arch_has_private_mem(kvm))
return KVM_MEMORY_ATTRIBUTE_PRIVATE;
+#endif
return 0;
}
which makes a *lot* more sense given the changelog (and IMO for the ordering in
general). In v8 here, Ackerley combined part of a change[2] (that I provided
off-list) with part of this commit, to create patch 4, "KVM: Decouple
kvm_has_arch_private_mem from CONFIG_KVM_VM_MEMORY_ATTRIBUTESthe".
Ackerley, the cover letter says:
+ Reshuffled the earlier commits that deal with preparing KVM to stop
seeing VM memory attributes as the only source of attributes.
but there's no explanation for *why* the reshuffling was done. Reorganizing
code like this at v8 of a series this size is a big "no-no" unless there's a
*really* good reason to do so. In addition to the resulting confusion, changes
like this invalidate Fuad's Reviewed-by. And since it's obviously quite difficult
to tease out exactly what changed, it's not realistic to re-review things without
doing a deep audit of the series, which no one wants to do for a series that is/was
so close to being fully ready. And without such an audit, I can't accept the
patches, because I can't trust that what I am accepting is what I and others have
reviewed.
So, except where there is/was a *need* to shuffle things around relative to v7,
I think we should revert back to the v7 ordering for v9. And where there is a
need to rework things, each and every one of those needs to be explicitly
documented, because "Reshuffled the earlier commits" is grossly insufficient.
[1] https://lore.kernel.org/all/20260522-gmem-inplace-conversion-v7-3-2f0fae496530@google.com
[2] https://github.com/sean-jc/linux/commit/8a475b1bcf89f1cf776ed9ce7d6bb587aab0d421
^ permalink raw reply related
* [PATCH] tracing: Add a no-rcu-check version of trace_##event##_enabled()
From: Steven Rostedt @ 2026-07-01 17:27 UTC (permalink / raw)
To: LKML, Linux trace kernel
Cc: Masami Hiramatsu, Mathieu Desnoyers, Geert Uytterhoeven,
David Carlier
From: Steven Rostedt <rostedt@goodmis.org>
Tracepoints require that RCU is watching. To prevent them from being used
in places that RCU is not watching, the trace_##event() macro always
calls rcu_is_watching() even when the event is not enabled and warns if
RCU is not watching. This is to make sure a warning is triggered even if
the tracepoint is never enabled (as it is only a bug when it is).
It was noticed that tracepoints could be hidden within
trace_#event#_enabled() calls, which are used to do extra work for the
tracepoint only if the tracepoint is enabled. But this also can hide the
fact that a tracepoint is placed in a location that can be called when RCU
is not watching.
Commit 9764e731ef6ab ("tracepoint: Add lockdep rcu_is_watching() check to
trace_##name##_enabled()") added a check to the trace_##event##_enabled()
macro to make sure RCU is watching when it is called to make sure not to
hide the bug of a tracepoint being called when RCU is not watching.
There is one case in the irq_disable tracepoint where it is within a
trace_irq_disable_enabled() block, but it checks if RCU is watching, and
if it isn't, it makes a call to ct_irq_enter() that makes RCU watch again.
But because trace_irq_disable_enabled() now checks if RCU is watching and
will trigger if it isn't. This is a false warning as the code within
the block handles this case.
Add a new internal macro __trace_##event##_enabled() that doesn't check if
RCU is watching, and convert the irq_enable/disable tracepoints over to
it.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Closes: https://lore.kernel.org/all/CAMuHMdXud_RpWag_hFqa2ByBGRxg6KnxGL1ObCWZrpTsk3TfAw@mail.gmail.com/
Fixes: 9764e731ef6ab ("tracepoint: Add lockdep rcu_is_watching() check to trace_##name##_enabled()")
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
include/linux/tracepoint.h | 12 +++++++++++-
kernel/trace/trace_preemptirq.c | 2 +-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index 4a0c36f40fe2..e0d838c9ce93 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -292,13 +292,18 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
{ \
} \
static inline bool \
+ __trace_##name##_enabled(void) \
+ { \
+ return static_branch_unlikely(&__tracepoint_##name.key);\
+ } \
+ static inline bool \
trace_##name##_enabled(void) \
{ \
if (IS_ENABLED(CONFIG_LOCKDEP)) { \
WARN_ONCE(!rcu_is_watching(), \
"RCU not watching for tracepoint"); \
} \
- return static_branch_unlikely(&__tracepoint_##name.key);\
+ return __trace_##name##_enabled(); \
}
#define __DECLARE_TRACE(name, proto, args, cond, data_proto) \
@@ -457,6 +462,11 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
{ \
} \
static inline bool \
+ __trace_##name##_enabled(void) \
+ { \
+ return false; \
+ } \
+ static inline bool \
trace_##name##_enabled(void) \
{ \
return false; \
diff --git a/kernel/trace/trace_preemptirq.c b/kernel/trace/trace_preemptirq.c
index 0c42b15c3800..b63e3558948f 100644
--- a/kernel/trace/trace_preemptirq.c
+++ b/kernel/trace/trace_preemptirq.c
@@ -30,7 +30,7 @@
#else
#define trace(point, args) \
do { \
- if (trace_##point##_enabled()) { \
+ if (__trace_##point##_enabled()) { \
bool exit_rcu = false; \
if (in_nmi()) \
break; \
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v13 04/11] perf/probe: Ignore comment lines in dynamic_events/kprobe_events file
From: Namhyung Kim @ 2026-07-01 17:44 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Arnaldo Carvalho de Melo, Steven Rostedt, Mathieu Desnoyers,
Jonathan Corbet, Shuah Khan, linux-kernel, linux-trace-kernel,
linux-doc, linux-kselftest
In-Reply-To: <20260701073939.81842d6f6bd139a329c45c7f@kernel.org>
On Wed, Jul 01, 2026 at 07:39:39AM +0900, Masami Hiramatsu wrote:
> On Mon, 29 Jun 2026 17:33:43 -0700
> Namhyung Kim <namhyung@kernel.org> wrote:
>
> > Hi Masami,
> >
> > On Tue, Jun 30, 2026 at 07:32:11AM +0900, Masami Hiramatsu wrote:
> > > Hi Arnaldo, Namhyung,
> > >
> > > I forgot to CC this. Can I pick this patch via linux-trace tree,
> > > or would you pick this?
> > > This is a part of typecast series [1] only for debugging.
> >
> > Thanks for letting me know.
> >
> > I think it's better to route this through the perf tree as we're seeing
> > a lot of cleanups all around the code base. Having this together would
> > reduce chances of future conflicts. Does that sound ok to you?
>
> OK, thanks for confirmation. Then I'll drop it from probes/for-next (and probes/core).
Thanks, I've applied it to perf-tools-next.
Best regards,
Namhyung
^ permalink raw reply
* Re: [RFC PATCH 2/4] tracing/probes: Compile all fetchargs into a single BPF program per event
From: Alexei Starovoitov @ 2026-07-01 18:41 UTC (permalink / raw)
To: Masami Hiramatsu (Google), Steven Rostedt, Shuah Khan
Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel,
linux-kselftest, bpf
In-Reply-To: <178291354144.1566898.14374948740441958770.stgit@devnote2>
On Wed Jul 1, 2026 at 6:45 AM PDT, Masami Hiramatsu (Google) wrote:
> +static bool trace_probe_can_compile_bpf(struct trace_probe *tp)
> +{
> + int i;
> +
> + if (tp->nr_args == 0)
> + return false;
> +
> + for (i = 0; i < tp->nr_args; i++) {
> + struct probe_arg *parg = &tp->args[i];
> + struct fetch_insn *code = parg->code;
> +
> + while (code->op != FETCH_OP_END) {
> + switch (code->op) {
> + case FETCH_OP_REG:
> + case FETCH_OP_IMM:
> + case FETCH_OP_DEREF:
> + case FETCH_OP_ST_RAW:
> + case FETCH_OP_ST_MEM:
> + break;
> + case FETCH_OP_ARG:
> + if (regs_get_kernel_argument_offset(code->param) < 0)
> + return false;
> + break;
> + default:
> + return false;
> + }
> + code++;
> + }
> + }
> + return true;
> +}
> +
> +static void trace_probe_compile_bpf(struct trace_probe *tp)
> +{
> + struct bpf_insn *insns;
> + int i = 0;
> + struct bpf_prog *prog;
> + int err, idx;
> +
> + if (!trace_probe_can_compile_bpf(tp))
> + return;
> +
> + insns = kmalloc_array(512, sizeof(struct bpf_insn), GFP_KERNEL);
> + if (!insns)
> + return;
> +
> + /* Prologue: R6 = ctx */
> + insns[i++] = BPF_MOV64_REG(BPF_REG_6, BPF_REG_1);
> + /* R7 = ctx->rec */
> + insns[i++] = BPF_LDX_MEM(BPF_DW, BPF_REG_7, BPF_REG_6,
> + offsetof(struct fetch_bpf_ctx, rec));
> + /* R8 = ctx->data */
> + insns[i++] = BPF_LDX_MEM(BPF_DW, BPF_REG_8, BPF_REG_6,
> + offsetof(struct fetch_bpf_ctx, data));
> + /* R9 = total size (0) */
> + insns[i++] = BPF_MOV64_IMM(BPF_REG_9, 0);
> +
> + for (idx = 0; idx < tp->nr_args; idx++) {
> + struct probe_arg *parg = &tp->args[idx];
> + struct fetch_insn *code = parg->code;
> +
> + while (code->op != FETCH_OP_END && i < 500) {
> + switch (code->op) {
> + case FETCH_OP_REG:
> + /* R0 = *(unsigned long *)(R7 + code->param) */
> + insns[i++] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_7, code->param);
> + break;
> + case FETCH_OP_ARG: {
> + int offset = regs_get_kernel_argument_offset(code->param);
> + /* R0 = *(unsigned long *)(R7 + offset) */
> + insns[i++] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_7, offset);
> + break;
> + }
> + case FETCH_OP_IMM:
> + insns[i++] = BPF_LD_IMM64(BPF_REG_0, code->immediate);
> + break;
> + case FETCH_OP_DEREF:
> + /* Add offset: R3 = R0 + code->offset (src) */
> + insns[i++] = BPF_MOV64_REG(BPF_REG_2, BPF_REG_0);
> + if (code->offset)
> + insns[i++] = BPF_ALU64_IMM(BPF_ADD, BPF_REG_2,
> + code->offset);
> + /* R1 = dst (R10 - 8 on stack) */
> + insns[i++] = BPF_MOV64_REG(BPF_REG_1, BPF_REG_10);
> + insns[i++] = BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, -8);
> + /* R3 = size */
> + insns[i++] = BPF_MOV64_IMM(BPF_REG_3, sizeof(unsigned long));
> + /* Call copy_from_kernel_nofault(dst, src, size) */
> + insns[i++] = BPF_EMIT_CALL(copy_from_kernel_nofault);
> + /* if (R0 < 0) return R0; */
> + insns[i++] = BPF_JMP_IMM(BPF_JSGE, BPF_REG_0, 0, 1);
> + insns[i++] = BPF_EXIT_INSN();
> + /* R0 = *(unsigned long *)(R10 - 8) */
> + insns[i++] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_10, -8);
> + break;
> + case FETCH_OP_ST_RAW:
> + /* Store R0 into R8 (data) + parg->offset based on size */
> + switch (code->size) {
> + case 1:
> + insns[i++] = BPF_STX_MEM(BPF_B, BPF_REG_8, BPF_REG_0,
> + parg->offset);
> + break;
> + case 2:
> + insns[i++] = BPF_STX_MEM(BPF_H, BPF_REG_8, BPF_REG_0,
> + parg->offset);
> + break;
> + case 4:
> + insns[i++] = BPF_STX_MEM(BPF_W, BPF_REG_8, BPF_REG_0,
> + parg->offset);
> + break;
> + case 8:
> + insns[i++] = BPF_STX_MEM(BPF_DW, BPF_REG_8, BPF_REG_0,
> + parg->offset);
> + break;
> + }
> + break;
> + case FETCH_OP_ST_MEM:
> + /* Add offset: R2 = R0 + code->offset (src) */
> + insns[i++] = BPF_MOV64_REG(BPF_REG_2, BPF_REG_0);
> + if (code->offset)
> + insns[i++] = BPF_ALU64_IMM(BPF_ADD, BPF_REG_2,
> + code->offset);
> + /* R1 = dst (R8 + parg->offset) */
> + insns[i++] = BPF_MOV64_REG(BPF_REG_1, BPF_REG_8);
> + if (parg->offset)
> + insns[i++] = BPF_ALU64_IMM(BPF_ADD, BPF_REG_1,
> + parg->offset);
> + /* R3 = size */
> + insns[i++] = BPF_MOV64_IMM(BPF_REG_3, code->size);
> + /* Call copy_from_kernel_nofault(dst, src, size) */
> + insns[i++] = BPF_EMIT_CALL(copy_from_kernel_nofault);
> + /* if (R0 < 0) return R0; */
> + insns[i++] = BPF_JMP_IMM(BPF_JSGE, BPF_REG_0, 0, 1);
> + insns[i++] = BPF_EXIT_INSN();
> + break;
> + default:
> + goto out;
> + }
> + code++;
> + }
> + }
Nack.
I really don't like it.
There were days in the past when the kernel generating bpf directly was appealing.
These days are gone. Performance improvements for fetchargs is not a good reason
to add all this complexity and bypass verifier checks.
bpf insns should come from user space.
^ permalink raw reply
* Re: [RFC PATCH 2/4] tracing/probes: Compile all fetchargs into a single BPF program per event
From: Steven Rostedt @ 2026-07-01 18:47 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Masami Hiramatsu (Google), Shuah Khan, Mathieu Desnoyers,
linux-kernel, linux-trace-kernel, linux-kselftest, bpf
In-Reply-To: <DJNGE5JG5ZY4.FEO5DZ21TL7Z@gmail.com>
On Wed, 01 Jul 2026 11:41:26 -0700
"Alexei Starovoitov" <alexei.starovoitov@gmail.com> wrote:
> Nack.
> I really don't like it.
So the nack is mostly your opinion and not technical?
> There were days in the past when the kernel generating bpf directly was appealing.
> These days are gone. Performance improvements for fetchargs is not a good reason
Why is performance *not* a good reason?
> to add all this complexity and bypass verifier checks.
The code lives in the kernel. What reason is there to add verification
checks? The point of verification is because we don't trust user space. Why
do we not trust the kernel?
> bpf insns should come from user space.
Why?
-- Steve
^ permalink raw reply
* Re: [RFC PATCH 2/4] tracing/probes: Compile all fetchargs into a single BPF program per event
From: Alexei Starovoitov @ 2026-07-01 18:53 UTC (permalink / raw)
To: Steven Rostedt
Cc: Masami Hiramatsu (Google), Shuah Khan, Mathieu Desnoyers,
linux-kernel, linux-trace-kernel, linux-kselftest, bpf
In-Reply-To: <20260701144726.0a5f2204@gandalf.local.home>
On Wed Jul 1, 2026 at 11:47 AM PDT, Steven Rostedt wrote:
> On Wed, 01 Jul 2026 11:41:26 -0700
> "Alexei Starovoitov" <alexei.starovoitov@gmail.com> wrote:
>
>> Nack.
>> I really don't like it.
>
> So the nack is mostly your opinion and not technical?
>
>> There were days in the past when the kernel generating bpf directly was appealing.
>> These days are gone. Performance improvements for fetchargs is not a good reason
>
> Why is performance *not* a good reason?
>
>> to add all this complexity and bypass verifier checks.
>
> The code lives in the kernel. What reason is there to add verification
> checks? The point of verification is because we don't trust user space. Why
> do we not trust the kernel?
>
>> bpf insns should come from user space.
>
> Why?
because I see this patchset as pointless kernel bloat with the "help" of bpf.
Hence the nack to avoid dragging bpf into this.
Call it philosophical disagreement if you like.
^ permalink raw reply
* Re: [PATCH v4 12/13] rv: Fix read_lock scope in per-task DA cleanup
From: Steven Rostedt @ 2026-07-01 19:27 UTC (permalink / raw)
To: Gabriele Monaco; +Cc: linux-kernel, linux-trace-kernel, Wen Yang, Nam Cao
In-Reply-To: <20260601153840.124372-13-gmonaco@redhat.com>
On Mon, 1 Jun 2026 17:38:39 +0200
Gabriele Monaco <gmonaco@redhat.com> wrote:
> The da_monitor_reset_all() function for per-task monitors takes
> tasklist_lock while iterating over tasks, then keeps it also while
> iterating over idle tasks (one per CPU). The latter is not necessary
> since the lock needs to guard only for_each_process_thread().
>
> Use a scoped_guard for more compact syntax and adjust the scope only
> where the lock is necessary.
>
> Reviewed-by: Wen Yang <wen.yang@linux.dev>
> Reviewed-by: Nam Cao <namcao@linutronix.de>
> Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
Hmm, this and patch 13 didn't get applied. Do you plan on sending them later?
-- Steve
^ permalink raw reply
* Re: [PATCH v3 01/11] dt-bindings: reserved-memory: Document Tegra VPR
From: Rob Herring (Arm) @ 2026-07-01 19:53 UTC (permalink / raw)
To: Thierry Reding
Cc: Christian Borntraeger, Rasmus Villemoes, dri-devel,
David Hildenbrand, Yury Norov, linux-media, linux-kernel,
Robin Murphy, Simona Vetter, linux-trace-kernel,
Krzysztof Kozlowski, Christian König, linux-mm, Russell King,
Will Deacon, Masami Hiramatsu, David Airlie, Vasily Gorbik,
Benjamin Gaignard, linaro-mm-sig, Heiko Carstens, Sumit Semwal,
Thierry Reding, Maxime Ripard, Thierry Reding, John Stultz,
Luca Ceresoli, Vlastimil Babka, Brian Starkey, Mikko Perttunen,
Michal Hocko, Steven Rostedt, Jonathan Hunter, Maarten Lankhorst,
Sowjanya Komatineni, Suren Baghdasaryan, linux-arm-kernel,
linux-s390, devicetree, Liam R. Howlett, linux-tegra,
Catalin Marinas, Marek Szyprowski, Conor Dooley,
Thomas Zimmermann, Andrew Morton, Gerald Schaefer,
Alexander Gordeev, Lorenzo Stoakes, T.J. Mercier,
Mathieu Desnoyers, iommu, Mike Rapoport, Sven Schnelle
In-Reply-To: <20260701-tegra-vpr-v3-1-d80f7b871bb4@nvidia.com>
On Wed, 01 Jul 2026 18:08:12 +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> The Video Protection Region (VPR) found on NVIDIA Tegra chips is a
> region of memory that is protected from CPU accesses. It is used to
> decode and play back DRM protected content.
>
> It is a standard reserved memory region that can exist in two forms:
> static VPR where the base address and size are fixed (uses the "reg"
> property to describe the memory) and a resizable VPR where only the
> size is known upfront and the OS can allocate it wherever it can be
> accomodated.
>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> Changes in v2:
> - add examples for fixed and resizable VPR
> ---
> .../nvidia,tegra-video-protection-region.yaml | 76 ++++++++++++++++++++++
> 1 file changed, 76 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra-video-protection-region.example.dtb: protected@2a8000000 (nvidia,tegra-video-protection-region): reg: [[2, 2818572288], [0, 1879048192]] is too long
from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection-region.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra-video-protection-region.example.dtb: protected@2a8000000 (nvidia,tegra-video-protection-region): Unevaluated properties are not allowed ('no-map', 'reg' were unexpected)
from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection-region.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260701-tegra-vpr-v3-1-d80f7b871bb4@nvidia.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v3 02/11] dt-bindings: display: tegra: Document memory regions
From: Rob Herring (Arm) @ 2026-07-01 19:53 UTC (permalink / raw)
To: Thierry Reding
Cc: linaro-mm-sig, Lorenzo Stoakes, Sven Schnelle, Gerald Schaefer,
Thomas Zimmermann, Yury Norov, linux-media, linux-trace-kernel,
Rasmus Villemoes, Jonathan Hunter, linux-s390, Masami Hiramatsu,
Vlastimil Babka, Heiko Carstens, Mikko Perttunen,
David Hildenbrand, Steven Rostedt, iommu, linux-kernel,
Simona Vetter, Mike Rapoport, Maarten Lankhorst, Robin Murphy,
Russell King, dri-devel, Maxime Ripard, Marek Szyprowski,
Vasily Gorbik, Brian Starkey, Krzysztof Kozlowski,
Christian Borntraeger, John Stultz, Christian König,
Thierry Reding, devicetree, Benjamin Gaignard, Catalin Marinas,
linux-arm-kernel, Alexander Gordeev, Mathieu Desnoyers, linux-mm,
Sumit Semwal, Will Deacon, Thierry Reding, Luca Ceresoli,
Liam R. Howlett, Andrew Morton, Suren Baghdasaryan,
Sowjanya Komatineni, linux-tegra, Conor Dooley, Michal Hocko,
T.J. Mercier, David Airlie
In-Reply-To: <20260701-tegra-vpr-v3-2-d80f7b871bb4@nvidia.com>
On Wed, 01 Jul 2026 18:08:13 +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Add the memory-region and memory-region-names properties to the bindings
> for the display controllers and the host1x engine found on various Tegra
> generations. These memory regions are used to access firmware-provided
> framebuffer memory as well as the video protection region.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> Changes in v3:
> - document properties for VIC
> ---
> .../devicetree/bindings/display/tegra/nvidia,tegra124-vic.yaml | 8 ++++++++
> .../devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml | 10 ++++++++++
> .../devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml | 10 +++++++++-
> .../bindings/display/tegra/nvidia,tegra20-host1x.yaml | 7 +++++++
> 4 files changed, 34 insertions(+), 1 deletion(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml: properties:memory-region-names: 'anyOf' conditional failed, one must be fixed:
'maxitems' is not one of ['$ref', 'additionalItems', 'additionalProperties', 'allOf', 'anyOf', 'const', 'contains', 'default', 'dependencies', 'dependentRequired', 'dependentSchemas', 'deprecated', 'description', 'else', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'items', 'if', 'minItems', 'minimum', 'maxItems', 'maximum', 'multipleOf', 'not', 'oneOf', 'pattern', 'patternProperties', 'properties', 'required', 'then', 'typeSize', 'unevaluatedProperties', 'uniqueItems']
'type' was expected
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml: properties:memory-region-names:items: {'enum': ['framebuffer', 'protected']} is not of type 'array'
from schema $id: http://devicetree.org/meta-schemas/string-array.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml: properties:memory-region-names: Additional properties are not allowed ('maxitems' was unexpected)
from schema $id: http://devicetree.org/meta-schemas/string-array.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml: properties:memory-region-names:items: {'enum': ['framebuffer', 'protected']} is not of type 'array'
from schema $id: http://devicetree.org/meta-schemas/string-array.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml: properties:memory-region-names: Additional properties are not allowed ('maxitems' was unexpected)
from schema $id: http://devicetree.org/meta-schemas/string-array.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260701-tegra-vpr-v3-2-d80f7b871bb4@nvidia.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH] tracing: Use more common error handling code in event_enable_trigger_parse()
From: Steven Rostedt @ 2026-07-01 20:37 UTC (permalink / raw)
To: Markus Elfring
Cc: linux-trace-kernel, Masami Hiramatsu, Mathieu Desnoyers,
Tom Zanussi, LKML, kernel-janitors
In-Reply-To: <bddf7714-0b80-4e94-9da8-55a263c270a5@web.de>
On Tue, 16 Jun 2026 22:33:17 +0200
Markus Elfring <Markus.Elfring@web.de> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Tue, 16 Jun 2026 22:22:52 +0200
>
> Use an additional label so that a bit of exception handling can be better
> reused at the end of this function implementation.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> kernel/trace/trace_events_trigger.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c
> index 655db2e82513..7e17dd6d5b50 100644
> --- a/kernel/trace/trace_events_trigger.c
> +++ b/kernel/trace/trace_events_trigger.c
> @@ -1789,17 +1789,14 @@ int event_enable_trigger_parse(struct event_command *cmd_ops,
> enable_data->file = event_enable_file;
>
> trigger_data = trigger_data_alloc(cmd_ops, cmd, param, enable_data);
> - if (!trigger_data) {
> - kfree(enable_data);
> - return ret;
> - }
> + if (!trigger_data)
> + goto out_free_enable_data;
>
> if (remove) {
> event_trigger_unregister(cmd_ops, file, glob+1, trigger_data);
> kfree(trigger_data);
> - kfree(enable_data);
> ret = 0;
> - return ret;
> + goto out_free_enable_data;
> }
>
> /* Up the trigger_data count to make sure nothing frees it on failure */
> @@ -1837,6 +1834,7 @@ int event_enable_trigger_parse(struct event_command *cmd_ops,
> out_free:
> event_trigger_reset_filter(cmd_ops, trigger_data);
> event_trigger_free(trigger_data);
> +out_free_enable_data:
> kfree(enable_data);
Ug, let's not add more error labels now that we have cleanup code.
Untested, but this would be cleaner:
diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c
index 655db2e82513..7da096acaf2b 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -1739,7 +1739,7 @@ int event_enable_trigger_parse(struct event_command *cmd_ops,
char *glob, char *cmd, char *param_and_filter)
{
struct trace_event_file *event_enable_file;
- struct enable_trigger_data *enable_data;
+ struct enable_trigger_data *enable_data __free(kfree) = NULL;
struct event_trigger_data *trigger_data;
struct trace_array *tr = file->tr;
char *param, *filter;
@@ -1789,17 +1789,13 @@ int event_enable_trigger_parse(struct event_command *cmd_ops,
enable_data->file = event_enable_file;
trigger_data = trigger_data_alloc(cmd_ops, cmd, param, enable_data);
- if (!trigger_data) {
- kfree(enable_data);
+ if (!trigger_data)
return ret;
- }
if (remove) {
event_trigger_unregister(cmd_ops, file, glob+1, trigger_data);
kfree(trigger_data);
- kfree(enable_data);
- ret = 0;
- return ret;
+ return 0;
}
/* Up the trigger_data count to make sure nothing frees it on failure */
@@ -1829,6 +1825,7 @@ int event_enable_trigger_parse(struct event_command *cmd_ops,
goto out_disable;
event_trigger_free(trigger_data);
+ no_free_ptr(enable_free);
return ret;
out_disable:
trace_event_enable_disable(event_enable_file, 0, 1);
@@ -1837,7 +1834,6 @@ int event_enable_trigger_parse(struct event_command *cmd_ops,
out_free:
event_trigger_reset_filter(cmd_ops, trigger_data);
event_trigger_free(trigger_data);
- kfree(enable_data);
return ret;
}
-- Steve
^ permalink raw reply related
* [PATCH] tracing: Cleanup event_enable_trigger_parse() by using __free()
From: Steven Rostedt @ 2026-07-01 21:48 UTC (permalink / raw)
To: LKML, Linux Trace Kernel
Cc: Masami Hiramatsu, Mathieu Desnoyers, Markus Elfring
From: Steven Rostedt <rostedt@goodmis.org>
The enable_data variable gets freed on most error paths in
event_enable_trigger_parse(). Use free() to free it and just before
returning normally, call no_free_ptr(enable_data) to keep it from being
freed.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
kernel/trace/trace_events_trigger.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c
index 655db2e82513..fe5ca6ac7c8d 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -1739,7 +1739,7 @@ int event_enable_trigger_parse(struct event_command *cmd_ops,
char *glob, char *cmd, char *param_and_filter)
{
struct trace_event_file *event_enable_file;
- struct enable_trigger_data *enable_data;
+ struct enable_trigger_data *enable_data __free(kfree) = NULL;
struct event_trigger_data *trigger_data;
struct trace_array *tr = file->tr;
char *param, *filter;
@@ -1789,17 +1789,13 @@ int event_enable_trigger_parse(struct event_command *cmd_ops,
enable_data->file = event_enable_file;
trigger_data = trigger_data_alloc(cmd_ops, cmd, param, enable_data);
- if (!trigger_data) {
- kfree(enable_data);
+ if (!trigger_data)
return ret;
- }
if (remove) {
event_trigger_unregister(cmd_ops, file, glob+1, trigger_data);
kfree(trigger_data);
- kfree(enable_data);
- ret = 0;
- return ret;
+ return 0;
}
/* Up the trigger_data count to make sure nothing frees it on failure */
@@ -1829,6 +1825,7 @@ int event_enable_trigger_parse(struct event_command *cmd_ops,
goto out_disable;
event_trigger_free(trigger_data);
+ no_free_ptr(enable_data);
return ret;
out_disable:
trace_event_enable_disable(event_enable_file, 0, 1);
@@ -1837,7 +1834,6 @@ int event_enable_trigger_parse(struct event_command *cmd_ops,
out_free:
event_trigger_reset_filter(cmd_ops, trigger_data);
event_trigger_free(trigger_data);
- kfree(enable_data);
return ret;
}
--
2.53.0
^ permalink raw reply related
* Re: [RFC PATCH 2/4] tracing/probes: Compile all fetchargs into a single BPF program per event
From: Masami Hiramatsu @ 2026-07-01 22:40 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Steven Rostedt, Shuah Khan, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel, linux-kselftest, bpf
In-Reply-To: <DJNGE5JG5ZY4.FEO5DZ21TL7Z@gmail.com>
On Wed, 01 Jul 2026 11:41:26 -0700
"Alexei Starovoitov" <alexei.starovoitov@gmail.com> wrote:
>
> Nack.
> I really don't like it.
> There were days in the past when the kernel generating bpf directly was appealing.
> These days are gone. Performance improvements for fetchargs is not a good reason
> to add all this complexity and bypass verifier checks.
> bpf insns should come from user space.
Thanks for your comment!
OK, I don't mind because this is a kind of investigation project. And some
people had asked me about the same idea, now I can tell them the result.
I'm satisfied with the current outcome, as this development process gave me
insight into the implementation of BPF and demonstrated the potential for
optimization via JIT. :)
And also, as noted in the cover letter, the current performance of fetcharg
is better than I thought, and is good enough for debugging. :)
BTW, I'm also interested in calling the verifier on this generated code.
Even it it is not merged, I think showing the correct way to implement it
will be useful in the future.
Thank you,
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH] tracing: Cleanup event_enable_trigger_parse() by using __free()
From: Masami Hiramatsu @ 2026-07-01 22:41 UTC (permalink / raw)
To: Steven Rostedt
Cc: LKML, Linux Trace Kernel, Masami Hiramatsu, Mathieu Desnoyers,
Markus Elfring
In-Reply-To: <20260701174829.67ab8a33@gandalf.local.home>
On Wed, 1 Jul 2026 17:48:29 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
>
> The enable_data variable gets freed on most error paths in
> event_enable_trigger_parse(). Use free() to free it and just before
> returning normally, call no_free_ptr(enable_data) to keep it from being
> freed.
>
This looks good to me.
Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Thank you,
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> ---
> kernel/trace/trace_events_trigger.c | 12 ++++--------
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c
> index 655db2e82513..fe5ca6ac7c8d 100644
> --- a/kernel/trace/trace_events_trigger.c
> +++ b/kernel/trace/trace_events_trigger.c
> @@ -1739,7 +1739,7 @@ int event_enable_trigger_parse(struct event_command *cmd_ops,
> char *glob, char *cmd, char *param_and_filter)
> {
> struct trace_event_file *event_enable_file;
> - struct enable_trigger_data *enable_data;
> + struct enable_trigger_data *enable_data __free(kfree) = NULL;
> struct event_trigger_data *trigger_data;
> struct trace_array *tr = file->tr;
> char *param, *filter;
> @@ -1789,17 +1789,13 @@ int event_enable_trigger_parse(struct event_command *cmd_ops,
> enable_data->file = event_enable_file;
>
> trigger_data = trigger_data_alloc(cmd_ops, cmd, param, enable_data);
> - if (!trigger_data) {
> - kfree(enable_data);
> + if (!trigger_data)
> return ret;
> - }
>
> if (remove) {
> event_trigger_unregister(cmd_ops, file, glob+1, trigger_data);
> kfree(trigger_data);
> - kfree(enable_data);
> - ret = 0;
> - return ret;
> + return 0;
> }
>
> /* Up the trigger_data count to make sure nothing frees it on failure */
> @@ -1829,6 +1825,7 @@ int event_enable_trigger_parse(struct event_command *cmd_ops,
> goto out_disable;
>
> event_trigger_free(trigger_data);
> + no_free_ptr(enable_data);
> return ret;
> out_disable:
> trace_event_enable_disable(event_enable_file, 0, 1);
> @@ -1837,7 +1834,6 @@ int event_enable_trigger_parse(struct event_command *cmd_ops,
> out_free:
> event_trigger_reset_filter(cmd_ops, trigger_data);
> event_trigger_free(trigger_data);
> - kfree(enable_data);
>
> return ret;
> }
> --
> 2.53.0
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCHv5 00/13] uprobes/x86: Fix red zone issue for optimized uprobes
From: Andrii Nakryiko @ 2026-07-01 23:13 UTC (permalink / raw)
To: Jiri Olsa
Cc: Oleg Nesterov, Peter Zijlstra, Ingo Molnar, Masami Hiramatsu,
Andrii Nakryiko, bpf, linux-trace-kernel
In-Reply-To: <20260701111337.53943-1-jolsa@kernel.org>
On Wed, Jul 1, 2026 at 4:13 AM Jiri Olsa <jolsa@kernel.org> wrote:
>
> hi,
> Andrii reported an issue with optimized uprobes [1] that can clobber
> redzone area with call instruction storing return address on stack
> where user code may keep temporary data without adjusting rsp.
>
> Fixing this by moving the optimized uprobes on top of 10-bytes nop
> instruction, so we can squeeze another instruction to escape the
> redzone area before doing the call.
>
> Note we need upstream update first for patch 3 (github.com/libbpf/usdt),
> if we decide to take this change.
>
> thanks,
> jirka
>
>
> v1: https://lore.kernel.org/bpf/20260514135342.22130-1-jolsa@kernel.org/
> v2: https://lore.kernel.org/bpf/20260518105957.123445-1-jolsa@kernel.org/
> v3: https://lore.kernel.org/bpf/20260521124411.31133-1-jolsa@kernel.org/
> v4: https://lore.kernel.org/bpf/20260526205840.173790-1-jolsa@kernel.org/
>
> v5 changes:
> - several selftests changes and reviewed-by tags [Jakub]
> - add more comments in int3_update_unoptimize [Andrii]
> - several other minor changes and acks [Oleg]
> - move insn_decode out of uprobe_init_insn to simplify the code
> - align uprobe_red_zone_test to 64 to make sure nop10 is not on page boundary
>
> v4 changes:
> - do not use 2nd int3 (ont +5 offset) because the call instruction
> is allways the same for the given nop10 address [Andrii/Peter]
> - unmap unused trampoline vma after unsuccesfull optimization [sashiko]
> - small change to patch#2 moved user_64bit_mode earlier in the path
> and pass/use mm_struct pointer directly from arch_uprobe_optimize
> instead of gettting current->mm
> Andrii, keeping your ack, please shout otherwise
>
> v3 changes:
> - use nop10 update suggested by Peter in [2]
> - remove struct uprobe_trampoline object, use vma objects directly instead
> - selftests fixes [sashiko]
> - ack from Andrii
>
> v2 changes:
> - several selftest fixes [sashiko]
> - consolidate is_lea_insn and is_call_insn insto single check [Jakub Sitnicki]
> - use proper mm_struct object in __in_uprobe_trampoline check [sashiko]
> - allow to copy uprobe trampolines vma objects on fork [sashiko]
> - change uprobe syscall detection error from -ENXIO to -EPROTO [Andrii]
> - added fork/clone tests
> - I kept the selftest changes and nop5->nop10 changes in separate
> commits for easier review, we can squash them later if we want to keep
> bisect working properly
>
>
> [1] https://lore.kernel.org/bpf/20260509003146.976844-1-andrii@kernel.org/
> [2] https://lore.kernel.org/bpf/20260518104306.GU3102624@noisy.programming.kicks-ass.net/#t
> ---
ASAN-enabled test_progs runs are not happy in CI, can you please check?
> Andrii Nakryiko (1):
> selftests/bpf: Add tests for uprobe nop10 red zone clobbering
>
> Jiri Olsa (12):
> uprobes/x86: Use proper mm_struct in __in_uprobe_trampoline
> uprobes/x86: Remove struct uprobe_trampoline object
> uprobes/x86: Do not leak trampoline vma mapping on optimization failure
> uprobes/x86: Allow to copy uprobe trampolines on fork
> uprobes/x86: Move optimized uprobe from nop5 to nop10
> libbpf: Change has_nop_combo to work on top of nop10
> libbpf: Detect uprobe syscall with new error
> selftests/bpf: Emit nop,nop10 instructions combo for x86_64 arch
> selftests/bpf: Change uprobe syscall tests to use nop10
> selftests/bpf: Change uprobe/usdt trigger bench code to use nop10
> selftests/bpf: Add reattach tests for uprobe syscall
> selftests/bpf: Add tests for forked/cloned optimized uprobes
>
> arch/x86/kernel/uprobes.c | 416 +++++++++++++++++++++++++++++++++++++++++++-----------------------------
> include/linux/uprobes.h | 5 -
> kernel/events/uprobes.c | 10 --
> kernel/fork.c | 1 -
> tools/lib/bpf/features.c | 4 +-
> tools/lib/bpf/usdt.c | 16 +--
> tools/testing/selftests/bpf/bench.c | 20 ++--
> tools/testing/selftests/bpf/benchs/bench_trigger.c | 38 +++----
> tools/testing/selftests/bpf/benchs/run_bench_uprobes.sh | 2 +-
> tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c | 326 ++++++++++++++++++++++++++++++++++++++++++++++++++++----
> tools/testing/selftests/bpf/prog_tests/usdt.c | 74 +++++++++++--
> tools/testing/selftests/bpf/progs/test_usdt.c | 25 +++++
> tools/testing/selftests/bpf/usdt.h | 2 +-
> tools/testing/selftests/bpf/usdt_2.c | 15 ++-
> 14 files changed, 698 insertions(+), 256 deletions(-)
^ permalink raw reply
* Re: [RFC PATCH 2/4] tracing/probes: Compile all fetchargs into a single BPF program per event
From: Alexei Starovoitov @ 2026-07-02 0:01 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Steven Rostedt, Shuah Khan, Mathieu Desnoyers, LKML,
linux-trace-kernel, open list:KERNEL SELFTEST FRAMEWORK, bpf
In-Reply-To: <20260702074007.e1047c9d66cbcecc7d4ab3a9@kernel.org>
On Wed, Jul 1, 2026 at 3:40 PM Masami Hiramatsu <mhiramat@kernel.org> wrote:
>
> On Wed, 01 Jul 2026 11:41:26 -0700
> "Alexei Starovoitov" <alexei.starovoitov@gmail.com> wrote:
>
> >
> > Nack.
> > I really don't like it.
> > There were days in the past when the kernel generating bpf directly was appealing.
> > These days are gone. Performance improvements for fetchargs is not a good reason
> > to add all this complexity and bypass verifier checks.
> > bpf insns should come from user space.
>
> Thanks for your comment!
> OK, I don't mind because this is a kind of investigation project. And some
> people had asked me about the same idea, now I can tell them the result.
>
> I'm satisfied with the current outcome, as this development process gave me
> insight into the implementation of BPF and demonstrated the potential for
> optimization via JIT. :)
>
> And also, as noted in the cover letter, the current performance of fetcharg
> is better than I thought, and is good enough for debugging. :)
>
> BTW, I'm also interested in calling the verifier on this generated code.
> Even it it is not merged, I think showing the correct way to implement it
> will be useful in the future.
The whole feature you're trying to do is imo reinvention of the wheel.
bpf could do that kind of filtering years ago.
I don't buy the excuse that embedded environments without any
kind of user space needs this facility.
^ permalink raw reply
* Re: [RFC PATCH 2/4] tracing/probes: Compile all fetchargs into a single BPF program per event
From: Masami Hiramatsu @ 2026-07-02 1:01 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Steven Rostedt, Shuah Khan, Mathieu Desnoyers, LKML,
linux-trace-kernel, open list:KERNEL SELFTEST FRAMEWORK, bpf
In-Reply-To: <CAADnVQLUniyTM64gHrLzgjWiNZTB82tT0LCxh8D29YfXG7cZ6w@mail.gmail.com>
On Wed, 1 Jul 2026 17:01:01 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> On Wed, Jul 1, 2026 at 3:40 PM Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >
> > On Wed, 01 Jul 2026 11:41:26 -0700
> > "Alexei Starovoitov" <alexei.starovoitov@gmail.com> wrote:
> >
> > >
> > > Nack.
> > > I really don't like it.
> > > There were days in the past when the kernel generating bpf directly was appealing.
> > > These days are gone. Performance improvements for fetchargs is not a good reason
> > > to add all this complexity and bypass verifier checks.
> > > bpf insns should come from user space.
> >
> > Thanks for your comment!
> > OK, I don't mind because this is a kind of investigation project. And some
> > people had asked me about the same idea, now I can tell them the result.
> >
> > I'm satisfied with the current outcome, as this development process gave me
> > insight into the implementation of BPF and demonstrated the potential for
> > optimization via JIT. :)
> >
> > And also, as noted in the cover letter, the current performance of fetcharg
> > is better than I thought, and is good enough for debugging. :)
> >
> > BTW, I'm also interested in calling the verifier on this generated code.
> > Even it it is not merged, I think showing the correct way to implement it
> > will be useful in the future.
>
> The whole feature you're trying to do is imo reinvention of the wheel.
> bpf could do that kind of filtering years ago.
> I don't buy the excuse that embedded environments without any
> kind of user space needs this facility.
>
Yeah, I understood it. I have no intention to merge this series.
This is totally just for fun and my interest about BPF.
But thanks for your comments. It is good to hear your thought in the RFC
stage. I can stop this series here with peace of mind. :)
Thank you!
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/1] tracing: Prevent out-of-bounds read in glob matching
From: Masami Hiramatsu @ 2026-07-02 1:15 UTC (permalink / raw)
To: Ren Wei
Cc: linux-kernel, linux-trace-kernel, rostedt, mhiramat,
mathieu.desnoyers, akpm, namhyung, yuantan098, yifanwucs,
tomapufckgml, zcliangcn, bird, hhhuang
In-Reply-To: <da1aaf125fc3b63320b0c540fd6afa7c3d5b4f1a.1782836943.git.hhhuang@smu.edu.sg>
On Wed, 1 Jul 2026 18:28:46 +0800
Ren Wei <n05ec@lzu.edu.cn> wrote:
> From: Huihui Huang <hhhuang@smu.edu.sg>
>
> String event fields are not necessarily NUL-terminated, so the filter
> predicate functions (filter_pred_string(), filter_pred_strloc() and
> filter_pred_strrelloc()) pass the field length to the regex match
> callbacks, and the length-aware matchers honour it.
>
> regex_match_glob() was the exception: it ignored the length and called
> glob_match(), which scans the string until it hits a NUL byte. Some
> string fields are not NUL-terminated. One example is the dynamic char
> array of the xfs_* namespace tracepoints, which is copied without a
> trailing NUL. For such a field, glob matching reads past the end of
> the event field, causing a KASAN slab-out-of-bounds read in
> glob_match(), reached via regex_match_glob() and filter_match_preds()
> from the xfs_lookup tracepoint.
>
> Add a length-bounded glob_match_len() and use it from regex_match_glob()
> so glob matching always stops at the field boundary. The matching loop
> is factored into a shared helper so glob_match() keeps its behaviour.
>
Looks good to me.
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Thank you,
> Fixes: 60f1d5e3bac4 ("ftrace: Support full glob matching")
> Cc: stable@vger.kernel.org
> Reported-by: Yuan Tan <yuantan098@gmail.com>
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
> Reported-by: Xin Liu <bird@lzu.edu.cn>
> Assisted-by: Codex:GPT-5.4
> Signed-off-by: Huihui Huang <hhhuang@smu.edu.sg>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
> ---
> include/linux/glob.h | 1 +
> kernel/trace/trace_events_filter.c | 6 ++----
> lib/glob.c | 31 ++++++++++++++++++++++++++++--
> 3 files changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/glob.h b/include/linux/glob.h
> index 861327b33e..91595e7509 100644
> --- a/include/linux/glob.h
> +++ b/include/linux/glob.h
> @@ -6,5 +6,6 @@
> #include <linux/compiler.h> /* For __pure */
>
> bool __pure glob_match(char const *pat, char const *str);
> +bool __pure glob_match_len(char const *pat, char const *str, size_t len);
>
> #endif /* _LINUX_GLOB_H */
> diff --git a/kernel/trace/trace_events_filter.c b/kernel/trace/trace_events_filter.c
> index 609325f579..6385cd662d 100644
> --- a/kernel/trace/trace_events_filter.c
> +++ b/kernel/trace/trace_events_filter.c
> @@ -1056,11 +1056,9 @@ static int regex_match_end(char *str, struct regex *r, int len)
> return 0;
> }
>
> -static int regex_match_glob(char *str, struct regex *r, int len __maybe_unused)
> +static int regex_match_glob(char *str, struct regex *r, int len)
> {
> - if (glob_match(r->pattern, str))
> - return 1;
> - return 0;
> + return glob_match_len(r->pattern, str, len) ? 1 : 0;
> }
>
> /**
> diff --git a/lib/glob.c b/lib/glob.c
> index 7aca76c25b..c80d9dd736 100644
> --- a/lib/glob.c
> +++ b/lib/glob.c
> @@ -11,6 +11,9 @@
> MODULE_DESCRIPTION("glob(7) matching");
> MODULE_LICENSE("Dual MIT/GPL");
>
> +static bool __pure glob_match_str(char const *pat, char const *str,
> + char const *str_end);
> +
> /**
> * glob_match - Shell-style pattern matching, like !fnmatch(pat, str, 0)
> * @pat: Shell-style pattern to match, e.g. "*.[ch]".
> @@ -40,6 +43,29 @@ MODULE_LICENSE("Dual MIT/GPL");
> * An opening bracket without a matching close is matched literally.
> */
> bool __pure glob_match(char const *pat, char const *str)
> +{
> + return glob_match_str(pat, str, NULL);
> +}
> +EXPORT_SYMBOL(glob_match);
> +
> +/**
> + * glob_match_len - glob match against a length-bounded string
> + * @pat: Shell-style pattern to match.
> + * @str: String to match. Need not be NUL-terminated.
> + * @len: Number of bytes of @str that may be read.
> + *
> + * Like glob_match(), but @str is only read up to @len bytes, so it can be
> + * used on buffers that are not NUL-terminated (e.g. trace event fields).
> + * A NUL byte within @len still terminates the string.
> + */
> +bool __pure glob_match_len(char const *pat, char const *str, size_t len)
> +{
> + return glob_match_str(pat, str, str + len);
> +}
> +EXPORT_SYMBOL(glob_match_len);
> +
> +static bool __pure glob_match_str(char const *pat, char const *str,
> + char const *str_end)
> {
> /*
> * Backtrack to previous * on mismatch and retry starting one
> @@ -55,9 +81,11 @@ bool __pure glob_match(char const *pat, char const *str)
> * on mismatch, or true after matching the trailing nul bytes.
> */
> for (;;) {
> - unsigned char c = *str++;
> + unsigned char c = (str_end && str >= str_end) ? '\0' : *str;
> unsigned char d = *pat++;
>
> + str++;
> +
> switch (d) {
> case '?': /* Wildcard: anything but nul */
> if (c == '\0')
> @@ -125,4 +153,3 @@ bool __pure glob_match(char const *pat, char const *str)
> }
> }
> }
> -EXPORT_SYMBOL(glob_match);
> --
> 2.50.1
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* [PATCH v2] selftests/ftrace: fix spelling error in poll test comment
From: Wang Yan @ 2026-07-02 1:56 UTC (permalink / raw)
To: rostedt, mhiramat, mathieu.desnoyers, shuah
Cc: linux-trace-kernel, linux-kselftest, linux-kernel, Wang Yan
Fix typo "happned" -> "happened" in ftrace poll test comment.
Signed-off-by: Wang Yan <wangyan01@kylinos.cn>
---
tools/testing/selftests/ftrace/poll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/ftrace/poll.c b/tools/testing/selftests/ftrace/poll.c
index 53258f7515e7..4da86a20dc85 100644
--- a/tools/testing/selftests/ftrace/poll.c
+++ b/tools/testing/selftests/ftrace/poll.c
@@ -66,7 +66,7 @@ int main(int argc, char *argv[])
}
close(pfd.fd);
- /* If timeout happned (ret == 0), exit code is 1 */
+ /* If timeout happened (ret == 0), exit code is 1 */
if (ret == 0)
return 1;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v2] selftests/ftrace: fix spelling error in poll test comment
From: Masami Hiramatsu @ 2026-07-02 5:27 UTC (permalink / raw)
To: shuah, Wang Yan
Cc: rostedt, mathieu.desnoyers, linux-trace-kernel, linux-kselftest,
linux-kernel
In-Reply-To: <20260702015634.366201-1-wangyan01@kylinos.cn>
Hi,
This looks good to me.
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Shuah, can you pick this through your tree?
Thank you,
On Thu, 2 Jul 2026 09:56:34 +0800
Wang Yan <wangyan01@kylinos.cn> wrote:
> Fix typo "happned" -> "happened" in ftrace poll test comment.
>
> Signed-off-by: Wang Yan <wangyan01@kylinos.cn>
> ---
> tools/testing/selftests/ftrace/poll.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/ftrace/poll.c b/tools/testing/selftests/ftrace/poll.c
> index 53258f7515e7..4da86a20dc85 100644
> --- a/tools/testing/selftests/ftrace/poll.c
> +++ b/tools/testing/selftests/ftrace/poll.c
> @@ -66,7 +66,7 @@ int main(int argc, char *argv[])
> }
> close(pfd.fd);
>
> - /* If timeout happned (ret == 0), exit code is 1 */
> + /* If timeout happened (ret == 0), exit code is 1 */
> if (ret == 0)
> return 1;
>
> --
> 2.25.1
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 12/13] rv: Fix read_lock scope in per-task DA cleanup
From: Gabriele Monaco @ 2026-07-02 6:31 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linux-kernel, linux-trace-kernel, Wen Yang, Nam Cao
In-Reply-To: <20260701152705.6dc9d8f2@gandalf.local.home>
On Wed, 2026-07-01 at 15:27 -0400, Steven Rostedt wrote:
> On Mon, 1 Jun 2026 17:38:39 +0200
> Gabriele Monaco <gmonaco@redhat.com> wrote:
>
> > The da_monitor_reset_all() function for per-task monitors takes
> > tasklist_lock while iterating over tasks, then keeps it also while
> > iterating over idle tasks (one per CPU). The latter is not necessary
> > since the lock needs to guard only for_each_process_thread().
> >
> > Use a scoped_guard for more compact syntax and adjust the scope only
> > where the lock is necessary.
> >
> > Reviewed-by: Wen Yang <wen.yang@linux.dev>
> > Reviewed-by: Nam Cao <namcao@linutronix.de>
> > Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
>
> Hmm, this and patch 13 didn't get applied. Do you plan on sending them later?
Yes, I didn't add them to the pull request since they weren't quite fixes, then
ended up not sending a "normal" pull request for 7.2 just for these.
I'm going to put them together for the next round.
Thanks,
Gabriele
^ permalink raw reply
* Re: [PATCHv4 00/13] uprobes/x86: Fix red zone issue for optimized uprobes
From: Peter Zijlstra @ 2026-07-02 7:20 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Jiri Olsa, Ingo Molnar, Masami Hiramatsu, Oleg Nesterov,
Andrii Nakryiko, bpf, linux-trace-kernel
In-Reply-To: <CAEf4BzYmgj55UnBX2fRoKwtc-97vc7Sf1opWcAXzSKKLr_Ei6A@mail.gmail.com>
On Thu, Jun 25, 2026 at 10:44:18PM -0700, Andrii Nakryiko wrote:
> On Mon, Jun 8, 2026 at 1:48 PM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
> >
> > On Wed, Jun 3, 2026 at 11:59 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> > >
> > > On Tue, May 26, 2026 at 10:58:27PM +0200, Jiri Olsa wrote:
> > > > hi,
> > > > Andrii reported an issue with optimized uprobes [1] that can clobber
> > > > redzone area with call instruction storing return address on stack
> > > > where user code may keep temporary data without adjusting rsp.
> > > >
> > > > Fixing this by moving the optimized uprobes on top of 10-bytes nop
> > > > instruction, so we can squeeze another instruction to escape the
> > > > redzone area before doing the call.
> > > >
> > > > Note we need upstream update first for patch 3 (github.com/libbpf/usdt),
> > > > if we decide to take this change.
> > > >
> > > > thanks,
> > > > jirka
> > > >
> > > >
> > > > v1: https://lore.kernel.org/bpf/20260514135342.22130-1-jolsa@kernel.org/
> > > > v2: https://lore.kernel.org/bpf/20260518105957.123445-1-jolsa@kernel.org/
> > > > v3: https://lore.kernel.org/bpf/20260521124411.31133-1-jolsa@kernel.org/
> > > >
> > > > v4 changes:
> > > > - do not use 2nd int3 (ont +5 offset) because the call instruction
> > > > is allways the same for the given nop10 address [Andrii/Peter]
> > > > - unmap unused trampoline vma after unsuccesfull optimization [sashiko]
> > > > - small change to patch#2 moved user_64bit_mode earlier in the path
> > > > and pass/use mm_struct pointer directly from arch_uprobe_optimize
> > > > instead of gettting current->mm
> > > > Andrii, keeping your ack, please shout otherwise
> > >
> > > hi,
> > > I think bots did not find anything substantial, I have just small
> > > selftests changes queued for v5
> > >
> > > any other feedback/review would be great
> > >
> >
> > one small nit on only, otherwise LGTM.
> >
> > Peter, Masami, Ingo, should this go through tip tree or should we
> > route this through bpf-next tree? I think we are fine either way, but
> > might be more convenient to route through bpf-next given libbpf and
> > BPF selftest changes.
> >
>
> I'll assume that no one has any objections to route this through
> bpf-next. We got reviews from Oleg, so that's great. Jiri, seems like
> you will do small adjustments and send v5, please do, and then unless
> meanwhile no one raises any issues, this will go through bpf-next.
> Thanks!
Is it already applied? If not, I can stick it in tip/perf/core (and the
first in /urgent).
^ 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