* Re: [PATCH] tracing: Update undefined symbols allow list for simple_ring_buffer
From: Marc Zyngier @ 2026-03-12 15:44 UTC (permalink / raw)
To: Vincent Donnefort
Cc: rostedt, linux-trace-kernel, kvmarm, kernel-team,
Nathan Chancellor
In-Reply-To: <20260312113535.2213350-1-vdonnefort@google.com>
On Thu, 12 Mar 2026 11:35:35 +0000, Vincent Donnefort wrote:
> Undefined symbols are not allowed for simple_ring_buffer.c. But some
> compiler emitted symbols are missing in the allowlist. Update it.
>
>
Applied to next, thanks!
[1/1] tracing: Update undefined symbols allow list for simple_ring_buffer
commit: 5f2f83047126f1cb2986d142d2e76e1fa3cef3f0
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [RFC PATCH v2 09/37] KVM: guest_memfd: Add support for KVM_SET_MEMORY_ATTRIBUTES2
From: Sean Christopherson @ 2026-03-12 15:44 UTC (permalink / raw)
To: Fuad Tabba
Cc: Ackerley Tng, kvm, linux-doc, linux-kernel, linux-kselftest,
linux-trace-kernel, x86, aik, andrew.jones, binbin.wu, bp,
brauner, chao.p.peng, chao.p.peng, chenhuacai, corbet,
dave.hansen, david, hpa, ira.weiny, jgg, jmattson, jroedel,
jthoughton, maobibo, mathieu.desnoyers, maz, mhiramat,
michael.roth, mingo, mlevitsk, oupton, pankaj.gupta, pbonzini,
prsampat, qperret, ricarkol, rick.p.edgecombe, rientjes, rostedt,
shivankg, shuah, steven.price, tglx, vannapurve, vbabka, willy,
wyihan, yan.y.zhao
In-Reply-To: <CA+EHjTy2urW2Tj5czQDKUHdri7FCLfw2mafTgmmtFs+-7ueoiw@mail.gmail.com>
On Thu, Mar 12, 2026, Fuad Tabba wrote:
> Hi Ackerley,
>
> Before getting into the UAPI semantics, thank you for all the heavy
> lifting you've done here. Figuring out how to make it all work across
> the different platforms is not easy :)
>
> <snip>
>
> > The policy definitions below provide more details:
Please drop "CONTENT_POLICY" from the KVM documentation. From KVM's perspective,
these are not "policy", they are purely properties of the underlying memory.
Userspace will likely use the attributes to implement policy of some kind, but
KVM straight up doesn't care.
> > ``KVM_SET_MEMORY_ATTRIBUTES2_CONTENT_POLICY_ZERO`` (default)
The default behavior absolutely cannot be something that's not supported on
every conversion type.
> >
> > On a private to shared conversion, the host will read zeros from the
> > converted memory on the next fault after successful return of the
> > KVM_SET_MEMORY_ATTRIBUTES2 ioctl.
> >
> > This is not supported (-EOPNOTSUPP) for a shared to private
> > conversion. While some CoCo implementations do zero memory contents
> > such that the guest reads zeros after conversion, the guest is not
> > expected to trust host-provided zeroing, hence as a UAPI policy, KVM
> > does not make any such guarantees.
>
> The rationale for not supporting this in the UAPI isn't quite right
> and I think that the prohibition should be removed. It's true that the
> guest is not expected to trust host-provided zeroing. However, if the
> VMM invokes this ioctl with the ZERO policy, the zeroing is performed
> by the hypervisor, not by the (untrusted) host.
What entity zeros the data doesn't matter as far as KVM's ABI is concerned. That's
a motivating favor to providing ZERO, e.g. it allow userspace to elide additional
zeroing when it _knows_ the memory holds zeros, but that's orthogonal to KVM's
contract with userspace.
> Although pKVM handles fresh, zeroed memory provisioning via donation
> rather than attribute conversion, stating that the UAPI cannot make
> guarantees due to trust boundaries is incorrect. The hypervisor is
We should avoid using "hypervisor", because (a) it means different things to
different people and (b) even when there's consensus on what "hypervisor" means,
whether or not the hypervisor is trusted varies per implementation.
> need to be careful witho precisely the entity the guest trusts to enforce
> this.
>
> The UAPI should define the semantics for a shared-to-private ZERO
> conversion, even if current architectures return -EOPNOTSUPP because
> they handle fresh memory provisioning via other mechanisms (like
> pKVM's donation path).
>
> How about something like the following:
>
> On a shared to private conversion, the hypervisor will zero the memory
Again, say _nothing_ about "the hypervisor". _How_ or when anything happens is
completely irrelevant, the only thing that matters here is _what_ happens.
> contents before mapping it into the guest's private address space,
> preventing the untrusted host from injecting arbitrary data into the
> guest. If an architecture handles zeroed-provisioning via mechanisms
> other than attribute conversion, it may return -EOPNOTSUPP.
No. I am 100% against bleeding vendor specific information into KVM's ABI for
this. What the vendor code does is irrelevant, the _only_ thing that matters
here is KVM's contract with userspace.
That doesn't mean pKVM guests can't rely on memory being zeroed, but that is a
contract between pKVM and its guests, not between KVM and host userspace.
> > For testing purposes, the KVM_X86_SW_PROTECTED_VM testing vehicle
> > will support this policy and ensure zeroing for conversions in both
> > directions.
> >
> > ``KVM_SET_MEMORY_ATTRIBUTES2_CONTENT_POLICY_PRESERVE``
> >
> > On private/shared conversions in both directions, memory contents
> > will be preserved and readable. As a concrete example, if the host
> > writes ``0xbeef`` to memory and converts the memory to shared, the
> > guest will also read ``0xbeef``, after any necessary hardware or
> > software provided decryption. After a reverse shared to private
> > conversion, the host will also read ``0xbeef``.
>
> I think that this example is backwards. If the host writes to memory,
> that memory is already shared, isn't it? Converting it to shared is
> redundant. More importantly, if memory undergoes a shared-to-private
> conversion, the host must lose access entirely.
Ya, it's messed up.
> Maybe a clearer example would reflect actual payload injection and
> bounce buffer sharing:
> - Shared-to-Private (Payload Injection): The host writes a payload
> (e.g., 0xbeef) to shared memory and converts it to private. The guest
> reads 0xbeef in its private address space. The host loses access.
> - Private-to-Shared (Bounce Buffer): The guest writes 0xbeef to
> private memory and converts it to shared. The host reads 0xbeef.
>
> > pKVM (ARM) is the first user of this policy. Since pKVM does not
> > protect memory with encryption, a content policy to preserve memory
> > will not will not involve any decryption. The guest will be able to
> > read what the host wrote with full content preservation.
>
> This is correct, but to be precise, I think it should explicitly
> mention Stage-2 page tables as the protection mechanism, maybe:
pKVM shouldn't be mentioned in here at all.
---
By default, KVM makes no guarantees about the in-memory values after memory is
convert to/from shared/private. Optionally, userspace may instruct KVM to
ensure the contents of memory are zeroed or preserved, e.g. to enable in-place
sharing of data, or as an optimization to avoid having to re-zero memory when
the trusted entity guarantees the memory will be zeroed after conversion.
The behaviors supported by a given KVM instance can be queried via <cap>. If
the requested behavior is an unsupported, KVM will return -EOPNOTSUPP and
reject the conversion request. Note! The "ZERO" request is only support for
private to shared conversion!
``KVM_SET_MEMORY_ATTRIBUTES2_ZERO``
On conversion, KVM guarantees all entities that have "allowed" access to the
memory will read zeros. E.g. on private to shared conversion, both trusted
and untrusted code will read zeros.
Zeroing is currently only supported for private-to-shared conversions, as KVM
in general is untrusted and thus cannot guarantee the guest (or any trusted
entity) will read zeros after conversion. Note, some CoCo implementations do
zero memory contents such that the guest reads zeros after conversion, and
the guest may choose to rely on that behavior. But that's a contract between
the trusted CoCo entity and the guest, not between KVM and the guest.
``KVM_SET_MEMORY_ATTRIBUTES2_PRESERVE``
On conversion, KVM guarantees memory contents will be preserved with respect
to the last written unencrypted value. As a concrete example, if the host
writes ``0xbeef`` to shared memory and converts the memory to private, the
guest will also read ``0xbeef``, even if the in-memory data is encrypted as
part of the conversion. And vice versa, if the guest writes ``0xbeef`` to
private memory and then converts the memory to shared, the host (and guest)
will read ``0xbeef`` (if the memory is accessible).
^ permalink raw reply
* Re: [PATCH 13/15] spi: Use trace_invoke_##name() at guarded tracepoint call sites
From: Steven Rostedt @ 2026-03-12 15:42 UTC (permalink / raw)
To: Mark Brown
Cc: Vineeth Pillai (Google), Peter Zijlstra, Michael Hennerich,
Nuno Sá, David Lechner, linux-spi, linux-kernel,
linux-trace-kernel
In-Reply-To: <5d057b07-be5a-4da6-86e3-87ef4319d4b2@sirena.org.uk>
On Thu, 12 Mar 2026 15:34:20 +0000
Mark Brown <broonie@kernel.org> wrote:
> though not loving the naming here, I'll have a hard time figuring out
> what the weird call is about next time I look at that code
Would:
trace_call__foo()
Be better?
Or do you have another name we should use?
-- Steve
^ permalink raw reply
* Re: [PATCH 00/15] tracepoint: Avoid double static_branch evaluation at guarded call sites
From: Steven Rostedt @ 2026-03-12 15:40 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Vineeth Pillai (Google), Peter Zijlstra, Dmitry Ilvokhin,
Masami Hiramatsu, Ingo Molnar, Jens Axboe, io-uring,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexei Starovoitov, Daniel Borkmann, Marcelo Ricardo Leitner,
Xin Long, Jon Maloy, Aaron Conole, Eelco Chaudron, Ilya Maximets,
netdev, bpf, linux-sctp, tipc-discussion, dev, Oded Gabbay,
Koby Elbaz, dri-devel, Rafael J. Wysocki, Viresh Kumar,
Gautham R. Shenoy, Huang Rui, Mario Limonciello, Len Brown,
Srinivas Pandruvada, linux-pm, MyungJoo Ham, Kyungmin Park,
Chanwoo Choi, Christian König, Sumit Semwal, linaro-mm-sig,
Eddie James, Andrew Jeffery, Joel Stanley, linux-fsi,
David Airlie, Simona Vetter, Alex Deucher, Danilo Krummrich,
Matthew Brost, Philipp Stanner, Harry Wentland, Leo Li, amd-gfx,
Jiri Kosina, Benjamin Tissoires, linux-input, Wolfram Sang,
linux-i2c, Mark Brown, Michael Hennerich, Nuno Sá, linux-spi,
James E.J. Bottomley, Martin K. Petersen, linux-scsi, Chris Mason,
David Sterba, linux-btrfs, linux-trace-kernel, linux-kernel
In-Reply-To: <219d015d-076b-4c80-8f63-88569115fdad@efficios.com>
On Thu, 12 Mar 2026 11:28:07 -0400
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> > Note, Vineeth came up with the naming. I would have done "do" but when I
> > saw "invoke" I thought it sounded better.
>
> It works as long as you don't have a tracing subsystem called
> "invoke", then you get into identifier clash territory.
True. Perhaps we should do the double underscore trick.
Instead of: trace_invoke_foo()
use: trace_invoke__foo()
Which will make it more visible to what the trace event is.
Hmm, we probably should have used: trace__foo() for all tracepoints, as
there's still functions that are called trace_foo() that are not
tracepoints :-p
-- Steve
^ permalink raw reply
* Re: [PATCH 01/15] tracepoint: Add trace_invoke_##name() API
From: Vineeth Remanan Pillai @ 2026-03-12 15:39 UTC (permalink / raw)
To: Steven Rostedt
Cc: Peter Zijlstra, Dmitry Ilvokhin, Masami Hiramatsu,
Mathieu Desnoyers, Ingo Molnar, Jens Axboe, io-uring,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexei Starovoitov, Daniel Borkmann, Marcelo Ricardo Leitner,
Xin Long, Jon Maloy, Aaron Conole, Eelco Chaudron, Ilya Maximets,
netdev, bpf, linux-sctp, tipc-discussion, dev, Oded Gabbay,
Koby Elbaz, dri-devel, Rafael J. Wysocki, Viresh Kumar,
Gautham R. Shenoy, Huang Rui, Mario Limonciello, Len Brown,
Srinivas Pandruvada, linux-pm, MyungJoo Ham, Kyungmin Park,
Chanwoo Choi, Christian König, Sumit Semwal, linaro-mm-sig,
Eddie James, Andrew Jeffery, Joel Stanley, linux-fsi,
David Airlie, Simona Vetter, Alex Deucher, Danilo Krummrich,
Matthew Brost, Philipp Stanner, Harry Wentland, Leo Li, amd-gfx,
Jiri Kosina, Benjamin Tissoires, linux-input, Wolfram Sang,
linux-i2c, Mark Brown, Michael Hennerich, Nuno Sá, linux-spi,
James E.J. Bottomley, Martin K. Petersen, linux-scsi, Chris Mason,
David Sterba, linux-btrfs, linux-trace-kernel, linux-kernel
In-Reply-To: <20260312111255.7925b4e2@gandalf.local.home>
On Thu, Mar 12, 2026 at 11:13 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Thu, 12 Mar 2026 11:04:56 -0400
> "Vineeth Pillai (Google)" <vineeth@bitbyteword.org> wrote:
>
> > Add trace_invoke_##name() as a companion to trace_##name(). When a
> > caller already guards a tracepoint with an explicit enabled check:
> >
> > if (trace_foo_enabled() && cond)
> > trace_foo(args);
> >
> > trace_foo() internally repeats the static_branch_unlikely() test, which
> > the compiler cannot fold since static branches are patched binary
> > instructions. This results in two static-branch evaluations for every
> > guarded call site.
> >
> > trace_invoke_##name() calls __do_trace_##name() directly, skipping the
> > redundant static-branch re-check. This avoids leaking the internal
> > __do_trace_##name() symbol into call sites while still eliminating the
> > double evaluation:
> >
> > if (trace_foo_enabled() && cond)
> > trace_invoke_foo(args); /* calls __do_trace_foo() directly */
> >
> > Three locations are updated:
> > - __DECLARE_TRACE: invoke form omits static_branch_unlikely, retains
> > the LOCKDEP RCU-watching assertion.
> > - __DECLARE_TRACE_SYSCALL: same, plus retains might_fault().
> > - !TRACEPOINTS_ENABLED stub: empty no-op so callers compile cleanly
> > when tracepoints are compiled out.
> >
> > Suggested-by: Steven Rostedt <rostedt@goodmis.org>
> > Suggested-by: Peter Zijlstra <peterz@infradead.org>
> > Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org>
> > Assisted-by: Claude:claude-sonnet-4-6
>
> I'm guessing Claude helped with the other patches. Did it really help with this one?
>
Claude wrote and build tested the whole series based on my guidance
and prompt :-). I verified the series before sending it out, but
claude did the initial work.
Thanks,
Vineeth
^ permalink raw reply
* Re: [PATCH 03/15] io_uring: Use trace_invoke_##name() at guarded tracepoint call sites
From: Steven Rostedt @ 2026-03-12 15:38 UTC (permalink / raw)
To: Keith Busch
Cc: Vineeth Pillai (Google), Peter Zijlstra, Jens Axboe, io-uring,
linux-kernel, linux-trace-kernel
In-Reply-To: <abLapcC7YGYDyJ3L@kbusch-mbp>
On Thu, 12 Mar 2026 09:24:21 -0600
Keith Busch <kbusch@kernel.org> wrote:
> On Thu, Mar 12, 2026 at 11:04:58AM -0400, Vineeth Pillai (Google) wrote:
> > if (trace_io_uring_complete_enabled())
> > - trace_io_uring_complete(req->ctx, req, cqe);
> > + trace_invoke_io_uring_complete(req->ctx, req, cqe);
>
> Curious, this one doesn't follow that pattern of "if (enabed && cond)"
> that this cover letter said it was addressing, so why doesn't this call
> just drop the 'if' check and go straight to trace_io_uring_complete()? I
> followed this usage to commit a0730c738309a06, which says that the
You mean 'a0727c738309a06'? As I could not find the above 'a0730c738309a06'
> compiler was generating code to move args before checking if the trace
> was enabled. That commit was a while ago though, and suggests to remove
It was only 2023.
> the check if that problem is solved. Is it still a problem?
We should check. But also, tracepoints should never be in a header file.
That really should be:
#include <linux/tracepoint-defs.h>
DECLARE_TRACEPOINT(io_uring_complete);
[..]
if (tracepoint_enabled(io_uring_complete))
do_trace_io_uring_complete(...);
And in a C file, that should be:
void do_io_uring_complete(...)
{
trace_inovke_io_uring_complete(...);
}
Which reminds me. There's other places that have that tracepoint_enabled()
in header files that do the above. The C wrapper functions should also
convert the callback to the trace_invoke_<event>() call.
-- Steve
^ permalink raw reply
* Re: [PATCH 2/3] tracing: add more symbols to whitelist
From: Arnd Bergmann @ 2026-03-12 15:37 UTC (permalink / raw)
To: Marc Zyngier
Cc: Vincent Donnefort, Arnd Bergmann, Steven Rostedt, Oliver Upton,
Catalin Marinas, Will Deacon, Masami Hiramatsu, Mathieu Desnoyers,
linux-kernel, linux-trace-kernel
In-Reply-To: <86zf4d5b0w.wl-maz@kernel.org>
On Thu, Mar 12, 2026, at 16:21, Marc Zyngier wrote:
>
> I've decided to take this patch anyway, on top of Vincent's. Should a
> more generic solution arise, I can always drop both.
>
Ok, thanks!
FWIW, I came across two additional ones by now, and will keep
running more tests to see what else comes up:
--- a/kernel/trace/Makefile
+++ b/kernel/trace/Makefile
@@ -140,6 +140,7 @@ UNDEFINED_ALLOWLIST := memset alt_cb_patch_nops __x86 __ubsan __asan __kasan __g
UNDEFINED_ALLOWLIST += __stack_chk_fail stackleak_track_stack __ref_stack __sanitizer
UNDEFINED_ALLOWLIST += ftrace_likely_update __hwasan_load __hwasan_store __hwasan_tag_memory
UNDEFINED_ALLOWLIST += warn_bogus_irq_restore warn_slowpath_fmt __stack_chk_guard
+UNDEFINED_ALLOWLIST += __kcsan __tsan
UNDEFINED_ALLOWLIST := $(addprefix -e , $(UNDEFINED_ALLOWLIST))
quiet_cmd_check_undefined = NM $<
Arnd
^ permalink raw reply
* Re: [PATCH 13/15] spi: Use trace_invoke_##name() at guarded tracepoint call sites
From: Mark Brown @ 2026-03-12 15:34 UTC (permalink / raw)
To: Vineeth Pillai (Google)
Cc: Steven Rostedt, Peter Zijlstra, Michael Hennerich, Nuno Sá,
David Lechner, linux-spi, linux-kernel, linux-trace-kernel
In-Reply-To: <20260312150523.2054552-14-vineeth@bitbyteword.org>
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
On Thu, Mar 12, 2026 at 11:05:08AM -0400, Vineeth Pillai (Google) wrote:
> Replace trace_foo() with the new trace_invoke_foo() at sites already
> guarded by trace_foo_enabled(), avoiding a redundant
> static_branch_unlikely() re-evaluation inside the tracepoint.
> trace_invoke_foo() calls the tracepoint callbacks directly without
> utilizing the static branch again.
Acked-by: Mark Brown <broonie@kernel.org>
though not loving the naming here, I'll have a hard time figuring out
what the weird call is about next time I look at that code
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 00/61] treewide: Use IS_ERR_OR_NULL over manual NULL check - refactor
From: James Bottomley @ 2026-03-12 15:32 UTC (permalink / raw)
To: Jason Gunthorpe, Kuan-Wei Chiu
Cc: Philipp Hahn, amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel,
dri-devel, gfs2, intel-gfx, intel-wired-lan, iommu, kvm,
linux-arm-kernel, linux-block, linux-bluetooth, linux-btrfs,
linux-cifs, linux-clk, linux-erofs, linux-ext4, linux-fsdevel,
linux-gpio, linux-hyperv, linux-input, linux-kernel, linux-leds,
linux-media, linux-mips, linux-mm, linux-modules, linux-mtd,
linux-nfs, linux-omap, linux-phy, linux-pm, linux-rockchip,
linux-s390, linux-scsi, linux-sctp, linux-security-module,
linux-sh, linux-sound, linux-stm32, linux-trace-kernel, linux-usb,
linux-wireless, netdev, ntfs3, samba-technical, sched-ext,
target-devel, tipc-discussion, v9fs
In-Reply-To: <20260312125730.GI1469476@ziepe.ca>
On Thu, 2026-03-12 at 09:57 -0300, Jason Gunthorpe wrote:
> On Wed, Mar 11, 2026 at 02:40:36AM +0800, Kuan-Wei Chiu wrote:
>
> > IMHO, the necessity of IS_ERR_OR_NULL() often highlights a
> > confusing or flawed API design. It usually implies that the caller
> > is unsure whether a failure results in an error pointer or a NULL
> > pointer.
>
> +1
>
> IS_ERR_OR_NULL() should always be looked on with suspicion. Very
> little should be returning some tri-state 'ERR' 'NULL' 'SUCCESS'
> pointer. What does the middle condition even mean? IS_ERR_OR_NULL()
> implies ERR and NULL are semanticly the same, so fix the things to
> always use ERR.
Not in any way supporting the original patch. However, the pattern
ERR, NULL, PTR is used extensively in the dentry code of filesystems.
See the try_lookup..() set of functions in fs/namei.c
The meaning is
PTR - I found it
NULL - It definitely doesn't exist
ERR - something went wrong during the lookup.
So I don't think you can blanket say this pattern is wrong.
Regards,
James
^ permalink raw reply
* Re: [PATCH 04/15] net: Use trace_invoke_##name() at guarded tracepoint call sites
From: Aaron Conole @ 2026-03-12 15:31 UTC (permalink / raw)
To: Vineeth Pillai (Google)
Cc: Steven Rostedt, Peter Zijlstra, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alexei Starovoitov,
Daniel Borkmann, Jesper Dangaard Brouer, John Fastabend,
Stanislav Fomichev, Eelco Chaudron, Ilya Maximets,
Marcelo Ricardo Leitner, Xin Long, Jon Maloy, Kuniyuki Iwashima,
Samiullah Khawaja, Hangbin Liu, netdev, linux-kernel, bpf, dev,
linux-sctp, tipc-discussion, linux-trace-kernel
In-Reply-To: <20260312150523.2054552-5-vineeth@bitbyteword.org>
"Vineeth Pillai (Google)" <vineeth@bitbyteword.org> writes:
> Replace trace_foo() with the new trace_invoke_foo() at sites already
> guarded by trace_foo_enabled(), avoiding a redundant
> static_branch_unlikely() re-evaluation inside the tracepoint.
> trace_invoke_foo() calls the tracepoint callbacks directly without
> utilizing the static branch again.
>
> Suggested-by: Steven Rostedt <rostedt@goodmis.org>
> Suggested-by: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org>
> Assisted-by: Claude:claude-sonnet-4-6
> ---
> net/core/dev.c | 2 +-
> net/core/xdp.c | 2 +-
> net/openvswitch/actions.c | 2 +-
> net/openvswitch/datapath.c | 2 +-
> net/sctp/outqueue.c | 2 +-
> net/tipc/node.c | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 14a83f2035b93..a48fae2bbf57e 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -6444,7 +6444,7 @@ void netif_receive_skb_list(struct list_head *head)
> return;
> if (trace_netif_receive_skb_list_entry_enabled()) {
> list_for_each_entry(skb, head, list)
> - trace_netif_receive_skb_list_entry(skb);
> + trace_invoke_netif_receive_skb_list_entry(skb);
> }
> netif_receive_skb_list_internal(head);
> trace_netif_receive_skb_list_exit(0);
> diff --git a/net/core/xdp.c b/net/core/xdp.c
> index 9890a30584ba7..53acc887c3434 100644
> --- a/net/core/xdp.c
> +++ b/net/core/xdp.c
> @@ -362,7 +362,7 @@ int xdp_rxq_info_reg_mem_model(struct xdp_rxq_info *xdp_rxq,
> xsk_pool_set_rxq_info(allocator, xdp_rxq);
>
> if (trace_mem_connect_enabled() && xdp_alloc)
> - trace_mem_connect(xdp_alloc, xdp_rxq);
> + trace_invoke_mem_connect(xdp_alloc, xdp_rxq);
> return 0;
> }
>
> diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
> index 792ca44a461da..420eb19322e85 100644
> --- a/net/openvswitch/actions.c
> +++ b/net/openvswitch/actions.c
> @@ -1259,7 +1259,7 @@ static int do_execute_actions(struct datapath *dp, struct sk_buff *skb,
> int err = 0;
>
> if (trace_ovs_do_execute_action_enabled())
> - trace_ovs_do_execute_action(dp, skb, key, a, rem);
> + trace_invoke_ovs_do_execute_action(dp, skb, key, a, rem);
Maybe we should just remove the guard here instead of calling the
invoke. That seems better to me. It wouldn't need to belong to this
series.
> /* Actions that rightfully have to consume the skb should do it
> * and return directly.
> diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> index e209099218b41..02451629e888e 100644
> --- a/net/openvswitch/datapath.c
> +++ b/net/openvswitch/datapath.c
> @@ -335,7 +335,7 @@ int ovs_dp_upcall(struct datapath *dp, struct sk_buff *skb,
> int err;
>
> if (trace_ovs_dp_upcall_enabled())
> - trace_ovs_dp_upcall(dp, skb, key, upcall_info);
> + trace_invoke_ovs_dp_upcall(dp, skb, key, upcall_info);
Same as above. Seems OVS tracepoints are the only ones that include
the guard without any real reason.
> if (upcall_info->portid == 0) {
> err = -ENOTCONN;
> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> index f6b8c13dafa4a..9831afbff070f 100644
> --- a/net/sctp/outqueue.c
> +++ b/net/sctp/outqueue.c
> @@ -1267,7 +1267,7 @@ int sctp_outq_sack(struct sctp_outq *q, struct sctp_chunk *chunk)
> /* SCTP path tracepoint for congestion control debugging. */
> if (trace_sctp_probe_path_enabled()) {
> list_for_each_entry(transport, transport_list, transports)
> - trace_sctp_probe_path(transport, asoc);
> + trace_invoke_sctp_probe_path(transport, asoc);
> }
>
> sack_ctsn = ntohl(sack->cum_tsn_ack);
> diff --git a/net/tipc/node.c b/net/tipc/node.c
> index af442a5ef8f3d..01e07ec18c56c 100644
> --- a/net/tipc/node.c
> +++ b/net/tipc/node.c
> @@ -1943,7 +1943,7 @@ static bool tipc_node_check_state(struct tipc_node *n, struct sk_buff *skb,
>
> if (trace_tipc_node_check_state_enabled()) {
> trace_tipc_skb_dump(skb, false, "skb for node state check");
> - trace_tipc_node_check_state(n, true, " ");
> + trace_invoke_tipc_node_check_state(n, true, " ");
> }
> l = n->links[bearer_id].link;
> if (!l)
^ permalink raw reply
* Re: [PATCH 00/15] tracepoint: Avoid double static_branch evaluation at guarded call sites
From: Mathieu Desnoyers @ 2026-03-12 15:28 UTC (permalink / raw)
To: Steven Rostedt
Cc: Vineeth Pillai (Google), Peter Zijlstra, Dmitry Ilvokhin,
Masami Hiramatsu, Ingo Molnar, Jens Axboe, io-uring,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexei Starovoitov, Daniel Borkmann, Marcelo Ricardo Leitner,
Xin Long, Jon Maloy, Aaron Conole, Eelco Chaudron, Ilya Maximets,
netdev, bpf, linux-sctp, tipc-discussion, dev, Oded Gabbay,
Koby Elbaz, dri-devel, Rafael J. Wysocki, Viresh Kumar,
Gautham R. Shenoy, Huang Rui, Mario Limonciello, Len Brown,
Srinivas Pandruvada, linux-pm, MyungJoo Ham, Kyungmin Park,
Chanwoo Choi, Christian König, Sumit Semwal, linaro-mm-sig,
Eddie James, Andrew Jeffery, Joel Stanley, linux-fsi,
David Airlie, Simona Vetter, Alex Deucher, Danilo Krummrich,
Matthew Brost, Philipp Stanner, Harry Wentland, Leo Li, amd-gfx,
Jiri Kosina, Benjamin Tissoires, linux-input, Wolfram Sang,
linux-i2c, Mark Brown, Michael Hennerich, Nuno Sá, linux-spi,
James E.J. Bottomley, Martin K. Petersen, linux-scsi, Chris Mason,
David Sterba, linux-btrfs, linux-trace-kernel, linux-kernel
In-Reply-To: <20260312112354.3dd99e36@gandalf.local.home>
On 2026-03-12 11:23, Steven Rostedt wrote:
> On Thu, 12 Mar 2026 11:12:41 -0400
> Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
>
>>> if (trace_foo_enabled() && cond)
>>> trace_invoke_foo(args); /* calls __do_trace_foo() directly */
>>
>> FYI, we have a similar concept in LTTng-UST for userspace
>> instrumentation already:
>>
>> if (lttng_ust_tracepoint_enabled(provider, name))
>> lttng_ust_do_tracepoint(provider, name, ...);
>>
>> Perhaps it can provide some ideas about API naming.
>
> I find the word "invoke" sounding more official than "do" ;-)
>
> Note, Vineeth came up with the naming. I would have done "do" but when I
> saw "invoke" I thought it sounded better.
It works as long as you don't have a tracing subsystem called
"invoke", then you get into identifier clash territory.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
^ permalink raw reply
* Re: [PATCH 03/15] io_uring: Use trace_invoke_##name() at guarded tracepoint call sites
From: Keith Busch @ 2026-03-12 15:24 UTC (permalink / raw)
To: Vineeth Pillai (Google)
Cc: Steven Rostedt, Peter Zijlstra, Jens Axboe, io-uring,
linux-kernel, linux-trace-kernel
In-Reply-To: <20260312150523.2054552-4-vineeth@bitbyteword.org>
On Thu, Mar 12, 2026 at 11:04:58AM -0400, Vineeth Pillai (Google) wrote:
> if (trace_io_uring_complete_enabled())
> - trace_io_uring_complete(req->ctx, req, cqe);
> + trace_invoke_io_uring_complete(req->ctx, req, cqe);
Curious, this one doesn't follow that pattern of "if (enabed && cond)"
that this cover letter said it was addressing, so why doesn't this call
just drop the 'if' check and go straight to trace_io_uring_complete()? I
followed this usage to commit a0730c738309a06, which says that the
compiler was generating code to move args before checking if the trace
was enabled. That commit was a while ago though, and suggests to remove
the check if that problem is solved. Is it still a problem?
^ permalink raw reply
* Re: [PATCH 00/15] tracepoint: Avoid double static_branch evaluation at guarded call sites
From: Steven Rostedt @ 2026-03-12 15:23 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Vineeth Pillai (Google), Peter Zijlstra, Dmitry Ilvokhin,
Masami Hiramatsu, Ingo Molnar, Jens Axboe, io-uring,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexei Starovoitov, Daniel Borkmann, Marcelo Ricardo Leitner,
Xin Long, Jon Maloy, Aaron Conole, Eelco Chaudron, Ilya Maximets,
netdev, bpf, linux-sctp, tipc-discussion, dev, Oded Gabbay,
Koby Elbaz, dri-devel, Rafael J. Wysocki, Viresh Kumar,
Gautham R. Shenoy, Huang Rui, Mario Limonciello, Len Brown,
Srinivas Pandruvada, linux-pm, MyungJoo Ham, Kyungmin Park,
Chanwoo Choi, Christian König, Sumit Semwal, linaro-mm-sig,
Eddie James, Andrew Jeffery, Joel Stanley, linux-fsi,
David Airlie, Simona Vetter, Alex Deucher, Danilo Krummrich,
Matthew Brost, Philipp Stanner, Harry Wentland, Leo Li, amd-gfx,
Jiri Kosina, Benjamin Tissoires, linux-input, Wolfram Sang,
linux-i2c, Mark Brown, Michael Hennerich, Nuno Sá, linux-spi,
James E.J. Bottomley, Martin K. Petersen, linux-scsi, Chris Mason,
David Sterba, linux-btrfs, linux-trace-kernel, linux-kernel
In-Reply-To: <1e3c2830-765e-4271-89f7-0b6784b37597@efficios.com>
On Thu, 12 Mar 2026 11:12:41 -0400
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> > if (trace_foo_enabled() && cond)
> > trace_invoke_foo(args); /* calls __do_trace_foo() directly */
>
> FYI, we have a similar concept in LTTng-UST for userspace
> instrumentation already:
>
> if (lttng_ust_tracepoint_enabled(provider, name))
> lttng_ust_do_tracepoint(provider, name, ...);
>
> Perhaps it can provide some ideas about API naming.
I find the word "invoke" sounding more official than "do" ;-)
Note, Vineeth came up with the naming. I would have done "do" but when I
saw "invoke" I thought it sounded better.
-- Steve
^ permalink raw reply
* Re: [PATCH 2/3] tracing: add more symbols to whitelist
From: Marc Zyngier @ 2026-03-12 15:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Vincent Donnefort, Arnd Bergmann, Steven Rostedt, Oliver Upton,
Catalin Marinas, Will Deacon, Masami Hiramatsu, Mathieu Desnoyers,
linux-kernel, linux-trace-kernel
In-Reply-To: <d4fa3ee4-22ed-4ba3-afa3-4fe7a22b226c@app.fastmail.com>
On Thu, 12 Mar 2026 14:37:50 +0000,
"Arnd Bergmann" <arnd@arndb.de> wrote:
>
> On Thu, Mar 12, 2026, at 14:40, Vincent Donnefort wrote:
> > On Thu, Mar 12, 2026 at 01:35:43PM +0100, Arnd Bergmann wrote:
> >> diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
>
> >> +UNDEFINED_ALLOWLIST += ftrace_likely_update __hwasan_load __hwasan_store __hwasan_tag_memory
> >> +UNDEFINED_ALLOWLIST += warn_bogus_irq_restore warn_slowpath_fmt __stack_chk_guard
>
> >
> > Thanks for the patch.
> >
> > Most of those ones are covered here
> > https://lore.kernel.org/all/20260312113535.2213350-1-vdonnefort@google.com/.
> >
> > This should fix allmodconfig.
>
> The ones I see in that patch look entirely different from the ones
> I found.
>
> > For the ones not covered, I'm working on a follow-up patch using a different
> > approach which should fix them. I'll be able to share it today or tomorrow. Not
> > sure if we want to take this temporarily?
>
> I can wait, my randconfig setup has my patch applied locally for now,
> but I've only fixed the ones I saw on three architectures with gcc-16.0.1,
> while Nathan's list seems to be mostly for clang specific symbols.
>
> A lot of them also don't show up in allmodconfig builds, only after a
> larger number of randconfig configurations.
I've decided to take this patch anyway, on top of Vincent's. Should a
more generic solution arise, I can always drop both.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 01/15] tracepoint: Add trace_invoke_##name() API
From: Steven Rostedt @ 2026-03-12 15:12 UTC (permalink / raw)
To: Vineeth Pillai (Google)
Cc: Peter Zijlstra, Dmitry Ilvokhin, Masami Hiramatsu,
Mathieu Desnoyers, Ingo Molnar, Jens Axboe, io-uring,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexei Starovoitov, Daniel Borkmann, Marcelo Ricardo Leitner,
Xin Long, Jon Maloy, Aaron Conole, Eelco Chaudron, Ilya Maximets,
netdev, bpf, linux-sctp, tipc-discussion, dev, Oded Gabbay,
Koby Elbaz, dri-devel, Rafael J. Wysocki, Viresh Kumar,
Gautham R. Shenoy, Huang Rui, Mario Limonciello, Len Brown,
Srinivas Pandruvada, linux-pm, MyungJoo Ham, Kyungmin Park,
Chanwoo Choi, Christian König, Sumit Semwal, linaro-mm-sig,
Eddie James, Andrew Jeffery, Joel Stanley, linux-fsi,
David Airlie, Simona Vetter, Alex Deucher, Danilo Krummrich,
Matthew Brost, Philipp Stanner, Harry Wentland, Leo Li, amd-gfx,
Jiri Kosina, Benjamin Tissoires, linux-input, Wolfram Sang,
linux-i2c, Mark Brown, Michael Hennerich, Nuno Sá, linux-spi,
James E.J. Bottomley, Martin K. Petersen, linux-scsi, Chris Mason,
David Sterba, linux-btrfs, linux-trace-kernel, linux-kernel
In-Reply-To: <20260312150523.2054552-2-vineeth@bitbyteword.org>
On Thu, 12 Mar 2026 11:04:56 -0400
"Vineeth Pillai (Google)" <vineeth@bitbyteword.org> wrote:
> Add trace_invoke_##name() as a companion to trace_##name(). When a
> caller already guards a tracepoint with an explicit enabled check:
>
> if (trace_foo_enabled() && cond)
> trace_foo(args);
>
> trace_foo() internally repeats the static_branch_unlikely() test, which
> the compiler cannot fold since static branches are patched binary
> instructions. This results in two static-branch evaluations for every
> guarded call site.
>
> trace_invoke_##name() calls __do_trace_##name() directly, skipping the
> redundant static-branch re-check. This avoids leaking the internal
> __do_trace_##name() symbol into call sites while still eliminating the
> double evaluation:
>
> if (trace_foo_enabled() && cond)
> trace_invoke_foo(args); /* calls __do_trace_foo() directly */
>
> Three locations are updated:
> - __DECLARE_TRACE: invoke form omits static_branch_unlikely, retains
> the LOCKDEP RCU-watching assertion.
> - __DECLARE_TRACE_SYSCALL: same, plus retains might_fault().
> - !TRACEPOINTS_ENABLED stub: empty no-op so callers compile cleanly
> when tracepoints are compiled out.
>
> Suggested-by: Steven Rostedt <rostedt@goodmis.org>
> Suggested-by: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org>
> Assisted-by: Claude:claude-sonnet-4-6
I'm guessing Claude helped with the other patches. Did it really help with this one?
-- Steve
> ---
> include/linux/tracepoint.h | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
> index 22ca1c8b54f32..07219316a8e14 100644
> --- a/include/linux/tracepoint.h
> +++ b/include/linux/tracepoint.h
> @@ -294,6 +294,10 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
> WARN_ONCE(!rcu_is_watching(), \
> "RCU not watching for tracepoint"); \
> } \
> + } \
> + static inline void trace_invoke_##name(proto) \
> + { \
> + __do_trace_##name(args); \
> }
>
> #define __DECLARE_TRACE_SYSCALL(name, proto, args, data_proto) \
> @@ -313,6 +317,11 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
> WARN_ONCE(!rcu_is_watching(), \
> "RCU not watching for tracepoint"); \
> } \
> + } \
> + static inline void trace_invoke_##name(proto) \
> + { \
> + might_fault(); \
> + __do_trace_##name(args); \
> }
>
> /*
> @@ -398,6 +407,8 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
> #define __DECLARE_TRACE_COMMON(name, proto, args, data_proto) \
> static inline void trace_##name(proto) \
> { } \
> + static inline void trace_invoke_##name(proto) \
> + { } \
> static inline int \
> register_trace_##name(void (*probe)(data_proto), \
> void *data) \
^ permalink raw reply
* Re: [PATCH 00/15] tracepoint: Avoid double static_branch evaluation at guarded call sites
From: Mathieu Desnoyers @ 2026-03-12 15:12 UTC (permalink / raw)
To: Vineeth Pillai (Google), Steven Rostedt, Peter Zijlstra,
Dmitry Ilvokhin
Cc: Masami Hiramatsu, Ingo Molnar, Jens Axboe, io-uring,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexei Starovoitov, Daniel Borkmann, Marcelo Ricardo Leitner,
Xin Long, Jon Maloy, Aaron Conole, Eelco Chaudron, Ilya Maximets,
netdev, bpf, linux-sctp, tipc-discussion, dev, Oded Gabbay,
Koby Elbaz, dri-devel, Rafael J. Wysocki, Viresh Kumar,
Gautham R. Shenoy, Huang Rui, Mario Limonciello, Len Brown,
Srinivas Pandruvada, linux-pm, MyungJoo Ham, Kyungmin Park,
Chanwoo Choi, Christian König, Sumit Semwal, linaro-mm-sig,
Eddie James, Andrew Jeffery, Joel Stanley, linux-fsi,
David Airlie, Simona Vetter, Alex Deucher, Danilo Krummrich,
Matthew Brost, Philipp Stanner, Harry Wentland, Leo Li, amd-gfx,
Jiri Kosina, Benjamin Tissoires, linux-input, Wolfram Sang,
linux-i2c, Mark Brown, Michael Hennerich, Nuno Sá, linux-spi,
James E.J. Bottomley, Martin K. Petersen, linux-scsi, Chris Mason,
David Sterba, linux-btrfs, linux-trace-kernel, linux-kernel
In-Reply-To: <20260312150523.2054552-1-vineeth@bitbyteword.org>
On 2026-03-12 11:04, Vineeth Pillai (Google) wrote:
> When a caller already guards a tracepoint with an explicit enabled check:
>
> if (trace_foo_enabled() && cond)
> trace_foo(args);
>
> trace_foo() internally re-evaluates the static_branch_unlikely() key.
> Since static branches are patched binary instructions the compiler cannot
> fold the two evaluations, so every such site pays the cost twice.
>
> This series introduces trace_invoke_##name() as a companion to
> trace_##name(). It calls __do_trace_##name() directly, bypassing the
> redundant static-branch re-check, while preserving all other correctness
> properties of the normal path (RCU-watching assertion, might_fault() for
> syscall tracepoints). The internal __do_trace_##name() symbol is not
> leaked to call sites; trace_invoke_##name() is the only new public API.
>
> if (trace_foo_enabled() && cond)
> trace_invoke_foo(args); /* calls __do_trace_foo() directly */
FYI, we have a similar concept in LTTng-UST for userspace
instrumentation already:
if (lttng_ust_tracepoint_enabled(provider, name))
lttng_ust_do_tracepoint(provider, name, ...);
Perhaps it can provide some ideas about API naming.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
^ permalink raw reply
* Re: [RFC PATCH v2 09/37] KVM: guest_memfd: Add support for KVM_SET_MEMORY_ATTRIBUTES2
From: Fuad Tabba @ 2026-03-12 15:12 UTC (permalink / raw)
To: Ackerley Tng
Cc: kvm, linux-doc, linux-kernel, linux-kselftest, linux-trace-kernel,
x86, aik, andrew.jones, binbin.wu, bp, brauner, chao.p.peng,
chao.p.peng, chenhuacai, corbet, dave.hansen, david, hpa,
ira.weiny, jgg, jmattson, jroedel, jthoughton, maobibo,
mathieu.desnoyers, maz, mhiramat, michael.roth, mingo, mlevitsk,
oupton, pankaj.gupta, pbonzini, prsampat, qperret, ricarkol,
rick.p.edgecombe, rientjes, rostedt, seanjc, shivankg, shuah,
steven.price, tglx, vannapurve, vbabka, willy, wyihan, yan.y.zhao
In-Reply-To: <CAEvNRgG-L+GBcm+u_thGvXAxV-Nqzu5VtgXy0PfND6SG0FiyVg@mail.gmail.com>
Hi Ackerley,
Before getting into the UAPI semantics, thank you for all the heavy
lifting you've done here. Figuring out how to make it all work across
the different platforms is not easy :)
<snip>
> The policy definitions below provide more details:
>
> ``KVM_SET_MEMORY_ATTRIBUTES2_CONTENT_POLICY_ZERO`` (default)
>
> On a private to shared conversion, the host will read zeros from the
> converted memory on the next fault after successful return of the
> KVM_SET_MEMORY_ATTRIBUTES2 ioctl.
>
> This is not supported (-EOPNOTSUPP) for a shared to private
> conversion. While some CoCo implementations do zero memory contents
> such that the guest reads zeros after conversion, the guest is not
> expected to trust host-provided zeroing, hence as a UAPI policy, KVM
> does not make any such guarantees.
The rationale for not supporting this in the UAPI isn't quite right
and I think that the prohibition should be removed. It's true that the
guest is not expected to trust host-provided zeroing. However, if the
VMM invokes this ioctl with the ZERO policy, the zeroing is performed
by the hypervisor, not by the (untrusted) host.
Although pKVM handles fresh, zeroed memory provisioning via donation
rather than attribute conversion, stating that the UAPI cannot make
guarantees due to trust boundaries is incorrect. The hypervisor is
precisely the entity the guest trusts to enforce this.
The UAPI should define the semantics for a shared-to-private ZERO
conversion, even if current architectures return -EOPNOTSUPP because
they handle fresh memory provisioning via other mechanisms (like
pKVM's donation path).
How about something like the following:
On a shared to private conversion, the hypervisor will zero the memory
contents before mapping it into the guest's private address space,
preventing the untrusted host from injecting arbitrary data into the
guest. If an architecture handles zeroed-provisioning via mechanisms
other than attribute conversion, it may return -EOPNOTSUPP.
> For testing purposes, the KVM_X86_SW_PROTECTED_VM testing vehicle
> will support this policy and ensure zeroing for conversions in both
> directions.
>
> ``KVM_SET_MEMORY_ATTRIBUTES2_CONTENT_POLICY_PRESERVE``
>
> On private/shared conversions in both directions, memory contents
> will be preserved and readable. As a concrete example, if the host
> writes ``0xbeef`` to memory and converts the memory to shared, the
> guest will also read ``0xbeef``, after any necessary hardware or
> software provided decryption. After a reverse shared to private
> conversion, the host will also read ``0xbeef``.
I think that this example is backwards. If the host writes to memory,
that memory is already shared, isn't it? Converting it to shared is
redundant. More importantly, if memory undergoes a shared-to-private
conversion, the host must lose access entirely.
Maybe a clearer example would reflect actual payload injection and
bounce buffer sharing:
- Shared-to-Private (Payload Injection): The host writes a payload
(e.g., 0xbeef) to shared memory and converts it to private. The guest
reads 0xbeef in its private address space. The host loses access.
- Private-to-Shared (Bounce Buffer): The guest writes 0xbeef to
private memory and converts it to shared. The host reads 0xbeef.
> pKVM (ARM) is the first user of this policy. Since pKVM does not
> protect memory with encryption, a content policy to preserve memory
> will not will not involve any decryption. The guest will be able to
> read what the host wrote with full content preservation.
This is correct, but to be precise, I think it should explicitly
mention Stage-2 page tables as the protection mechanism, maybe:
Because pKVM protects private memory via Stage-2 page table isolation
rather than hardware encryption, content preservation does not require
cryptographic operations. The hypervisor (at EL2) simply transfers
page ownership while retaining the data.
Cheers,
/fuad
> For testing purposes, the KVM_X86_SW_PROTECTED_VM testing vehicle
> will support this policy and the contents of converted memory will
> be preserved.
>
> ``KVM_SET_MEMORY_ATTRIBUTES2_CONTENT_POLICY_NONE``
>
> This is an explicit request that KVM provide no guarantees on memory
> contents after conversion. Neither host nor guest should expect any
> guarantees about the memory contents after conversion.
>
> For testing purposes, the KVM_X86_SW_PROTECTED_VM testing vehicle will
> support this policy and every byte of converted memory will read
> ``0xab``.
>
> >> See also: :ref: `KVM_SET_MEMORY_ATTRIBUTES`.
> >>
> >
> > [...snip...]
> >
^ permalink raw reply
* [PATCH 15/15] btrfs: Use trace_invoke_##name() at guarded tracepoint call sites
From: Vineeth Pillai (Google) @ 2026-03-12 15:05 UTC (permalink / raw)
Cc: Vineeth Pillai (Google), Steven Rostedt, Peter Zijlstra,
Chris Mason, David Sterba, linux-btrfs, linux-kernel,
linux-trace-kernel
In-Reply-To: <20260312150523.2054552-1-vineeth@bitbyteword.org>
Replace trace_foo() with the new trace_invoke_foo() at sites already
guarded by trace_foo_enabled(), avoiding a redundant
static_branch_unlikely() re-evaluation inside the tracepoint.
trace_invoke_foo() calls the tracepoint callbacks directly without
utilizing the static branch again.
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org>
Assisted-by: Claude:claude-sonnet-4-6
---
fs/btrfs/extent_map.c | 4 ++--
fs/btrfs/raid56.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c
index 095a561d733f0..fadb676fc4e90 100644
--- a/fs/btrfs/extent_map.c
+++ b/fs/btrfs/extent_map.c
@@ -1318,7 +1318,7 @@ static void btrfs_extent_map_shrinker_worker(struct work_struct *work)
if (trace_btrfs_extent_map_shrinker_scan_enter_enabled()) {
s64 nr = percpu_counter_sum_positive(&fs_info->evictable_extent_maps);
- trace_btrfs_extent_map_shrinker_scan_enter(fs_info, nr);
+ trace_invoke_btrfs_extent_map_shrinker_scan_enter(fs_info, nr);
}
while (ctx.scanned < ctx.nr_to_scan && !btrfs_fs_closing(fs_info)) {
@@ -1358,7 +1358,7 @@ static void btrfs_extent_map_shrinker_worker(struct work_struct *work)
if (trace_btrfs_extent_map_shrinker_scan_exit_enabled()) {
s64 nr = percpu_counter_sum_positive(&fs_info->evictable_extent_maps);
- trace_btrfs_extent_map_shrinker_scan_exit(fs_info, nr_dropped, nr);
+ trace_invoke_btrfs_extent_map_shrinker_scan_exit(fs_info, nr_dropped, nr);
}
atomic64_set(&fs_info->em_shrinker_nr_to_scan, 0);
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
index b4511f560e929..c6de0c5bd6ef6 100644
--- a/fs/btrfs/raid56.c
+++ b/fs/btrfs/raid56.c
@@ -1743,7 +1743,7 @@ static void submit_read_wait_bio_list(struct btrfs_raid_bio *rbio,
struct raid56_bio_trace_info trace_info = { 0 };
bio_get_trace_info(rbio, bio, &trace_info);
- trace_raid56_read(rbio, bio, &trace_info);
+ trace_invoke_raid56_read(rbio, bio, &trace_info);
}
submit_bio(bio);
}
@@ -2420,7 +2420,7 @@ static void submit_write_bios(struct btrfs_raid_bio *rbio,
struct raid56_bio_trace_info trace_info = { 0 };
bio_get_trace_info(rbio, bio, &trace_info);
- trace_raid56_write(rbio, bio, &trace_info);
+ trace_invoke_raid56_write(rbio, bio, &trace_info);
}
submit_bio(bio);
}
--
2.53.0
^ permalink raw reply related
* [PATCH 14/15] scsi: ufs: Use trace_invoke_##name() at guarded tracepoint call sites
From: Vineeth Pillai (Google) @ 2026-03-12 15:05 UTC (permalink / raw)
Cc: Vineeth Pillai (Google), Steven Rostedt, Peter Zijlstra,
Alim Akhtar, Avri Altman, Bart Van Assche, James E.J. Bottomley,
Martin K. Petersen, Peter Wang, Bean Huo, Adrian Hunter,
Bao D. Nguyen, linux-scsi, linux-kernel, linux-trace-kernel
In-Reply-To: <20260312150523.2054552-1-vineeth@bitbyteword.org>
Replace trace_foo() with the new trace_invoke_foo() at sites already
guarded by trace_foo_enabled(), avoiding a redundant
static_branch_unlikely() re-evaluation inside the tracepoint.
trace_invoke_foo() calls the tracepoint callbacks directly without
utilizing the static branch again.
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org>
Assisted-by: Claude:claude-sonnet-4-6
---
drivers/ufs/core/ufshcd.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 899e663fea6e8..923e24e7c9973 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -422,7 +422,7 @@ static void ufshcd_add_cmd_upiu_trace(struct ufs_hba *hba,
else
header = &lrb->ucd_rsp_ptr->header;
- trace_ufshcd_upiu(hba, str_t, header, &rq->sc.cdb,
+ trace_invoke_ufshcd_upiu(hba, str_t, header, &rq->sc.cdb,
UFS_TSF_CDB);
}
@@ -433,7 +433,7 @@ static void ufshcd_add_query_upiu_trace(struct ufs_hba *hba,
if (!trace_ufshcd_upiu_enabled())
return;
- trace_ufshcd_upiu(hba, str_t, &rq_rsp->header,
+ trace_invoke_ufshcd_upiu(hba, str_t, &rq_rsp->header,
&rq_rsp->qr, UFS_TSF_OSF);
}
@@ -446,12 +446,12 @@ static void ufshcd_add_tm_upiu_trace(struct ufs_hba *hba, unsigned int tag,
return;
if (str_t == UFS_TM_SEND)
- trace_ufshcd_upiu(hba, str_t,
+ trace_invoke_ufshcd_upiu(hba, str_t,
&descp->upiu_req.req_header,
&descp->upiu_req.input_param1,
UFS_TSF_TM_INPUT);
else
- trace_ufshcd_upiu(hba, str_t,
+ trace_invoke_ufshcd_upiu(hba, str_t,
&descp->upiu_rsp.rsp_header,
&descp->upiu_rsp.output_param1,
UFS_TSF_TM_OUTPUT);
@@ -471,7 +471,7 @@ static void ufshcd_add_uic_command_trace(struct ufs_hba *hba,
else
cmd = ufshcd_readl(hba, REG_UIC_COMMAND);
- trace_ufshcd_uic_command(hba, str_t, cmd,
+ trace_invoke_ufshcd_uic_command(hba, str_t, cmd,
ufshcd_readl(hba, REG_UIC_COMMAND_ARG_1),
ufshcd_readl(hba, REG_UIC_COMMAND_ARG_2),
ufshcd_readl(hba, REG_UIC_COMMAND_ARG_3));
@@ -523,7 +523,7 @@ static void ufshcd_add_command_trace(struct ufs_hba *hba, struct scsi_cmnd *cmd,
} else {
doorbell = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
}
- trace_ufshcd_command(cmd->device, hba, str_t, tag, doorbell, hwq_id,
+ trace_invoke_ufshcd_command(cmd->device, hba, str_t, tag, doorbell, hwq_id,
transfer_len, intr, lba, opcode, group_id);
}
--
2.53.0
^ permalink raw reply related
* [PATCH 13/15] spi: Use trace_invoke_##name() at guarded tracepoint call sites
From: Vineeth Pillai (Google) @ 2026-03-12 15:05 UTC (permalink / raw)
Cc: Vineeth Pillai (Google), Steven Rostedt, Peter Zijlstra,
Michael Hennerich, Nuno Sá, David Lechner, Mark Brown,
linux-spi, linux-kernel, linux-trace-kernel
In-Reply-To: <20260312150523.2054552-1-vineeth@bitbyteword.org>
Replace trace_foo() with the new trace_invoke_foo() at sites already
guarded by trace_foo_enabled(), avoiding a redundant
static_branch_unlikely() re-evaluation inside the tracepoint.
trace_invoke_foo() calls the tracepoint callbacks directly without
utilizing the static branch again.
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org>
Assisted-by: Claude:claude-sonnet-4-6
---
drivers/spi/spi-axi-spi-engine.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-axi-spi-engine.c b/drivers/spi/spi-axi-spi-engine.c
index 48ee5bf481738..44e618bab2f0b 100644
--- a/drivers/spi/spi-axi-spi-engine.c
+++ b/drivers/spi/spi-axi-spi-engine.c
@@ -953,7 +953,7 @@ static int spi_engine_transfer_one_message(struct spi_controller *host,
struct spi_transfer *xfer;
list_for_each_entry(xfer, &msg->transfers, transfer_list)
- trace_spi_transfer_start(msg, xfer);
+ trace_invoke_spi_transfer_start(msg, xfer);
}
spin_lock_irqsave(&spi_engine->lock, flags);
@@ -987,7 +987,7 @@ static int spi_engine_transfer_one_message(struct spi_controller *host,
struct spi_transfer *xfer;
list_for_each_entry(xfer, &msg->transfers, transfer_list)
- trace_spi_transfer_stop(msg, xfer);
+ trace_invoke_spi_transfer_stop(msg, xfer);
}
out:
--
2.53.0
^ permalink raw reply related
* [PATCH 12/15] i2c: Use trace_invoke_##name() at guarded tracepoint call sites
From: Vineeth Pillai (Google) @ 2026-03-12 15:05 UTC (permalink / raw)
Cc: Vineeth Pillai (Google), Steven Rostedt, Peter Zijlstra,
Wolfram Sang, linux-i2c, linux-kernel, linux-trace-kernel
In-Reply-To: <20260312150523.2054552-1-vineeth@bitbyteword.org>
Replace trace_foo() with the new trace_invoke_foo() at sites already
guarded by trace_foo_enabled(), avoiding a redundant
static_branch_unlikely() re-evaluation inside the tracepoint.
trace_invoke_foo() calls the tracepoint callbacks directly without
utilizing the static branch again.
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org>
Assisted-by: Claude:claude-sonnet-4-6
---
drivers/i2c/i2c-core-slave.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-core-slave.c b/drivers/i2c/i2c-core-slave.c
index 02ca55c2246bc..04de8908de5fc 100644
--- a/drivers/i2c/i2c-core-slave.c
+++ b/drivers/i2c/i2c-core-slave.c
@@ -89,7 +89,7 @@ int i2c_slave_event(struct i2c_client *client,
int ret = client->slave_cb(client, event, val);
if (trace_i2c_slave_enabled())
- trace_i2c_slave(client, event, val, ret);
+ trace_invoke_i2c_slave(client, event, val, ret);
return ret;
}
--
2.53.0
^ permalink raw reply related
* [PATCH 11/15] HID: Use trace_invoke_##name() at guarded tracepoint call sites
From: Vineeth Pillai (Google) @ 2026-03-12 15:05 UTC (permalink / raw)
Cc: Vineeth Pillai (Google), Steven Rostedt, Peter Zijlstra,
Srinivas Pandruvada, Jiri Kosina, Benjamin Tissoires, Zhang Lixu,
Andy Shevchenko, linux-input, linux-kernel, linux-trace-kernel
In-Reply-To: <20260312150523.2054552-1-vineeth@bitbyteword.org>
Replace trace_foo() with the new trace_invoke_foo() at sites already
guarded by trace_foo_enabled(), avoiding a redundant
static_branch_unlikely() re-evaluation inside the tracepoint.
trace_invoke_foo() calls the tracepoint callbacks directly without
utilizing the static branch again.
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org>
Assisted-by: Claude:claude-sonnet-4-6
---
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
index ed3405c05e73c..01334a6599971 100644
--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
+++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
@@ -110,7 +110,7 @@ void ish_event_tracer(struct ishtp_device *dev, const char *format, ...)
vsnprintf(tmp_buf, sizeof(tmp_buf), format, args);
va_end(args);
- trace_ishtp_dump(tmp_buf);
+ trace_invoke_ishtp_dump(tmp_buf);
}
}
--
2.53.0
^ permalink raw reply related
* [PATCH 10/15] drm: Use trace_invoke_##name() at guarded tracepoint call sites
From: Vineeth Pillai (Google) @ 2026-03-12 15:05 UTC (permalink / raw)
Cc: Vineeth Pillai (Google), Steven Rostedt, Peter Zijlstra,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Harry Wentland, Leo Li, Rodrigo Siqueira, Matthew Brost,
Danilo Krummrich, Philipp Stanner, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Sunil Khatri,
Srinivasan Shanmugam, Tvrtko Ursulin, Liu01 Tong,
Mario Limonciello, Kees Cook, Prike Liang, Timur Kristóf,
André Almeida, Jesse.Zhang, Philip Yang, Alex Hung,
Aurabindo Pillai, Ray Wu, Wayne Lin, Mario Limonciello (AMD),
Ivan Lipski, Dominik Kaszewski, amd-gfx, dri-devel, linux-kernel,
linux-trace-kernel
In-Reply-To: <20260312150523.2054552-1-vineeth@bitbyteword.org>
Replace trace_foo() with the new trace_invoke_foo() at sites already
guarded by trace_foo_enabled(), avoiding a redundant
static_branch_unlikely() re-evaluation inside the tracepoint.
trace_invoke_foo() calls the tracepoint callbacks directly without
utilizing the static branch again.
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org>
Assisted-by: Claude:claude-sonnet-4-6
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 ++--
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
drivers/gpu/drm/scheduler/sched_entity.c | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 24e4b4fc91564..cdcb33edb2bb6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1012,7 +1012,7 @@ static void trace_amdgpu_cs_ibs(struct amdgpu_cs_parser *p)
struct amdgpu_job *job = p->jobs[i];
for (j = 0; j < job->num_ibs; ++j)
- trace_amdgpu_cs(p, job, &job->ibs[j]);
+ trace_invoke_amdgpu_cs(p, job, &job->ibs[j]);
}
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index f2beb980e3c3a..2d34608fd7298 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1394,7 +1394,7 @@ int amdgpu_vm_bo_update(struct amdgpu_device *adev, struct amdgpu_bo_va *bo_va,
if (trace_amdgpu_vm_bo_mapping_enabled()) {
list_for_each_entry(mapping, &bo_va->valids, list)
- trace_amdgpu_vm_bo_mapping(mapping);
+ trace_invoke_amdgpu_vm_bo_mapping(mapping);
}
error_free:
@@ -2167,7 +2167,7 @@ void amdgpu_vm_bo_trace_cs(struct amdgpu_vm *vm, struct ww_acquire_ctx *ticket)
continue;
}
- trace_amdgpu_vm_bo_cs(mapping);
+ trace_invoke_amdgpu_vm_bo_cs(mapping);
}
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index b3d6f2cd8ab6f..844b8fc5359a3 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5190,7 +5190,7 @@ static void amdgpu_dm_backlight_set_level(struct amdgpu_display_manager *dm,
}
if (trace_amdgpu_dm_brightness_enabled()) {
- trace_amdgpu_dm_brightness(__builtin_return_address(0),
+ trace_invoke_amdgpu_dm_brightness(__builtin_return_address(0),
user_brightness,
brightness,
caps->aux_support,
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c
index fe174a4857be7..003c015b3bfcf 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -429,7 +429,7 @@ static bool drm_sched_entity_add_dependency_cb(struct drm_sched_entity *entity,
if (trace_drm_sched_job_unschedulable_enabled() &&
!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &entity->dependency->flags))
- trace_drm_sched_job_unschedulable(sched_job, entity->dependency);
+ trace_invoke_drm_sched_job_unschedulable(sched_job, entity->dependency);
if (!dma_fence_add_callback(entity->dependency, &entity->cb,
drm_sched_entity_wakeup))
@@ -586,7 +586,7 @@ void drm_sched_entity_push_job(struct drm_sched_job *sched_job)
unsigned long index;
xa_for_each(&sched_job->dependencies, index, entry)
- trace_drm_sched_job_add_dep(sched_job, entry);
+ trace_invoke_drm_sched_job_add_dep(sched_job, entry);
}
atomic_inc(entity->rq->sched->score);
WRITE_ONCE(entity->last_user, current->group_leader);
--
2.53.0
^ permalink raw reply related
* [PATCH 09/15] fsi: Use trace_invoke_##name() at guarded tracepoint call sites
From: Vineeth Pillai (Google) @ 2026-03-12 15:05 UTC (permalink / raw)
Cc: Vineeth Pillai (Google), Steven Rostedt, Peter Zijlstra,
Eddie James, Ninad Palsule, Joel Stanley, Andrew Jeffery,
linux-fsi, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-trace-kernel
In-Reply-To: <20260312150523.2054552-1-vineeth@bitbyteword.org>
Replace trace_foo() with the new trace_invoke_foo() at sites already
guarded by trace_foo_enabled(), avoiding a redundant
static_branch_unlikely() re-evaluation inside the tracepoint.
trace_invoke_foo() calls the tracepoint callbacks directly without
utilizing the static branch again.
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org>
Assisted-by: Claude:claude-sonnet-4-6
---
drivers/fsi/fsi-master-aspeed.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/fsi/fsi-master-aspeed.c b/drivers/fsi/fsi-master-aspeed.c
index aa1380cdff338..07b88ef49cc47 100644
--- a/drivers/fsi/fsi-master-aspeed.c
+++ b/drivers/fsi/fsi-master-aspeed.c
@@ -229,7 +229,7 @@ static int check_errors(struct fsi_master_aspeed *aspeed, int err)
opb_readl(aspeed, ctrl_base + FSI_MSTAP0, &mstap0);
opb_readl(aspeed, ctrl_base + FSI_MESRB0, &mesrb0);
- trace_fsi_master_aspeed_opb_error(
+ trace_invoke_fsi_master_aspeed_opb_error(
be32_to_cpu(mresp0),
be32_to_cpu(mstap0),
be32_to_cpu(mesrb0));
--
2.53.0
^ permalink raw reply related
* [PATCH 08/15] dma-buf: Use trace_invoke_##name() at guarded tracepoint call sites
From: Vineeth Pillai (Google) @ 2026-03-12 15:05 UTC (permalink / raw)
Cc: Vineeth Pillai (Google), Steven Rostedt, Peter Zijlstra,
Sumit Semwal, Christian König, linux-media, dri-devel,
linaro-mm-sig, linux-kernel, linux-trace-kernel
In-Reply-To: <20260312150523.2054552-1-vineeth@bitbyteword.org>
Replace trace_foo() with the new trace_invoke_foo() at sites already
guarded by trace_foo_enabled(), avoiding a redundant
static_branch_unlikely() re-evaluation inside the tracepoint.
trace_invoke_foo() calls the tracepoint callbacks directly without
utilizing the static branch again.
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org>
Assisted-by: Claude:claude-sonnet-4-6
---
drivers/dma-buf/dma-fence.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 35afcfcac5910..8884ad1ff0dab 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -535,7 +535,7 @@ dma_fence_wait_timeout(struct dma_fence *fence, bool intr, signed long timeout)
if (trace_dma_fence_wait_start_enabled()) {
rcu_read_lock();
- trace_dma_fence_wait_start(fence);
+ trace_invoke_dma_fence_wait_start(fence);
rcu_read_unlock();
}
if (fence->ops->wait)
@@ -544,7 +544,7 @@ dma_fence_wait_timeout(struct dma_fence *fence, bool intr, signed long timeout)
ret = dma_fence_default_wait(fence, intr, timeout);
if (trace_dma_fence_wait_end_enabled()) {
rcu_read_lock();
- trace_dma_fence_wait_end(fence);
+ trace_invoke_dma_fence_wait_end(fence);
rcu_read_unlock();
}
return ret;
--
2.53.0
^ permalink raw reply related
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