* Re: [PATCH v3 09/17] rv: Add KUnit tests for some DA/HA monitors
From: Nam Cao @ 2026-07-07 6:52 UTC (permalink / raw)
To: Gabriele Monaco, linux-trace-kernel, linux-kernel, Steven Rostedt,
Gabriele Monaco, Masami Hiramatsu
Cc: Thomas Weissschuh, Tomas Glozar, John Kacur, Wen Yang
In-Reply-To: <20260625121440.116317-10-gmonaco@redhat.com>
Gabriele Monaco <gmonaco@redhat.com> writes:
> + * Automatically generated by rvgen kunit.
I was slightly confused by this, as I wasn't aware that rvgen can
generate this.
The patch adding generation support into rvgen should be before
this patch. But oh well, no big deal.
Reviewed-by: Nam Cao <namcao@linutronix.de>
^ permalink raw reply
* Re: [PATCH 0/4] tracing: add ref_trace_final_put tracing
From: Eugene Mavick @ 2026-07-07 6:18 UTC (permalink / raw)
To: Eugene Mavick, Will Deacon, Peter Zijlstra, Boqun Feng,
Mark Rutland, Gary Guo, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Andrew Morton, Dennis Zhou, Tejun Heo,
Christoph Lameter
Cc: linux-kernel, linux-trace-kernel, linux-mm
In-Reply-To: <20260705-refcount-final-put-trace-v1-0-cdd0014626a9@mavick.dev>
I apologise for the duplicate patch series submission, I had resent the
v1 via b4 relay as it did not show up on lore.kernel.org for a
day, and I assumed the emails were lost.
^ permalink raw reply
* [PATCH net-next] net/tcp: Add explicit tracepoint for tcp_syn_ack_timeout()
From: Emil Tsalapatis @ 2026-07-07 1:01 UTC (permalink / raw)
To: netdev, linux-trace-kernel
Cc: edumazet, ncardwell, kuniyu, rostedt, mhiramat, davem, kuba,
pabeni, Emil Tsalapatis
Clang can inline the tcp_syn_ack_timeout() function during compilation,
making it impossible to use kprobes for tracing without preventing
inlining. Add an explicit tracepoint to it instead.
Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com>
---
include/trace/events/tcp.h | 72 ++++++++++++++++++++++++++++++++++++++
net/ipv4/tcp_timer.c | 3 ++
2 files changed, 75 insertions(+)
diff --git a/include/trace/events/tcp.h b/include/trace/events/tcp.h
index f155f95cdb6e..37ffaa50faad 100644
--- a/include/trace/events/tcp.h
+++ b/include/trace/events/tcp.h
@@ -332,6 +332,78 @@ TRACE_EVENT(tcp_retransmit_synack,
__entry->saddr_v6, __entry->daddr_v6)
);
+TRACE_EVENT(tcp_syn_ack_timeout,
+
+ TP_PROTO(const struct request_sock *req),
+
+ TP_ARGS(req),
+
+ TP_STRUCT__entry(
+ __field(const void *, req)
+ __field(__u16, sport)
+ __field(__u16, dport)
+ __field(__u16, family)
+ __array(__u8, saddr, 4)
+ __array(__u8, daddr, 4)
+ __array(__u8, saddr_v6, 16)
+ __array(__u8, daddr_v6, 16)
+ __field(u8, state)
+ __field(u8, num_timeout)
+ __field(bool, acked)
+ ),
+
+
+ TP_fast_assign(
+ const struct inet_request_sock *ireq = inet_rsk(req);
+ __be32 *p32;
+
+ __entry->req = req;
+
+ __entry->sport = ireq->ir_num;
+ __entry->dport = ntohs(ireq->ir_rmt_port);
+ __entry->family = req->__req_common.skc_family;
+
+ p32 = (__be32 *) __entry->saddr;
+ *p32 = ireq->ir_loc_addr;
+
+ p32 = (__be32 *) __entry->daddr;
+ *p32 = ireq->ir_rmt_addr;
+
+#if IS_ENABLED(CONFIG_IPV6)
+ /*
+ * Cannot use TP_STORE_ADDRS directly because it assumes
+ * there is an sk available.
+ */
+ if (__entry->family == AF_INET6) {
+ struct in6_addr *pin6;
+
+ pin6 = (struct in6_addr *)__entry->saddr_v6;
+ *pin6 = ireq->ir_v6_loc_addr;
+ pin6 = (struct in6_addr *)__entry->daddr_v6;
+ *pin6 = ireq->ir_v6_rmt_addr;
+ } else {
+ TP_STORE_V4MAPPED(__entry, ireq->ir_loc_addr, ireq->ir_rmt_addr);
+ }
+#else
+ TP_STORE_V4MAPPED(__entry, ireq->ir_loc_addr, ireq->ir_rmt_addr);
+#endif
+
+ __entry->state = ireq->ireq_state;
+ __entry->num_timeout = req->num_timeout;
+ __entry->acked = ireq->acked;
+ ),
+
+ TP_printk("family=%s sport=%hu dport=%hu saddr=%pI4 "
+ "daddr=%pI4 saddrv6=%pI6c daddrv6=%pI6c "
+ "ireq_state=%s num_timeout=%u acked=%d",
+ show_family_name(__entry->family),
+ __entry->sport, __entry->dport,
+ __entry->saddr, __entry->daddr,
+ __entry->saddr_v6, __entry->daddr_v6,
+ show_tcp_state_name(__entry->state),
+ __entry->num_timeout, __entry->acked)
+);
+
TRACE_EVENT(tcp_sendmsg_locked,
TP_PROTO(const struct sock *sk, const struct msghdr *msg,
const struct sk_buff *skb, int size_goal),
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index bf171b5e1eb3..8f482a6b43e3 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -24,6 +24,7 @@
#include <net/tcp.h>
#include <net/tcp_ecn.h>
#include <net/rstreason.h>
+#include <trace/events/tcp.h>
static u32 tcp_clamp_rto_to_user_timeout(const struct sock *sk)
{
@@ -753,6 +754,8 @@ void tcp_syn_ack_timeout(const struct request_sock *req)
struct net *net = read_pnet(&inet_rsk(req)->ireq_net);
__NET_INC_STATS(net, LINUX_MIB_TCPTIMEOUTS);
+
+ trace_tcp_syn_ack_timeout(req);
}
void tcp_reset_keepalive_timer(struct sock *sk, unsigned long len)
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v8 13/46] KVM: guest_memfd: Add base support for KVM_SET_MEMORY_ATTRIBUTES2
From: Suzuki K Poulose @ 2026-07-06 22:35 UTC (permalink / raw)
To: Ackerley Tng, 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,
aneesh.kumar, liam, Paolo Bonzini, Sean Christopherson,
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
Cc: kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <CAEvNRgFKbKfTMkqh_XF-igm07qYWfRwYJ5SH7wHcLZnqesCzTw@mail.gmail.com>
On 06/07/2026 19:17, Ackerley Tng wrote:
> Suzuki K Poulose <suzuki.poulose@arm.com> writes:
>
>>
>> [...snip...]
>>
>>> +static int __kvm_gmem_set_attributes(struct inode *inode, pgoff_t start,
>>> + size_t nr_pages, uint64_t attrs)
>>> +{
>>> + struct address_space *mapping = inode->i_mapping;
>>> + struct gmem_inode *gi = GMEM_I(inode);
>>> + pgoff_t end = start + nr_pages;
>>> + struct maple_tree *mt;
>>> + struct ma_state mas;
>>> + int r;
>>> +
>>> + mt = &gi->attributes;
>>> +
>>> + filemap_invalidate_lock(mapping);
>>> +
>>> + mas_init(&mas, mt, start);
>>> + r = kvm_gmem_mas_preallocate(&mas, attrs, start, nr_pages);
>>> + if (r)
>>> + goto out;
>>> +
>>> + /*
>>> + * From this point on guest_memfd has performed necessary
>>> + * checks and can proceed to do guest-breaking changes.
>>> + */
>>> +
>>> + kvm_gmem_invalidate_start(inode, start, end);
>>
>> I added support for Arm CCA KVM patches with the inplace conversion and
>> I am hitting the following issue.
>>
>> 1. I am supporting INIT_SHARED + MMAP flags.
>> 2. VMM creates the Gmem_fd with both the flags above.
>> 3. Uses the shared gmem-mmap to load the initial payloads (kernel, dtb).
>> 4. At the VM finalization time, Populate the loaded regions one by one
>> by
>> a) copying the images to a temparory buffer - Since CCA can't really
>> load the contents in-place.
>
> Sounds good :). I see that you blocked this in the kernel by returning
> -EOPNOTSUPP if (!src_page) [0].
We could do the copy in kernel with src_page == dst_page, but that would
affect the batching of Granule delegation (and at which point we might
need a temparory buffer in the kernel as big as the vma_pagesize)
>
>> b) Set the "region" to Private in the gmem_fd (via
>> SET_MEMORY_ATTRIBUTES2)
>> c) Invoke CCA backend to populate the private memory via
>> ioctl(KVM_ARM_RMI_POPULATE,..) [0]
>>
>
> This flow sounds right.
>
>> [0]
>> https://lore.kernel.org/all/20260513131757.116630-27-steven.price@arm.com/
>>
>>
>> 5. Additionally, VMM can mark the entire RAM to be private before the VM
>> starts running, again via SET_MEMORY_ATTRIBUTES2. On CCA, this
>> action is measured and doesn't require the Host to "commit" memory to
>> the VM.
>> Instead the host can lazily donate memory on a fault.
>>
>
> For both TDX and SNP, the host can also lazily donate memory,
> guest_memfd supports this.
>
>> But step (5) triggers the invalidation of both private and shared
>> mappings of the gmem area, from the kvm_gmem_invalidate_start()
>> above.
>>
>> This is because, the entire DRAM now has, some portions PRIVATE (the
>> loaded regions) and the rest are SHARED (from the Gmem_fd creation).
>> Thus, kvm_gmem_get_invalidate_filter(Dram_start, Dram_end) causes the
>> invalidation of both "PRIVATE" and "SHARED" regions, which results
>> in the destruction of the already loaded data and things go south.
>>
>
> This destruction will happen for TDX as well. I think we managed to get
> around this because we didn't apply conversion on the already-private
> ranges.
>
> IIUC on SNP, zapping pages in the stage 2 page tables doesn't destroy
> the data, so that's probably why it has been fine for SNP.
Additionally, the Guest at boot, will try to mark the entire DRAM
as Private (RIPAS_RAM in CCA), which would trigger this anyways.
Suzuki
>
>> When we know that the kvm_gmem_invalidate_xx is triggered by a
>> conversion, we don't need to invalidate the existing pages that
>> are in the requested state. i.e., the following patch on top of
>> this series does the trick for me :
>>
>>
>> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
>> index a97fcac34a0e..62e0427a49f4 100644
>> --- a/virt/kvm/guest_memfd.c
>> +++ b/virt/kvm/guest_memfd.c
>> @@ -250,16 +250,23 @@ static void __kvm_gmem_invalidate_start(struct
>> gmem_file *f, pgoff_t start,
>> KVM_MMU_UNLOCK(kvm);
>> }
>>
>> +static void kvm_gmem_invalidate_start_filter(struct inode *inode,
>> pgoff_t start,
>> + pgoff_t end,
>> + enum kvm_gfn_range_filter
>> attr_filter)
>> +{
>> + struct gmem_file *f;
>> +
>> + kvm_gmem_for_each_file(f, inode)
>> + __kvm_gmem_invalidate_start(f, start, end, attr_filter);
>> +}
>> +
>> static void kvm_gmem_invalidate_start(struct inode *inode, pgoff_t start,
>> pgoff_t end)
>> {
>> enum kvm_gfn_range_filter attr_filter;
>> - struct gmem_file *f;
>> -
>> attr_filter = kvm_gmem_get_invalidate_filter(inode, start, end);
>>
>> - kvm_gmem_for_each_file(f, inode)
>> - __kvm_gmem_invalidate_start(f, start, end, attr_filter);
>> + kvm_gmem_invalidate_start_filter(inode, start, end, attr_filter);
>> }
>>
>> static void __kvm_gmem_invalidate_end(struct gmem_file *f, pgoff_t start,
>> @@ -724,9 +731,14 @@ static int __kvm_gmem_set_attributes(struct inode
>> *inode, pgoff_t start,
>> /*
>> * From this point on guest_memfd has performed necessary
>> * checks and can proceed to do guest-breaking changes.
>> + * Also, we don't have to invalidate the regions that
>> + * may already be in the requested state. Hence, we could
>> + * explicitly filter the invalidations to the opposite
>> + * state.
>> */
>>
>> - kvm_gmem_invalidate_start(inode, start, end);
>> + kvm_gmem_invalidate_start_filter(inode, start, end,
>> + to_private ? KVM_FILTER_SHARED :
>> KVM_FILTER_PRIVATE);
>>
>
> I think this makes sense. Thanks for catching this.
>
>> if (!to_private)
>> kvm_gmem_invalidate(inode, start, end);
>>
>>
>> Thoughts ?
>>
>> Suzuki
>>
>>
>>>
>>> [...snip...]
>>>
^ permalink raw reply
* Re: [PATCH] tracing/user_events: fix use-after-free of enabler in user_event_mm_dup()
From: Michael Bommarito @ 2026-07-06 20:11 UTC (permalink / raw)
To: Steven Rostedt
Cc: Beau Belgrave, XIAO WU, Masami Hiramatsu, Mathieu Desnoyers,
linux-trace-kernel, linux-kernel, stable
In-Reply-To: <20260706160650.2791767d@gandalf.local.home>
On Mon, Jul 6, 2026 at 4:06 PM Steven Rostedt <rostedt@goodmis.org> wrote:
> I'm taking in the OP patch, but this looks like a separate issue.
>
> Any update on this?
Sorry, had gone fishing. I'll have v2 in the next day or so
Thanks,
Mike
^ permalink raw reply
* Re: [PATCH] tracing/user_events: fix use-after-free of enabler in user_event_mm_dup()
From: Steven Rostedt @ 2026-07-06 20:06 UTC (permalink / raw)
To: Beau Belgrave
Cc: XIAO WU, Michael Bommarito, Masami Hiramatsu, Mathieu Desnoyers,
linux-trace-kernel, linux-kernel, stable
In-Reply-To: <20260624200535.GA132-beaub@linux.microsoft.com>
On Wed, 24 Jun 2026 20:05:35 +0000
Beau Belgrave <beaub@linux.microsoft.com> wrote:
> While I cannot repro this locally on my 16 core machine, I do agree this
> case needs to be handled correctly. The enabler should keep the ref to
> the user_event until after an RCU grace period. I have this fix that
> addresses it more completely than the original proposal.
>
> I'm hoping you can try out this fix with your machine that does repro
> the timing window. The below change needs self test fixes, since now the
> free happens after an RCU grace period + work queue schedule. This is
> because the self tests (abi_test and perf_test) assume after unreg the
> last ref is immediate (which was never guaranteed).
I'm taking in the OP patch, but this looks like a separate issue.
Any update on this?
-- Steve
^ permalink raw reply
* Re: [PATCH v5 3/9] mm: use enum migrate_reason instead of int for migration reason parameters
From: David Hildenbrand (Arm) @ 2026-07-06 18:34 UTC (permalink / raw)
To: Ye Liu, Muchun Song, Oscar Salvador, Andrew Morton,
Steven Rostedt, Masami Hiramatsu, Vlastimil Babka
Cc: Zi Yan, Matthew Brost, Joshua Hahn, Rakie Kim, Byungchul Park,
Gregory Price, Ying Huang, Alistair Popple, Lorenzo Stoakes,
Liam R. Howlett, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Mathieu Desnoyers, Brendan Jackman, Johannes Weiner, linux-mm,
linux-kernel, linux-trace-kernel
In-Reply-To: <20260701061101.344679-4-ye.liu@linux.dev>
On 7/1/26 08:10, Ye Liu wrote:
> Replace all 'int reason' function parameters that carry migrate_reason
> values with the proper 'enum migrate_reason' type. This makes the
> intent explicit and leverages compiler type checking. The affected
> subsystems are:
>
> - page_owner: __folio_set_owner_migrate_reason(),
> folio_set_owner_migrate_reason()
> - migrate: migrate_pages(), migrate_pages_sync(),
> migrate_pages_batch(), migrate_folios_move(),
> migrate_hugetlbs(), unmap_and_move_huge_page()
> - hugetlb: move_hugetlb_state(), htlb_allow_alloc_fallback()
> - trace: mm_migrate_pages and mm_migrate_pages_start events
>
> The 'short last_migrate_reason' struct field and internal helper
> parameter in page_owner are intentionally left as 'short' since they
> store per-page metadata where size matters.
>
> No functional change.
>
> Signed-off-by: Ye Liu <ye.liu@linux.dev>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> include/linux/hugetlb.h | 9 +++++----
> include/linux/migrate.h | 6 ++++--
> include/linux/page_owner.h | 7 ++++---
> include/trace/events/migrate.h | 8 ++++----
> mm/hugetlb.c | 3 ++-
> mm/migrate.c | 12 ++++++------
> mm/page_owner.c | 2 +-
> 7 files changed, 26 insertions(+), 21 deletions(-)
>
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 2abaf99321e9..fa828232dfcc 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -154,7 +154,8 @@ long hugetlb_unreserve_pages(struct inode *inode, long start, long end,
> bool folio_isolate_hugetlb(struct folio *folio, struct list_head *list);
> int get_hwpoison_hugetlb_folio(struct folio *folio, bool *hugetlb, bool unpoison);
> void folio_putback_hugetlb(struct folio *folio);
> -void move_hugetlb_state(struct folio *old_folio, struct folio *new_folio, int reason);
> +void move_hugetlb_state(struct folio *old_folio, struct folio *new_folio,
> + enum migrate_reason reason);
Two tabs indent, applies to all other cases in here as well.
Besides the "extern" Lorenzo mentioned, LGTM.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v8 13/46] KVM: guest_memfd: Add base support for KVM_SET_MEMORY_ATTRIBUTES2
From: Ackerley Tng @ 2026-07-06 18:17 UTC (permalink / raw)
To: Suzuki K Poulose, 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, aneesh.kumar, liam, Paolo Bonzini, Sean Christopherson,
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
Cc: kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <114e2488-97ed-4740-a8e8-1edd991f26c5@arm.com>
Suzuki K Poulose <suzuki.poulose@arm.com> writes:
>
> [...snip...]
>
>> +static int __kvm_gmem_set_attributes(struct inode *inode, pgoff_t start,
>> + size_t nr_pages, uint64_t attrs)
>> +{
>> + struct address_space *mapping = inode->i_mapping;
>> + struct gmem_inode *gi = GMEM_I(inode);
>> + pgoff_t end = start + nr_pages;
>> + struct maple_tree *mt;
>> + struct ma_state mas;
>> + int r;
>> +
>> + mt = &gi->attributes;
>> +
>> + filemap_invalidate_lock(mapping);
>> +
>> + mas_init(&mas, mt, start);
>> + r = kvm_gmem_mas_preallocate(&mas, attrs, start, nr_pages);
>> + if (r)
>> + goto out;
>> +
>> + /*
>> + * From this point on guest_memfd has performed necessary
>> + * checks and can proceed to do guest-breaking changes.
>> + */
>> +
>> + kvm_gmem_invalidate_start(inode, start, end);
>
> I added support for Arm CCA KVM patches with the inplace conversion and
> I am hitting the following issue.
>
> 1. I am supporting INIT_SHARED + MMAP flags.
> 2. VMM creates the Gmem_fd with both the flags above.
> 3. Uses the shared gmem-mmap to load the initial payloads (kernel, dtb).
> 4. At the VM finalization time, Populate the loaded regions one by one
> by
> a) copying the images to a temparory buffer - Since CCA can't really
> load the contents in-place.
Sounds good :). I see that you blocked this in the kernel by returning
-EOPNOTSUPP if (!src_page) [0].
> b) Set the "region" to Private in the gmem_fd (via
> SET_MEMORY_ATTRIBUTES2)
> c) Invoke CCA backend to populate the private memory via
> ioctl(KVM_ARM_RMI_POPULATE,..) [0]
>
This flow sounds right.
> [0]
> https://lore.kernel.org/all/20260513131757.116630-27-steven.price@arm.com/
>
>
> 5. Additionally, VMM can mark the entire RAM to be private before the VM
> starts running, again via SET_MEMORY_ATTRIBUTES2. On CCA, this
> action is measured and doesn't require the Host to "commit" memory to
> the VM.
> Instead the host can lazily donate memory on a fault.
>
For both TDX and SNP, the host can also lazily donate memory,
guest_memfd supports this.
> But step (5) triggers the invalidation of both private and shared
> mappings of the gmem area, from the kvm_gmem_invalidate_start()
> above.
>
> This is because, the entire DRAM now has, some portions PRIVATE (the
> loaded regions) and the rest are SHARED (from the Gmem_fd creation).
> Thus, kvm_gmem_get_invalidate_filter(Dram_start, Dram_end) causes the
> invalidation of both "PRIVATE" and "SHARED" regions, which results
> in the destruction of the already loaded data and things go south.
>
This destruction will happen for TDX as well. I think we managed to get
around this because we didn't apply conversion on the already-private
ranges.
IIUC on SNP, zapping pages in the stage 2 page tables doesn't destroy
the data, so that's probably why it has been fine for SNP.
> When we know that the kvm_gmem_invalidate_xx is triggered by a
> conversion, we don't need to invalidate the existing pages that
> are in the requested state. i.e., the following patch on top of
> this series does the trick for me :
>
>
> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index a97fcac34a0e..62e0427a49f4 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
> @@ -250,16 +250,23 @@ static void __kvm_gmem_invalidate_start(struct
> gmem_file *f, pgoff_t start,
> KVM_MMU_UNLOCK(kvm);
> }
>
> +static void kvm_gmem_invalidate_start_filter(struct inode *inode,
> pgoff_t start,
> + pgoff_t end,
> + enum kvm_gfn_range_filter
> attr_filter)
> +{
> + struct gmem_file *f;
> +
> + kvm_gmem_for_each_file(f, inode)
> + __kvm_gmem_invalidate_start(f, start, end, attr_filter);
> +}
> +
> static void kvm_gmem_invalidate_start(struct inode *inode, pgoff_t start,
> pgoff_t end)
> {
> enum kvm_gfn_range_filter attr_filter;
> - struct gmem_file *f;
> -
> attr_filter = kvm_gmem_get_invalidate_filter(inode, start, end);
>
> - kvm_gmem_for_each_file(f, inode)
> - __kvm_gmem_invalidate_start(f, start, end, attr_filter);
> + kvm_gmem_invalidate_start_filter(inode, start, end, attr_filter);
> }
>
> static void __kvm_gmem_invalidate_end(struct gmem_file *f, pgoff_t start,
> @@ -724,9 +731,14 @@ static int __kvm_gmem_set_attributes(struct inode
> *inode, pgoff_t start,
> /*
> * From this point on guest_memfd has performed necessary
> * checks and can proceed to do guest-breaking changes.
> + * Also, we don't have to invalidate the regions that
> + * may already be in the requested state. Hence, we could
> + * explicitly filter the invalidations to the opposite
> + * state.
> */
>
> - kvm_gmem_invalidate_start(inode, start, end);
> + kvm_gmem_invalidate_start_filter(inode, start, end,
> + to_private ? KVM_FILTER_SHARED :
> KVM_FILTER_PRIVATE);
>
I think this makes sense. Thanks for catching this.
> if (!to_private)
> kvm_gmem_invalidate(inode, start, end);
>
>
> Thoughts ?
>
> Suzuki
>
>
>>
>> [...snip...]
>>
^ permalink raw reply
* Re: [PATCH bpf-next 1/2] srcu: Add lock guard for srcu_fast_updown flavor
From: Paul E. McKenney @ 2026-07-06 17:36 UTC (permalink / raw)
To: Puranjay Mohan
Cc: Lai Jiangshan, Josh Triplett, Masami Hiramatsu, Oleg Nesterov,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Alexei Starovoitov, Andrii Nakryiko, Steven Rostedt,
Mathieu Desnoyers, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, rcu, linux-kernel,
linux-trace-kernel, linux-perf-users, bpf
In-Reply-To: <20260706172744.3920417-2-puranjay@kernel.org>
On Mon, Jul 06, 2026 at 10:27:41AM -0700, Puranjay Mohan wrote:
> Add a guard(srcu_fast_updown) definition for scoped
> SRCU-fast-updown read-side critical sections, following the
> existing pattern of guard(srcu) and guard(srcu_fast).
>
> Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
(Or I can take it if you would prefer, but it might be easier and faster
for you to send it along with the next patch.)
> ---
> include/linux/srcu.h | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/linux/srcu.h b/include/linux/srcu.h
> index a54ce9e808b92..72c86d3b23f2e 100644
> --- a/include/linux/srcu.h
> +++ b/include/linux/srcu.h
> @@ -638,4 +638,11 @@ DEFINE_LOCK_GUARD_1(srcu_fast_notrace, struct srcu_struct,
> DECLARE_LOCK_GUARD_1_ATTRS(srcu_fast_notrace, __acquires_shared(_T), __releases_shared(*(struct srcu_struct **)_T))
> #define class_srcu_fast_notrace_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(srcu_fast_notrace, _T)
>
> +DEFINE_LOCK_GUARD_1(srcu_fast_updown, struct srcu_struct,
> + _T->scp = srcu_read_lock_fast_updown(_T->lock),
> + srcu_read_unlock_fast_updown(_T->lock, _T->scp),
> + struct srcu_ctr __percpu *scp)
> +DECLARE_LOCK_GUARD_1_ATTRS(srcu_fast_updown, __acquires_shared(_T), __releases_shared(*(struct srcu_struct **)_T))
> +#define class_srcu_fast_updown_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(srcu_fast_updown, _T)
> +
> #endif
> --
> 2.53.0-Meta
>
^ permalink raw reply
* [PATCH bpf-next 2/2] uprobes: Switch uretprobes_srcu to SRCU-fast-updown
From: Puranjay Mohan @ 2026-07-06 17:27 UTC (permalink / raw)
To: Lai Jiangshan, Paul E. McKenney, Josh Triplett, Masami Hiramatsu,
Oleg Nesterov, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Alexei Starovoitov,
Andrii Nakryiko
Cc: Puranjay Mohan, Steven Rostedt, Mathieu Desnoyers, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, rcu, linux-kernel, linux-trace-kernel,
linux-perf-users, bpf
In-Reply-To: <20260706172744.3920417-1-puranjay@kernel.org>
uretprobes_srcu currently uses normal SRCU, which issues
two smp_mb() per read lock/unlock pair. This overhead is
paid on every uretprobe hit.
Switch to SRCU-fast-updown, which eliminates the per-reader
memory barriers by moving the ordering cost to the
grace-period side (synchronize_rcu() instead of smp_mb()).
This is acceptable because grace periods (uprobe
unregistration) are infrequent compared to reader-side
uretprobe hits.
The updown flavor is required because the SRCU read lock is
taken in prepare_uretprobe() when a return instance is
created and is held until that return instance is finalized.
The traced thread returns to user space in between, so the
lock is inherently released in a different context from
where it was acquired: on the normal return path via
uprobe_handle_trampoline() -> hprobe_finalize(), or from
ri_timer() (expiry) or dup_utask() (fork) via
hprobe_expire(). srcu_down_read_fast() / srcu_up_read_fast()
are designed for this acquire-here / release-elsewhere
pattern and, unlike the same-context srcu_read_lock_fast()
variant, do not carry the lockdep read-side tracking that
would warn on it.
The short, same-context SRCU sections in ri_timer() and
dup_utask() (which guard the uprobe against reuse across the
hprobe_expire() cmpxchg) instead use guard(srcu_fast_updown)
for proper lockdep coverage.
Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
---
include/linux/uprobes.h | 5 +++--
kernel/events/uprobes.c | 29 +++++++++++++++++------------
2 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index f548fea2adec8..f3b07753c2f3d 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -25,6 +25,7 @@ struct mm_struct;
struct inode;
struct notifier_block;
struct page;
+struct srcu_ctr;
/*
* Allowed return values from uprobe consumer's handler callback
@@ -106,7 +107,7 @@ enum hprobe_state {
* underlying uprobe is not guaranteed anymore. __UPROBE_DEAD is just an
* internal marker and is handled transparently by hprobe_fetch() helper.
*
- * When uprobe is SRCU-protected, we also record srcu_idx value, necessary for
+ * When uprobe is SRCU-protected, we also record srcu_scp value, necessary for
* SRCU unlocking.
*
* See hprobe_expire() and hprobe_fetch() for details of race-free uprobe
@@ -115,7 +116,7 @@ enum hprobe_state {
*/
struct hprobe {
enum hprobe_state state;
- int srcu_idx;
+ struct srcu_ctr __percpu *srcu_scp;
struct uprobe *uprobe;
};
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 4084e926e2844..afa491b0bd3f9 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -54,7 +54,7 @@ static struct mutex uprobes_mmap_mutex[UPROBES_HASH_SZ];
DEFINE_STATIC_PERCPU_RWSEM(dup_mmap_sem);
/* Covers return_instance's uprobe lifetime. */
-DEFINE_STATIC_SRCU(uretprobes_srcu);
+DEFINE_STATIC_SRCU_FAST_UPDOWN(uretprobes_srcu);
/* Have a copy of original instruction */
#define UPROBE_COPY_INSN 0
@@ -707,12 +707,13 @@ static void put_uprobe(struct uprobe *uprobe)
}
/* Initialize hprobe as SRCU-protected "leased" uprobe */
-static void hprobe_init_leased(struct hprobe *hprobe, struct uprobe *uprobe, int srcu_idx)
+static void hprobe_init_leased(struct hprobe *hprobe, struct uprobe *uprobe,
+ struct srcu_ctr __percpu *srcu_scp)
{
WARN_ON(!uprobe);
hprobe->state = HPROBE_LEASED;
hprobe->uprobe = uprobe;
- hprobe->srcu_idx = srcu_idx;
+ hprobe->srcu_scp = srcu_scp;
}
/* Initialize hprobe as refcounted ("stable") uprobe (uprobe can be NULL). */
@@ -720,7 +721,7 @@ static void hprobe_init_stable(struct hprobe *hprobe, struct uprobe *uprobe)
{
hprobe->state = uprobe ? HPROBE_STABLE : HPROBE_GONE;
hprobe->uprobe = uprobe;
- hprobe->srcu_idx = -1;
+ hprobe->srcu_scp = NULL;
}
/*
@@ -757,7 +758,7 @@ static void hprobe_finalize(struct hprobe *hprobe, enum hprobe_state hstate)
{
switch (hstate) {
case HPROBE_LEASED:
- __srcu_read_unlock(&uretprobes_srcu, hprobe->srcu_idx);
+ srcu_up_read_fast(&uretprobes_srcu, hprobe->srcu_scp);
break;
case HPROBE_STABLE:
put_uprobe(hprobe->uprobe);
@@ -829,7 +830,7 @@ static struct uprobe *hprobe_expire(struct hprobe *hprobe, bool get)
*/
if (try_cmpxchg(&hprobe->state, &hstate, uprobe ? HPROBE_STABLE : HPROBE_GONE)) {
/* We won the race, we are the ones to unlock SRCU */
- __srcu_read_unlock(&uretprobes_srcu, hprobe->srcu_idx);
+ srcu_up_read_fast(&uretprobes_srcu, hprobe->srcu_scp);
return get ? get_uprobe(uprobe) : uprobe;
}
@@ -2045,7 +2046,7 @@ static void ri_timer(struct timer_list *timer)
struct return_instance *ri;
/* SRCU protects uprobe from reuse for the cmpxchg() inside hprobe_expire(). */
- guard(srcu)(&uretprobes_srcu);
+ guard(srcu_fast_updown)(&uretprobes_srcu);
/* RCU protects return_instance from freeing. */
guard(rcu)();
@@ -2142,7 +2143,7 @@ static int dup_utask(struct task_struct *t, struct uprobe_task *o_utask)
t->utask = n_utask;
/* protect uprobes from freeing, we'll need try_get_uprobe() them */
- guard(srcu)(&uretprobes_srcu);
+ guard(srcu_fast_updown)(&uretprobes_srcu);
p = &n_utask->return_instances;
for (o = o_utask->return_instances; o; o = o->next) {
@@ -2254,8 +2255,8 @@ static void prepare_uretprobe(struct uprobe *uprobe, struct pt_regs *regs,
{
struct uprobe_task *utask = current->utask;
unsigned long orig_ret_vaddr, trampoline_vaddr;
+ struct srcu_ctr __percpu *srcu_scp;
bool chained;
- int srcu_idx;
if (!get_xol_area())
goto free;
@@ -2293,8 +2294,12 @@ static void prepare_uretprobe(struct uprobe *uprobe, struct pt_regs *regs,
orig_ret_vaddr = utask->return_instances->orig_ret_vaddr;
}
- /* __srcu_read_lock() because SRCU lock survives switch to user space */
- srcu_idx = __srcu_read_lock(&uretprobes_srcu);
+ /*
+ * Use srcu_down_read_fast() because the SRCU lock survives a switch to
+ * user space and can be unlocked from a different context by ri_timer()
+ * or dup_utask().
+ */
+ srcu_scp = srcu_down_read_fast(&uretprobes_srcu);
ri->func = instruction_pointer(regs);
ri->stack = user_stack_pointer(regs);
@@ -2303,7 +2308,7 @@ static void prepare_uretprobe(struct uprobe *uprobe, struct pt_regs *regs,
utask->depth++;
- hprobe_init_leased(&ri->hprobe, uprobe, srcu_idx);
+ hprobe_init_leased(&ri->hprobe, uprobe, srcu_scp);
ri->next = utask->return_instances;
rcu_assign_pointer(utask->return_instances, ri);
--
2.53.0-Meta
^ permalink raw reply related
* [PATCH bpf-next 1/2] srcu: Add lock guard for srcu_fast_updown flavor
From: Puranjay Mohan @ 2026-07-06 17:27 UTC (permalink / raw)
To: Lai Jiangshan, Paul E. McKenney, Josh Triplett, Masami Hiramatsu,
Oleg Nesterov, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Alexei Starovoitov,
Andrii Nakryiko
Cc: Puranjay Mohan, Steven Rostedt, Mathieu Desnoyers, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, rcu, linux-kernel, linux-trace-kernel,
linux-perf-users, bpf
In-Reply-To: <20260706172744.3920417-1-puranjay@kernel.org>
Add a guard(srcu_fast_updown) definition for scoped
SRCU-fast-updown read-side critical sections, following the
existing pattern of guard(srcu) and guard(srcu_fast).
Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
---
include/linux/srcu.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/include/linux/srcu.h b/include/linux/srcu.h
index a54ce9e808b92..72c86d3b23f2e 100644
--- a/include/linux/srcu.h
+++ b/include/linux/srcu.h
@@ -638,4 +638,11 @@ DEFINE_LOCK_GUARD_1(srcu_fast_notrace, struct srcu_struct,
DECLARE_LOCK_GUARD_1_ATTRS(srcu_fast_notrace, __acquires_shared(_T), __releases_shared(*(struct srcu_struct **)_T))
#define class_srcu_fast_notrace_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(srcu_fast_notrace, _T)
+DEFINE_LOCK_GUARD_1(srcu_fast_updown, struct srcu_struct,
+ _T->scp = srcu_read_lock_fast_updown(_T->lock),
+ srcu_read_unlock_fast_updown(_T->lock, _T->scp),
+ struct srcu_ctr __percpu *scp)
+DECLARE_LOCK_GUARD_1_ATTRS(srcu_fast_updown, __acquires_shared(_T), __releases_shared(*(struct srcu_struct **)_T))
+#define class_srcu_fast_updown_constructor(_T) WITH_LOCK_GUARD_1_ATTRS(srcu_fast_updown, _T)
+
#endif
--
2.53.0-Meta
^ permalink raw reply related
* [PATCH bpf-next 0/2] uprobes: Switch uretprobes_srcu to SRCU-fast-updown
From: Puranjay Mohan @ 2026-07-06 17:27 UTC (permalink / raw)
To: Lai Jiangshan, Paul E. McKenney, Josh Triplett, Masami Hiramatsu,
Oleg Nesterov, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Alexei Starovoitov,
Andrii Nakryiko
Cc: Puranjay Mohan, Steven Rostedt, Mathieu Desnoyers, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, rcu, linux-kernel, linux-trace-kernel,
linux-perf-users, bpf
uretprobes_srcu currently uses normal SRCU. Normal SRCU issues an
smp_mb() on both srcu_read_lock() and srcu_read_unlock(), i.e. two full
memory barriers per read-side critical section. For uretprobes this cost
is paid on every uretprobe invocation: prepare_uretprobe() takes the
read lock that is later dropped on the normal return path
(hprobe_finalize()) or from ri_timer()/dup_utask() (hprobe_expire()).
Switch uretprobes_srcu to the SRCU-fast-updown flavor. SRCU-fast moves
the read-side ordering off the reader and onto the (rare) grace-period
side: synchronize_srcu() rides on synchronize_rcu() instead of relying
on reader-side smp_mb(). This is a good trade for uretprobes, where
reader-side hits vastly outnumber grace periods (uprobe unregistration).
The updown variant (rather than plain SRCU-fast) is required because the
read lock is acquired in prepare_uretprobe() on the way out to user
space and is released only once the return instance is finalized -- from
a different context than it was taken: the normal return path
(uprobe_handle_trampoline() -> hprobe_finalize()), the timer callback,
or the fork path (ri_timer()/dup_utask() -> hprobe_expire()).
srcu_down_read_fast()/srcu_up_read_fast() are designed for this
semaphore-like, cross-context pattern and, unlike the same-context
srcu_read_lock_fast() variant, do not carry lockdep read-side tracking
that would warn on it -- which is why the old code had to use the raw
__srcu_read_lock() here. For the short, same-context sections in
ri_timer() and dup_utask(), guard(srcu_fast_updown) is used instead,
giving proper lockdep coverage.
Patch 1 adds the guard(srcu_fast_updown) definition, following the
existing guard(srcu)/guard(srcu_fast) pattern.
Patch 2 does the uretprobes_srcu conversion.
Note
----
Only uretprobes_srcu is converted; the main uprobe readers (RB-tree
lookup and consumer-list iteration) are deliberately left on RCU Tasks
Trace. RCU Tasks Trace is already implemented on top of
srcu_read_lock_fast(), so the reader-side cost is identical, and it has
a nesting fast path that the uprobe -> sleepable-BPF-program call chain
relies on (the BPF trampoline takes rcu_read_lock_trace() while uprobes
already holds it; the nested acquire is just a counter bump). Converting
those readers to a separate srcu_struct would turn one real + one nested
lock into two real locks and lose that optimization for no reader-side
gain. uretprobes_srcu is different: it uses normal SRCU (not Tasks
Trace), its readers are long-lived and cross-context, and it genuinely
benefits from dropping the per-reader barriers.
Puranjay Mohan (2):
srcu: Add lock guard for srcu_fast_updown flavor
uprobes: Switch uretprobes_srcu to SRCU-fast-updown
include/linux/srcu.h | 7 +++++++
include/linux/uprobes.h | 5 +++--
kernel/events/uprobes.c | 29 +++++++++++++++++------------
3 files changed, 27 insertions(+), 14 deletions(-)
base-commit: 87bfe634b1193db90e5170e1ddbad04a63ef4501
--
2.53.0-Meta
^ permalink raw reply
* Re: [PATCH 2/2] tracing/synthetic: Free type string on error path
From: Steven Rostedt @ 2026-07-06 17:15 UTC (permalink / raw)
To: Yu Peng
Cc: Masami Hiramatsu, Mathieu Desnoyers, linux-trace-kernel,
linux-kernel
In-Reply-To: <20260603062533.1096320-2-pengyu@kylinos.cn>
On Wed, 3 Jun 2026 14:25:33 +0800
Yu Peng <pengyu@kylinos.cn> wrote:
> parse_synth_field() builds a "__data_loc ..." type string before
> assigning it to field->type. If the seq_buf check fails, the common
> cleanup cannot free the temporary string. Free it before leaving.
>
> Signed-off-by: Yu Peng <pengyu@kylinos.cn>
> ---
> kernel/trace/trace_events_synth.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/trace_events_synth.c b/kernel/trace/trace_events_synth.c
> index cdd5b93328358..dc15658a887cb 100644
> --- a/kernel/trace/trace_events_synth.c
> +++ b/kernel/trace/trace_events_synth.c
> @@ -839,8 +839,10 @@ static struct synth_field *parse_synth_field(int argc, char **argv,
> seq_buf_puts(&s, "__data_loc ");
> seq_buf_puts(&s, field->type);
>
> - if (WARN_ON_ONCE(!seq_buf_buffer_left(&s)))
> + if (WARN_ON_ONCE(!seq_buf_buffer_left(&s))) {
> + kfree(type);
> goto free;
> + }
> s.buffer[s.len] = '\0';
>
> kfree(field->type);
Can you do this instead?
diff --git a/kernel/trace/trace_events_synth.c b/kernel/trace/trace_events_synth.c
index cdd5b9332835..7ff0f00edbdd 100644
--- a/kernel/trace/trace_events_synth.c
+++ b/kernel/trace/trace_events_synth.c
@@ -828,7 +828,7 @@ static struct synth_field *parse_synth_field(int argc, char **argv,
} else if (size == 0) {
if (synth_field_is_string(field->type) ||
synth_field_is_stack(field->type)) {
- char *type;
+ char *type __free(kfree) = NULL;
len = sizeof("__data_loc ") + strlen(field->type) + 1;
type = kzalloc(len, GFP_KERNEL);
@@ -844,7 +844,7 @@ static struct synth_field *parse_synth_field(int argc, char **argv,
s.buffer[s.len] = '\0';
kfree(field->type);
- field->type = type;
+ field->type = no_free_ptr(type);
field->is_dynamic = true;
size = sizeof(u64);
-- Steve
^ permalink raw reply related
* Re: [PATCH v10 6/6] selftests/mm: add hwpoison-panic destructive test
From: Mike Rapoport @ 2026-07-06 16:23 UTC (permalink / raw)
To: Breno Leitao
Cc: Miaohe Lin, Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Vlastimil Babka, Suren Baghdasaryan, Michal Hocko, Shuah Khan,
Naoya Horiguchi, Jonathan Corbet, Shuah Khan, Liam R. Howlett,
lance.yang, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
linux-mm, linux-kernel, linux-doc, linux-kselftest,
linux-trace-kernel, kernel-team
In-Reply-To: <akvSzb0mRSS5aCg_@gmail.com>
On Mon, Jul 06, 2026 at 09:14:22AM -0700, Breno Leitao wrote:
> Hello Mike,
>
> On Sat, Jul 04, 2026 at 12:31:26PM +0300, Mike Rapoport wrote:
> > On Tue, Jun 30, 2026 at 05:46:09AM -0700, Breno Leitao wrote:
>
> > I'm looking at these awk scripts and od encodings and I wonder if wasn't it
> > simpler to write the test in C.
> >
> > We have a bunch of helpers in tools/testing/selftests/mm/vm_utils.h for
> > accessing /proc files and there is already /proc/iomem parser in
> > tools/testing/selftests/mm/pfnmap.c that also could be lifter to vm_util
>
> I'm fine with either approach.
>
> My main concern is keeping the selftest decoupled from the feature
> itself, so that review of the test doesn't block the feature from
> landing. Would that work for you?
Sure.
> Thanks
> --breno
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v10 6/6] selftests/mm: add hwpoison-panic destructive test
From: Breno Leitao @ 2026-07-06 16:14 UTC (permalink / raw)
To: Mike Rapoport
Cc: Miaohe Lin, Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Vlastimil Babka, Suren Baghdasaryan, Michal Hocko, Shuah Khan,
Naoya Horiguchi, Jonathan Corbet, Shuah Khan, Liam R. Howlett,
lance.yang, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
linux-mm, linux-kernel, linux-doc, linux-kselftest,
linux-trace-kernel, kernel-team
In-Reply-To: <akjS7kiGjVwWaWEz@kernel.org>
Hello Mike,
On Sat, Jul 04, 2026 at 12:31:26PM +0300, Mike Rapoport wrote:
> On Tue, Jun 30, 2026 at 05:46:09AM -0700, Breno Leitao wrote:
> I'm looking at these awk scripts and od encodings and I wonder if wasn't it
> simpler to write the test in C.
>
> We have a bunch of helpers in tools/testing/selftests/mm/vm_utils.h for
> accessing /proc files and there is already /proc/iomem parser in
> tools/testing/selftests/mm/pfnmap.c that also could be lifter to vm_util
I'm fine with either approach.
My main concern is keeping the selftest decoupled from the feature
itself, so that review of the test doesn't block the feature from
landing. Would that work for you?
Thanks
--breno
^ permalink raw reply
* Re: [PATCH 2/2] spi: qcom-geni: add GENI SE registers trace event on error paths
From: Konrad Dybcio @ 2026-07-06 15:35 UTC (permalink / raw)
To: Praveen Talari, Bjorn Andersson, Konrad Dybcio, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Mark Brown
Cc: linux-kernel, linux-arm-msm, linux-trace-kernel, linux-spi,
Mukesh Kumar Savaliya, aniket.randive, chandana.chiluveru
In-Reply-To: <20260706-add-tracepoints-for-se-reg-dump-v1-2-48bd08e28cf2@oss.qualcomm.com>
On 7/6/26 1:08 PM, Praveen Talari wrote:
> The GENI SPI driver reports various transfer failures such as command
> timeouts, DMA reset timeouts, DMA transaction errors, and unexpected
> interrupt conditions. However, diagnosing the root cause of these
> failures is difficult as the hardware state is not captured when the
> error occurs.
>
> Add trace_geni_se_regs() calls at critical SPI error handling paths to
> automatically capture GENI serial engine debug registers when failures
> are detected. This includes:
>
> - M_CMD abort/cancel timeout
> - DMA TX/RX FSM reset timeout
> - DMA transaction failures and pending residue conditions
> - Unexpected interrupt error status
> - Premature transfer completion with pending TX/RX data
>
> Dumping the SE debug registers at the time of failure provides
> additional hardware context and significantly improves post-mortem
> analysis of SPI transfer issues without affecting normal operation.
>
> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
> ---
> drivers/spi/spi-geni-qcom.c | 22 ++++++++++++++++++----
> 1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
> index 26e723cfea61..7db0836308c2 100644
> --- a/drivers/spi/spi-geni-qcom.c
> +++ b/drivers/spi/spi-geni-qcom.c
> @@ -3,6 +3,7 @@
>
> #define CREATE_TRACE_POINTS
> #include <trace/events/qcom_geni_spi.h>
> +#include <trace/events/qcom_geni_se.h>
nit: this could be sorted alphabetically (Mark, could you fix
it up while applying?)
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 3/3] rv/reactors: add KUnit tests for reactor_panic
From: Gabriele Monaco @ 2026-07-06 15:00 UTC (permalink / raw)
To: wen.yang; +Cc: Nam Cao, linux-trace-kernel, linux-kernel
In-Reply-To: <810f587d63c84b64067f990299be02b88f5d8106.1781541556.git.wen.yang@linux.dev>
On Tue, 2026-06-16 at 00:44 +0800, wen.yang@linux.dev wrote:
> +/*
> + * Test 2: panic notifier chain is reachable.
> + *
> + * vpanic() calls atomic_notifier_call_chain(&panic_notifier_list, ...).
> + * Drive the chain directly to verify panic notifiers receive the
> notification —
> + * the observable side-effect of reactor_panic without halting the system.
> + */
> +static void test_panic_notifier_called(struct kunit *test)
> +{
> + atomic_notifier_chain_register(&panic_notifier_list, &mock_panic_nb);
> + atomic_notifier_call_chain(&panic_notifier_list, 0,
> + "panic violation message");
> + atomic_notifier_chain_unregister(&panic_notifier_list,
> &mock_panic_nb);
I just realised this isn't even testing the reactor, it's testing the
notifier_chain thing, I don't think we really need this here or am I missing
something?
Thanks,
Gabriele
> +
> + KUNIT_EXPECT_TRUE(test, panic_test_state.notifier_called);
> +}
> +
> +static struct kunit_case reactor_panic_kunit_cases[] = {
> + KUNIT_CASE(test_panic_register_unregister),
> + KUNIT_CASE(test_panic_notifier_called),
> + {}
> +};
> +
> +static struct kunit_suite reactor_panic_kunit_suite = {
> + .name = "rv_reactor_panic",
> + .init = reactor_panic_kunit_init,
> + .test_cases = reactor_panic_kunit_cases,
> +};
> +
> +kunit_test_suite(reactor_panic_kunit_suite);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("KUnit tests for reactor_panic");
^ permalink raw reply
* Re: [PATCH 1/2] soc: qcom: geni-se: trace: Add trace event support for GENI SE registers dump
From: Steven Rostedt @ 2026-07-06 14:59 UTC (permalink / raw)
To: Praveen Talari
Cc: Bjorn Andersson, Konrad Dybcio, Masami Hiramatsu,
Mathieu Desnoyers, Mark Brown, linux-kernel, linux-arm-msm,
linux-trace-kernel, linux-spi, Mukesh Kumar Savaliya,
aniket.randive, chandana.chiluveru
In-Reply-To: <20260706-add-tracepoints-for-se-reg-dump-v1-1-48bd08e28cf2@oss.qualcomm.com>
On Mon, 06 Jul 2026 16:38:12 +0530
Praveen Talari <praveen.talari@oss.qualcomm.com> wrote:
> +TRACE_EVENT(geni_se_regs,
> + TP_PROTO(struct geni_se *se),
> +
> + TP_ARGS(se),
> +
> + TP_STRUCT__entry(__string(geni_se_name, dev_name(se->dev))
> + __field(u32, geni_se_m_cmd0)
> + __field(u32, geni_se_m_irq_status)
> + __field(u32, geni_se_s_cmd0)
> + __field(u32, geni_se_s_irq_status)
> + __field(u32, geni_se_status)
> + __field(u32, geni_se_ios)
> + __field(u32, geni_se_m_cmd_ctrl)
> + __field(u32, geni_se_m_cmd_err)
> + __field(u32, geni_se_m_fw_err)
> + __field(u32, geni_se_tx_fifo_status)
> + __field(u32, geni_se_rx_fifo_status)
> + __field(u32, geni_se_tx_watermark)
> + __field(u32, geni_se_rx_watermark)
> + __field(u32, geni_se_rx_watermark_rfr)
> + __field(u32, geni_se_m_gp_length)
> + __field(u32, geni_se_s_gp_length)
> + __field(u32, geni_se_dma_tx_irq)
> + __field(u32, geni_se_dma_rx_irq)
> + __field(u32, geni_se_dma_tx_irq_en)
> + __field(u32, geni_se_dma_rx_irq_en)
> + __field(u32, geni_se_dma_rx_len)
> + __field(u32, geni_se_dma_rx_len_in)
> + __field(u32, geni_se_dma_tx_len)
> + __field(u32, geni_se_dma_tx_len_in)
> + __field(u32, geni_se_dma_tx_ptr_l)
> + __field(u32, geni_se_dma_tx_ptr_h)
> + __field(u32, geni_se_dma_rx_ptr_l)
> + __field(u32, geni_se_dma_rx_ptr_h)
> + __field(u32, geni_se_dma_tx_attr)
> + __field(u32, geni_se_dma_tx_max_burst)
> + __field(u32, geni_se_dma_rx_attr)
> + __field(u32, geni_se_dma_rx_max_burst)
> + __field(u32, geni_se_dma_if_en)
> + __field(u32, geni_se_dma_if_en_ro)
> + __field(u32, geni_se_dma_general_cfg)
> + __field(u32, geni_se_dma_qsb_trans_cfg)
> + __field(u32, geni_se_dma_dbg)
> + __field(u32, geni_se_m_irq_en)
> + __field(u32, geni_se_s_irq_en)
> + __field(u32, geni_se_gsi_event_en)
> + __field(u32, geni_se_irq_en)
> + __field(u32, geni_se_ser_m_clk_cfg)
> + __field(u32, geni_se_ser_s_clk_cfg)
> + __field(u32, geni_se_general_cfg)
> + __field(u32, geni_se_output_ctrl)
> + __field(u32, geni_se_clk_ctrl_ro)
> + __field(u32, geni_se_fifo_if_disable)
> + __field(u32, geni_se_fw_multilock_msa)
> + __field(u32, geni_se_clk_sel)
> + ),
Wow, a pretty big trace event! But it still fits in the ring buffer.
Acked-by: Steven Rostedt <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH] x86/stacktrace: Mark arch_stack_walk() and unwinder functions notrace
From: Steven Rostedt @ 2026-07-06 14:57 UTC (permalink / raw)
To: Yuanhe Shu
Cc: Josh Poimboeuf, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H . Peter Anvin,
Masami Hiramatsu, linux-kernel, linux-trace-kernel, stable
In-Reply-To: <20260706095445.1683434-1-xiangzao@linux.alibaba.com>
On Mon, 6 Jul 2026 17:54:45 +0800
Yuanhe Shu <xiangzao@linux.alibaba.com> wrote:
> When the function tracer's func_stack_trace option and the function graph
> profiler (function_profile_enabled) are both active, a recursive ftrace
> reentrance can occur, leading to a hard lockup. This was observed during
> ftrace selftest (ftracetest-ktap) execution:
>
> watchdog: Watchdog detected hard LOCKUP on cpu 204
> RIP: profile_graph_entry+0xa0/0x160
> Call Trace:
> function_graph_enter+0xc9/0x120
> arch_ftrace_ops_list_func+0x112/0x230
> ftrace_call+0x5/0x44
> unwind_next_frame+0x5/0x870 <-- traced by ftrace
> arch_stack_walk+0x88/0xf0
> stack_trace_save+0x4b/0x70
> __ftrace_trace_stack+0x12e/0x170
> function_stack_trace_call+0x7c/0xa0
> arch_ftrace_ops_list_func+0x112/0x230
> ftrace_call+0x5/0x44
> irqtime_account_irq+0x5/0xb0
> __irq_exit_rcu+0x12/0xc0
> ...
>
> The root cause is a recursive ftrace reentrance:
> function_stack_trace_call() invokes __trace_stack() ->
> arch_stack_walk() -> unwind_next_frame() to capture a backtrace.
> Since the unwinder functions (__unwind_start(),
> unwind_next_frame(), unwind_get_return_address(),
> unwind_get_return_address_ptr()) are not marked notrace, the
> function graph tracer instruments them, re-entering the ftrace
> infrastructure from within an ftrace callback. This results in a
> hard lockup with interrupts disabled, detected by the watchdog NMI.
I'm fine with this change, but I'm wondering why the recursion protection
didn't catch this. There may be a missing check somewhere. I'll ack this
change, but I also want to add the check that would have prevented this
lockup.
Acked-by: Steven Rostedt <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH 3/3] rv/reactors: add KUnit tests for reactor_panic
From: Gabriele Monaco @ 2026-07-06 14:48 UTC (permalink / raw)
To: wen.yang; +Cc: Nam Cao, linux-trace-kernel, linux-kernel
In-Reply-To: <810f587d63c84b64067f990299be02b88f5d8106.1781541556.git.wen.yang@linux.dev>
On Tue, 2026-06-16 at 00:44 +0800, wen.yang@linux.dev wrote:
> From: Wen Yang <wen.yang@linux.dev>
>
> Add KUnit tests for the panic reactor covering:
> - Reactor registration and unregistration lifecycle
> - Panic notifier chain reachability
>
> The real rv_panic_reaction() calls vpanic(), which is __noreturn and
> halts the system. KUnit cannot test across that boundary. Instead, the
> test drives atomic_notifier_call_chain(&panic_notifier_list, ...) directly
> with a high-priority mock notifier that returns NOTIFY_STOP, verifying
> that the panic notification propagates without triggering real handlers
> (kdump, watchdog, reboot).
>
> The mock notifier busy-waits to simulate real handler execution time
> (e.g., crash_save_vmcoreinfo, emergency_restart preamble) under the
> panic context constraints.
>
> Signed-off-by: Wen Yang <wen.yang@linux.dev>
> ---
> kernel/trace/rv/Kconfig | 10 +++
> kernel/trace/rv/Makefile | 1 +
> kernel/trace/rv/reactor_panic_kunit.c | 106 ++++++++++++++++++++++++++
> 3 files changed, 117 insertions(+)
> create mode 100644 kernel/trace/rv/reactor_panic_kunit.c
>
> diff --git a/kernel/trace/rv/Kconfig b/kernel/trace/rv/Kconfig
> index ff47895c897f..6c6c43c5f86c 100644
> --- a/kernel/trace/rv/Kconfig
> +++ b/kernel/trace/rv/Kconfig
> @@ -121,3 +121,13 @@ config RV_REACT_PANIC
> help
> Enables the panic reactor. The panic reactor emits a printk()
> message if an exception is found and panic()s the system.
> +
> +config RV_REACT_PANIC_KUNIT
> + bool "KUnit tests for reactor_panic" if !KUNIT_ALL_TESTS
> + depends on RV_REACT_PANIC && KUNIT
> + default KUNIT_ALL_TESTS
> + help
> + This builds KUnit tests for the panic reactor. These are only
> + for development and testing, not for regular kernel use cases.
> +
> + If unsure, say N.
> diff --git a/kernel/trace/rv/Makefile b/kernel/trace/rv/Makefile
> index ef0a2dcb927c..2ebfe5e5068c 100644
> --- a/kernel/trace/rv/Makefile
> +++ b/kernel/trace/rv/Makefile
> @@ -25,3 +25,4 @@ obj-$(CONFIG_RV_REACTORS) += rv_reactors.o
> obj-$(CONFIG_RV_REACT_PRINTK) += reactor_printk.o
> obj-$(CONFIG_RV_REACT_PRINTK_KUNIT) += reactor_printk_kunit.o
> obj-$(CONFIG_RV_REACT_PANIC) += reactor_panic.o
> +obj-$(CONFIG_RV_REACT_PANIC_KUNIT) += reactor_panic_kunit.o
> diff --git a/kernel/trace/rv/reactor_panic_kunit.c
> b/kernel/trace/rv/reactor_panic_kunit.c
> new file mode 100644
> index 000000000000..f9a09ae7aaad
> --- /dev/null
> +++ b/kernel/trace/rv/reactor_panic_kunit.c
> @@ -0,0 +1,106 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * KUnit tests for reactor_panic
> + *
> + */
> +
> +#include <kunit/test.h>
> +#include <linux/rv.h>
> +#include <linux/panic_notifier.h>
> +#include <linux/notifier.h>
> +#include <linux/limits.h>
> +#include <linux/sched/clock.h>
> +#include <linux/processor.h>
> +
> +/* Simulated execution time for mock panic notifier (nanoseconds). */
> +#define RV_PANIC_NOTIFIER_EXEC_NS 2000000ULL
> +
> +/* Test state */
> +static struct {
> + bool notifier_called;
> +} panic_test_state;
A struct isn't really needed I guess, but good to have a way to test there was a
call.
> +
> +/*
> + * Mock panic notifier callback.
> + *
> + * Runs at INT_MAX priority and returns NOTIFY_STOP to prevent real panic
> + * handlers (kdump, watchdog) from executing during the test. Busy-waits
> + * RV_PANIC_NOTIFIER_EXEC_NS to simulate a real handler's execution time.
> + */
> +static int mock_panic_notifier_fn(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + char *msg = data;
> + u64 start = sched_clock();
> +
> + panic_test_state.notifier_called = true;
> + pr_emerg("KUnit: reactor_panic test intercepted panic notifier:
> %s\n",
> + msg ? msg : "(no message)");
Since we cannot panic(), do we really need to test yet another mock reactor?
What if you put the notifier_called in the other test and drop this test
altogether?
We can simulate what panic() does right now, but it isn't too representative if
this ever changes.
Also it's good to make this reactor test buildable as a module. Currently some
functions aren't exported, feel free to just EXPORT_SYMBOL_GPL() them. There is
no need not to have modular reactors, just nobody did it before.
Thanks,
Gabriele
> +
> + while (sched_clock() - start < RV_PANIC_NOTIFIER_EXEC_NS)
> + cpu_relax();
> +
> + return NOTIFY_STOP;
> +}
> +
> +static struct notifier_block mock_panic_nb = {
> + .notifier_call = mock_panic_notifier_fn,
> + .priority = INT_MAX,
> +};
> +
> +static struct rv_reactor mock_panic_reactor = {
> + .name = "test_panic",
> + .description = "test panic reactor",
> +};
> +
> +static int reactor_panic_kunit_init(struct kunit *test)
> +{
> + panic_test_state.notifier_called = false;
> + return 0;
> +}
> +
> +/* Test 1: register and unregister reactor */
> +static void test_panic_register_unregister(struct kunit *test)
> +{
> + int ret;
> +
> + ret = rv_register_reactor(&mock_panic_reactor);
> + KUNIT_EXPECT_EQ(test, ret, 0);
> + KUNIT_EXPECT_STREQ(test, mock_panic_reactor.name, "test_panic");
> +
> + rv_unregister_reactor(&mock_panic_reactor);
> +}
> +
> +/*
> + * Test 2: panic notifier chain is reachable.
> + *
> + * vpanic() calls atomic_notifier_call_chain(&panic_notifier_list, ...).
> + * Drive the chain directly to verify panic notifiers receive the
> notification —
> + * the observable side-effect of reactor_panic without halting the system.
> + */
> +static void test_panic_notifier_called(struct kunit *test)
> +{
> + atomic_notifier_chain_register(&panic_notifier_list, &mock_panic_nb);
> + atomic_notifier_call_chain(&panic_notifier_list, 0,
> + "panic violation message");
> + atomic_notifier_chain_unregister(&panic_notifier_list,
> &mock_panic_nb);
> +
> + KUNIT_EXPECT_TRUE(test, panic_test_state.notifier_called);
> +}
> +
> +static struct kunit_case reactor_panic_kunit_cases[] = {
> + KUNIT_CASE(test_panic_register_unregister),
> + KUNIT_CASE(test_panic_notifier_called),
> + {}
> +};
> +
> +static struct kunit_suite reactor_panic_kunit_suite = {
> + .name = "rv_reactor_panic",
> + .init = reactor_panic_kunit_init,
> + .test_cases = reactor_panic_kunit_cases,
> +};
> +
> +kunit_test_suite(reactor_panic_kunit_suite);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("KUnit tests for reactor_panic");
^ permalink raw reply
* Re: [PATCH 2/3] rv/reactors: add KUnit tests for reactor_printk
From: Gabriele Monaco @ 2026-07-06 14:41 UTC (permalink / raw)
To: wen.yang; +Cc: Nam Cao, linux-trace-kernel, linux-kernel
In-Reply-To: <690593305ad075539a804e0bf94493335354e6b9.1781541556.git.wen.yang@linux.dev>
On Tue, 2026-06-16 at 00:44 +0800, wen.yang@linux.dev wrote:
> From: Wen Yang <wen.yang@linux.dev>
>
> Add KUnit tests for the printk reactor covering:
> - Reactor registration and unregistration lifecycle
> - React callback invocation via rv_react()
> - Double registration rejection
> - Multiple register/unregister cycles
>
> The mock callback calls vprintk_deferred() — the same path as the real
> reactor — then busy-waits to simulate I/O back-pressure, exercising the
> LD_WAIT_FREE constraint of rv_react() under load.
>
> Signed-off-by: Wen Yang <wen.yang@linux.dev>
> ---
> kernel/trace/rv/Kconfig | 10 ++
> kernel/trace/rv/Makefile | 1 +
> kernel/trace/rv/reactor_printk_kunit.c | 123 +++++++++++++++++++++++++
> 3 files changed, 134 insertions(+)
> create mode 100644 kernel/trace/rv/reactor_printk_kunit.c
>
> diff --git a/kernel/trace/rv/Kconfig b/kernel/trace/rv/Kconfig
> index 3884b14df375..ff47895c897f 100644
> --- a/kernel/trace/rv/Kconfig
> +++ b/kernel/trace/rv/Kconfig
> @@ -104,6 +104,16 @@ config RV_REACT_PRINTK
> Enables the printk reactor. The printk reactor emits a printk()
> message if an exception is found.
>
> +config RV_REACT_PRINTK_KUNIT
> + bool "KUnit tests for reactor_printk" if !KUNIT_ALL_TESTS
> + depends on RV_REACT_PRINTK && KUNIT
> + default KUNIT_ALL_TESTS
> + help
> + This builds KUnit tests for the printk reactor. These are only
> + for development and testing, not for regular kernel use cases.
> +
> + If unsure, say N.
> +
> config RV_REACT_PANIC
> bool "Panic reactor"
> depends on RV_REACTORS
> diff --git a/kernel/trace/rv/Makefile b/kernel/trace/rv/Makefile
> index 94498da35b37..ef0a2dcb927c 100644
> --- a/kernel/trace/rv/Makefile
> +++ b/kernel/trace/rv/Makefile
> @@ -23,4 +23,5 @@ obj-$(CONFIG_RV_MON_NOMISS) += monitors/nomiss/nomiss.o
> # Add new monitors here
> obj-$(CONFIG_RV_REACTORS) += rv_reactors.o
> obj-$(CONFIG_RV_REACT_PRINTK) += reactor_printk.o
> +obj-$(CONFIG_RV_REACT_PRINTK_KUNIT) += reactor_printk_kunit.o
> obj-$(CONFIG_RV_REACT_PANIC) += reactor_panic.o
> diff --git a/kernel/trace/rv/reactor_printk_kunit.c
> b/kernel/trace/rv/reactor_printk_kunit.c
> new file mode 100644
> index 000000000000..933aa5602226
> --- /dev/null
> +++ b/kernel/trace/rv/reactor_printk_kunit.c
> @@ -0,0 +1,123 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * KUnit tests for reactor_printk
> + *
> + */
> +
> +#include <kunit/test.h>
> +#include <linux/rv.h>
> +#include <linux/printk.h>
> +#include <linux/sched/clock.h>
> +#include <linux/processor.h>
> +
> +/*
> + * Simulated execution time for mock_printk_react (sched_clock units,
> + * nanoseconds). Models the time a real printk reactor callback may consume
> + * under I/O pressure, exercising the LD_WAIT_FREE constraint of rv_react().
> + */
> +#define MOCK_REACT_DURATION_NS 5000000ULL
> +
> +/*
> + * Mock react callback mirroring rv_printk_reaction().
> + *
> + * Calls vprintk_deferred() — the same path as the real reactor — then holds
> + * the CPU for MOCK_REACT_DURATION_NS via a sched_clock() timed busy-loop,
> + * simulating a callback that is slow due to I/O back-pressure.
> + * sched_clock() is notrace and lock-free; no sleep or lock acquisition is
> + * performed, satisfying the LD_WAIT_FREE constraint of rv_react().
> + */
> +__printf(1, 0) static void mock_printk_react(const char *msg, va_list args)
> +{
> + u64 start = sched_clock();
> +
I'm fine testing something that looks like the printk reactor rather than the
real thing, but here sched_clock() is playing with preemption and could trigger
one, this isn't accurate.
I'm not sure all implementations are free from this problem, but why don't you
just use mdelay() here?
> + vprintk_deferred(msg, args);
> +
> + while (sched_clock() - start < MOCK_REACT_DURATION_NS)
> + cpu_relax();
> +}
> +
> +static struct rv_reactor mock_printk_reactor = {
> + .name = "test_printk",
> + .description = "test printk reactor",
> + .react = mock_printk_react,
> +};
> +
> +/* Test 1: register and unregister reactor */
> +static void test_printk_register_unregister(struct kunit *test)
> +{
> + int ret;
> +
> + ret = rv_register_reactor(&mock_printk_reactor);
> + KUNIT_EXPECT_EQ(test, ret, 0);
Yeah checking the return value is the maximum we can do without exporting
internal static functions. I'd say we don't need to be too pedantic on that.
> + KUNIT_EXPECT_STREQ(test, mock_printk_reactor.name, "test_printk");
> +
> + rv_unregister_reactor(&mock_printk_reactor);
> +}
> +
> +/* Test 2: react callback is invoked via rv_react() */
> +static void test_printk_react_called(struct kunit *test)
> +{
> + struct rv_reactor reactor = {
> + .name = "printk_cb_test",
> + .react = mock_printk_react,
> + };
> + struct rv_monitor monitor = {
> + .name = "test_monitor",
> + .reactor = &reactor,
> + .react = mock_printk_react,
> + };
> +
> + rv_react(&monitor, "printk violation message");
> +}
> +
> +/* Test 3: double registration should fail */
> +static void test_printk_double_register(struct kunit *test)
> +{
> + int ret;
> +
> + ret = rv_register_reactor(&mock_printk_reactor);
> + KUNIT_ASSERT_EQ(test, ret, 0);
> +
> + ret = rv_register_reactor(&mock_printk_reactor);
> + KUNIT_EXPECT_NE(test, ret, 0);
> +
> + rv_unregister_reactor(&mock_printk_reactor);
> +}
> +
> +/* Test 4: register/unregister cycle */
> +static void test_printk_register_cycle(struct kunit *test)
> +{
> + int ret, i;
> +
> + for (i = 0; i < 5; i++) {
> + ret = rv_register_reactor(&mock_printk_reactor);
> + KUNIT_EXPECT_EQ(test, ret, 0);
> +
> + rv_unregister_reactor(&mock_printk_reactor);
> + }
> +}
> +
> +/* Test 5: react callback is not NULL (printk reactors must provide react) */
> +static void test_printk_react_not_null(struct kunit *test)
> +{
> + KUNIT_EXPECT_NOT_NULL(test, mock_printk_reactor.react);
As others pointed out, those assertions on a variable you control aren't needed.
Thanks,
Gabriele
> +}
> +
> +static struct kunit_case reactor_printk_kunit_cases[] = {
> + KUNIT_CASE(test_printk_register_unregister),
> + KUNIT_CASE(test_printk_react_called),
> + KUNIT_CASE(test_printk_double_register),
> + KUNIT_CASE(test_printk_register_cycle),
> + KUNIT_CASE(test_printk_react_not_null),
> + {}
> +};
> +
> +static struct kunit_suite reactor_printk_kunit_suite = {
> + .name = "rv_reactor_printk",
> + .test_cases = reactor_printk_kunit_cases,
> +};
> +
> +kunit_test_suite(reactor_printk_kunit_suite);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("KUnit tests for reactor_printk");
^ permalink raw reply
* Re: [PATCH] ufs: core: tracing: Do not dereference pointers in TP_printk()
From: Bart Van Assche @ 2026-07-06 14:22 UTC (permalink / raw)
To: Steven Rostedt, LKML, Linux Trace Kernel, linux-scsi
Cc: Masami Hiramatsu, Mathieu Desnoyers, Alim Akhtar, Avri Altman,
James Bottomley, Martin K. Petersen, Peter Wang
In-Reply-To: <20260630185412.283c26c5@gandalf.local.home>
On 6/30/26 3:54 PM, Steven Rostedt wrote:
> The trace events in drivers/ufs/core/ufs_trace.h were converted to take a
> pointer to the hba structure as an argument for the tracepoint and then in
> TP_printk() the printing of the dev_name from the ring buffer was
> converted to using the dev dereferenced pointer from the hba saved
> pointer.
>
> This is not allowed as the TP_printk() is executed at the time the trace
> event is read from /sys/kernel/tracing/trace file. That can happen
> literally, seconds, minutes, hours, weeks, days, or even months later!
> There is no guarantee that the hba pointer will still exist by the time it
> is dereferenced when the "trace" file is read.
>
> Instead, save the device name from the hba pointer at the time the
> tracepoint is called and place it into the ring buffer event. Then the
> TP_printk() can read the name directly from the ring buffer and remove the
> possibility that it will read a freed pointer and crash the kernel.
>
> This was detected when testing the trace event code that looks for
> TP_printk() parameters doing illegal derferences[1]
>
> [1] https://lore.kernel.org/all/20260630184836.74d477b6@gandalf.local.home/
Thanks Steven!
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
^ permalink raw reply
* Re: [PATCH 1/3] rv/reactors: fix lockdep "Invalid wait context" in rv_react()
From: Gabriele Monaco @ 2026-07-06 14:02 UTC (permalink / raw)
To: Thomas Weißschuh, wen.yang; +Cc: Nam Cao, linux-trace-kernel, linux-kernel
In-Reply-To: <20260623112942-4943fc6a-c1d5-4eed-a91f-66b3a034caa7@linutronix.de>
On Tue, 2026-06-23 at 11:38 +0200, Thomas Weißschuh wrote:
> This now allows reactors to take (raw) spinlocks. The original idea was
> to not allow that as a reactor can be called from LD_WAIT_FREE context.
> So I am not sure this is the right fix. Not that I have a better one
> available right now.
As far as I understand it, LD_WAIT_FREE is fairly impossible to apply on
preemptible code (here we see it hit by an interrupt).
Since we kind of have to allow raw spinlock to avoid this (even if we don't take
them explicitly), why wouldn't a reactor ever be allowed to take raw spinlocks?
Technically it wouldn't be wrong to take locks from RV monitors, although most
monitors don't do it explicitly.
If we ever happen to take the wrong lock explicitly from a reactor triggered by
a nasty event (e.g. sched_switch), I believe lockdep would still be complaining
down that path, so we probably don't need to be too strict in rv_react().
Obviously we don't want to disable interrutps for LD_WAIT_FREE to hold either.
Am I missing something?
Thanks,
Gabriele
^ permalink raw reply
* Re: [PATCH v3 04/11] arm64/mm: Add set_memory_device() and set_memory_normal()
From: Thierry Reding @ 2026-07-06 13:49 UTC (permalink / raw)
To: Will Deacon
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, 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, 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, Chun Ng
In-Reply-To: <akftuw9NyRy36fXA@willie-the-truck>
[-- Attachment #1: Type: text/plain, Size: 4204 bytes --]
On Fri, Jul 03, 2026 at 06:13:31PM +0100, Will Deacon wrote:
> On Thu, Jul 02, 2026 at 06:41:23PM +0200, Thierry Reding wrote:
> > On Thu, Jul 02, 2026 at 03:46:44PM +0200, Thierry Reding wrote:
> > > On Thu, Jul 02, 2026 at 10:18:47AM +0100, Will Deacon wrote:
> > > > On Wed, Jul 01, 2026 at 06:08:15PM +0200, Thierry Reding wrote:
> > > > > From: Chun Ng <chunn@nvidia.com>
> > > > >
> > > > > Add helpers to swap PROT_NORMAL and PROT_DEVICE_nGnRnE protection bits
> > > > > on a kernel-linear-map range.
> > > >
> > > > That sounds like a really terrible idea. Why is this necessary and how
> > > > does it interact with things like load_unaligned_zeropad()?
> > >
> > > This is necessary because once the memory controller has walled off the
> > > new memory region the CPU must not access it under any circumstances or
> > > it'll cause the CPU to lock up (I think technically it'll hit an SError
> > > but in practice that just means it'll freeze, as far as I can tell).
> > >
> > > Probably doesn't interact well at all with load_unaligned_zeropad().
> > >
> > > > I think you should unmap the memory from the linear map and memremap()
> > > > it instead.
> > >
> > > Given that the memory can never be accessed by the CPU after the memory
> > > controller locks it down, I don't think we'll even need memremap(). The
> > > only thing we really need is the sg_table we hand out via the DMA BUFs
> > > so that they can be used by device drivers to program their DMA engines
> > > internally.
> > >
> > > Looking through some of the architecture code around this, shouldn't we
> > > simply be using set_memory_encrypted() and set_memory_decrypted() for
> > > this? While they might've been created for slightly other use-cases,
> > > they seem to be doing exactly what we want (i.e. remove the page range
> > > from the linear mapping and flushing it, or restoring the valid bit and
> > > standard permissions, respectively).
> >
> > Ah... I guess we can't do it because we're not in a realm world and so
> > the early checks in __set_memory_enc_dec() would return early and turn
> > it into a no-op.
> >
> > How about if I extract a common helper and provide set_memory_p() and
> > set_memory_np() in terms of those. Those are available on x86 and
> > PowerPC as well, so fairly standard. I suppose at that point we're
> > closer to set_memory_valid().
>
> Why not just call set_direct_map_invalid_noflush() +
> flush_tlb_kernel_range() for each page? We already have APIs for this.
Having a "standard" helper with a fixed and documented purposed seemed
like a preferable approach for this particular case. We also may want to
make the driver that uses this buildable as a module, in which case we'd
need to export these rather low-level APIs. And then there's also the
fact that we typically call this on a rather large region of memory
(usually something like 512 MiB), so doing it page-by-page is rather
suboptimal.
> The big challenge I see with any linear map manipulation, however, is
> that it will rely on can_set_direct_map() which likely means you need to
> give up some performance and/or security to make this work. Does memory
> become inaccesible dynamically at runtime? If not, the best bet would
> be to describe it as a carveout in the DT and mark it as "no-map" so
> we avoid mapping it in the first place.
VPR exists in two modes: static and resizable. For static VPR we do
exactly that: describe it as carveout in DT with no-map and deal with it
accordingly in the driver. Resizable VPR is for device that have small
amounts of RAM. Content-protected video playback will in the worst case
consume around 1.8 GiB of RAM, so we want to be able to reuse for other
purposes when VPR is unused on those devices. In that case, the memory
is also described as a reserved-memory region in DT, but it is marked as
reusable so that it can be managed by CMA.
The resize operation is fairly slow to begin with because we need to
stall the GPU and put it into reset before the operation, then take it
out of reset and resume it afterwards.
What kind of performance impact do you expect?
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] signal: make send_signal_locked() take const siginfo
From: Bradley Morgan @ 2026-07-06 13:38 UTC (permalink / raw)
To: Oleg Nesterov, Christian Brauner
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Andrew Morton, Peter Zijlstra, Marco Elver, Aleksandr Nogikh,
Thomas Gleixner, Adrian Huang, Kexin Sun, linux-kernel,
linux-trace-kernel
In-Reply-To: <akuusnRXP_tyuiel@redhat.com>
On July 6, 2026 2:33:38 PM GMT+01:00, Oleg Nesterov <oleg@redhat.com>
wrote:
>Just in case, I can't read the code until Wednesday, but...
>
>On 07/06, Christian Brauner wrote:
>>
>> > send_signal_locked() should not change the caller's siginfo. Make that
>> > part of the type and keep the local rewrite on its copy.
>> >
>> > Suggested-by: Oleg Nesterov <oleg@redhat.com>
>> > Signed-off-by: Bradley Morgan <include@grrlz.net>
>>
>> Reviewed-by: Christian Brauner (Amutable) <brauner@kernel.org>
>
>Agreed, but IIRC this change should be rebased on top of -mm tree (I sent
>the patch which changes send_signal_locked(), and thanks for your review
>btw!)
>
>And, again iirc, with that patch "make siginfo const" become really
>trivial,
>we only need to add "const" to every "kernel_siginfo *info" in the
>send_signal_locked()'s callchain.
>
>Oleg.
>
>
Makes sense, thanks a lot.
Thanks!
^ 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