* Re: [RFC bpf-next 00/12] bpf: tracing_multi link
From: Alexei Starovoitov @ 2026-02-03 23:17 UTC (permalink / raw)
To: Jiri Olsa
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, bpf,
linux-trace-kernel, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, Menglong Dong, Steven Rostedt
In-Reply-To: <20260203093819.2105105-1-jolsa@kernel.org>
On Tue, Feb 3, 2026 at 1:38 AM Jiri Olsa <jolsa@kernel.org> wrote:
>
> hi,
> as an option to Meglong's change [1] I'm sending proposal for tracing_multi
> link that does not add static trampoline but attaches program to all needed
> trampolines.
>
> This approach keeps the same performance but has some drawbacks:
>
> - when attaching 20k functions we allocate and attach 20k trampolines
> - during attachment we hold each trampoline mutex, so for above
> 20k functions we will hold 20k mutexes during the attachment,
> should be very prone to deadlock, but haven't hit it yet
If you check that it's sorted and always take them in the same order
then there will be no deadlock.
Or just grab one global mutex first and then grab trampolines mutexes
next in any order. The global one will serialize this attach operation.
> It looks the trampoline allocations/generation might not be big a problem
> and I'll try to find a solution for holding that many mutexes. If there's
> no better solution I think having one read/write mutex for tracing multi
> link attach/detach should work.
If you mean to have one global mutex as I proposed above then I don't see
a downside. It only serializes multiple libbpf calls.
overall makes sense to me.
^ permalink raw reply
* [PATCH net-next 04/15] trace: mptcp: add mptcp_rcvbuf_grow tracepoint
From: Matthieu Baerts (NGI0) @ 2026-02-03 18:41 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Shuah Khan
Cc: netdev, mptcp, linux-kernel, linux-kselftest,
Matthieu Baerts (NGI0), Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, linux-trace-kernel
In-Reply-To: <20260203-net-next-mptcp-misc-feat-6-20-v1-0-31ec8bfc56d1@kernel.org>
From: Paolo Abeni <pabeni@redhat.com>
Similar to tcp, provide a new tracepoint to better understand
mptcp_rcv_space_adjust() behavior, which presents many artifacts.
Note that the used format string is so long that I preferred
wrap it, contrary to guidance for quoted strings.
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
To: Steven Rostedt <rostedt@goodmis.org>
To: Masami Hiramatsu <mhiramat@kernel.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: linux-trace-kernel@vger.kernel.org
---
include/trace/events/mptcp.h | 80 ++++++++++++++++++++++++++++++++++++++++++++
net/mptcp/protocol.c | 3 ++
2 files changed, 83 insertions(+)
diff --git a/include/trace/events/mptcp.h b/include/trace/events/mptcp.h
index 085b749cdd97..269d949b2025 100644
--- a/include/trace/events/mptcp.h
+++ b/include/trace/events/mptcp.h
@@ -5,7 +5,13 @@
#if !defined(_TRACE_MPTCP_H) || defined(TRACE_HEADER_MULTI_READ)
#define _TRACE_MPTCP_H
+#include <linux/ipv6.h>
+#include <linux/tcp.h>
#include <linux/tracepoint.h>
+#include <net/ipv6.h>
+#include <net/tcp.h>
+#include <linux/sock_diag.h>
+#include <net/rstreason.h>
#define show_mapping_status(status) \
__print_symbolic(status, \
@@ -178,6 +184,80 @@ TRACE_EVENT(subflow_check_data_avail,
__entry->skb)
);
+#include <trace/events/net_probe_common.h>
+
+TRACE_EVENT(mptcp_rcvbuf_grow,
+
+ TP_PROTO(struct sock *sk, int time),
+
+ TP_ARGS(sk, time),
+
+ TP_STRUCT__entry(
+ __field(int, time)
+ __field(__u32, rtt_us)
+ __field(__u32, copied)
+ __field(__u32, inq)
+ __field(__u32, space)
+ __field(__u32, ooo_space)
+ __field(__u32, rcvbuf)
+ __field(__u32, rcv_wnd)
+ __field(__u8, scaling_ratio)
+ __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(const void *, skaddr)
+ ),
+
+ TP_fast_assign(
+ struct mptcp_sock *msk = mptcp_sk(sk);
+ struct inet_sock *inet = inet_sk(sk);
+ bool ofo_empty;
+ __be32 *p32;
+
+ __entry->time = time;
+ __entry->rtt_us = msk->rcvq_space.rtt_us >> 3;
+ __entry->copied = msk->rcvq_space.copied;
+ __entry->inq = mptcp_inq_hint(sk);
+ __entry->space = msk->rcvq_space.space;
+ ofo_empty = RB_EMPTY_ROOT(&msk->out_of_order_queue);
+ __entry->ooo_space = ofo_empty ? 0 :
+ MPTCP_SKB_CB(msk->ooo_last_skb)->end_seq -
+ msk->ack_seq;
+
+ __entry->rcvbuf = sk->sk_rcvbuf;
+ __entry->rcv_wnd = atomic64_read(&msk->rcv_wnd_sent) -
+ msk->ack_seq;
+ __entry->scaling_ratio = msk->scaling_ratio;
+ __entry->sport = ntohs(inet->inet_sport);
+ __entry->dport = ntohs(inet->inet_dport);
+ __entry->family = sk->sk_family;
+
+ p32 = (__be32 *)__entry->saddr;
+ *p32 = inet->inet_saddr;
+
+ p32 = (__be32 *)__entry->daddr;
+ *p32 = inet->inet_daddr;
+
+ TP_STORE_ADDRS(__entry, inet->inet_saddr, inet->inet_daddr,
+ sk->sk_v6_rcv_saddr, sk->sk_v6_daddr);
+
+ __entry->skaddr = sk;
+ ),
+
+ TP_printk("time=%u rtt_us=%u copied=%u inq=%u space=%u ooo=%u scaling_ratio=%u "
+ "rcvbuf=%u rcv_wnd=%u family=%d sport=%hu dport=%hu saddr=%pI4 "
+ "daddr=%pI4 saddrv6=%pI6c daddrv6=%pI6c skaddr=%p",
+ __entry->time, __entry->rtt_us, __entry->copied,
+ __entry->inq, __entry->space, __entry->ooo_space,
+ __entry->scaling_ratio, __entry->rcvbuf, __entry->rcv_wnd,
+ __entry->family, __entry->sport, __entry->dport,
+ __entry->saddr, __entry->daddr, __entry->saddr_v6,
+ __entry->daddr_v6, __entry->skaddr)
+);
#endif /* _TRACE_MPTCP_H */
/* This part must be outside protection */
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 514272179714..197ee169c0bc 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -28,6 +28,8 @@
#include "protocol.h"
#include "mib.h"
+static unsigned int mptcp_inq_hint(const struct sock *sk);
+
#define CREATE_TRACE_POINTS
#include <trace/events/mptcp.h>
@@ -2133,6 +2135,7 @@ static void mptcp_rcv_space_adjust(struct mptcp_sock *msk, int copied)
if (msk->rcvq_space.copied <= msk->rcvq_space.space)
goto new_measure;
+ trace_mptcp_rcvbuf_grow(sk, time);
if (mptcp_rcvbuf_grow(sk, msk->rcvq_space.copied)) {
/* Make subflows follow along. If we do not do this, we
* get drops at subflow level if skbs can't be moved to
--
2.51.0
^ permalink raw reply related
* [PATCH net-next 00/15] mptcp: misc. features for v6.20/7.0
From: Matthieu Baerts (NGI0) @ 2026-02-03 18:41 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Shuah Khan
Cc: netdev, mptcp, linux-kernel, linux-kselftest,
Matthieu Baerts (NGI0), Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, linux-trace-kernel, David Laight, Gang Yan,
Thomas Weißschuh, Geliang Tang
This series contains a few independent new features, and small fixes for
net-next:
- Patches 1-2: two small fixes linked to the MPTCP receive buffer that
are not urgent, requiring code that has been recently changed, and is
needed for the next patch. Because we are at the end of the cycle, it
seems easier to send them to net-next, instead of dealing with
conflicts between net and net-next.
- Patch 3: a refactoring to simplify the code around MPTCP DRS.
- Patch 4: a new trace event for MPTCP to help debugging receive buffer
auto-tuning issues.
- Patch 5: align internal MPTCP PM structure with NL specs, just to
manipulate the same thing.
- Patch 6: convert some min_t(int, ...) to min(): cleaner, and to avoid
future warnings.
- Patch 7: prepare future extensions replacing sk_write_space().
- Patch 8: sort all #include in MPTCP Diag tool in the selftests to
prevent future potential conflicts and ease the reading.
- Patches 9-11: improve the MPTCP Join selftest by waiting for an event
instead of a "random" sleep.
- Patches 12-14: some small cleanups in the selftests, seen while
working on the previous patches.
- Patch 15: avoid marking subtests as skipped while still validating
most checks when executing the last MPTCP selftests on older kernels.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
David Laight (1):
mptcp: Change some dubious min_t(int, ...) to min()
Geliang Tang (1):
mptcp: allow overridden write_space to be invoked
Matthieu Baerts (NGI0) (9):
mptcp: pm: align endpoint flags size with the NL specs
selftests: mptcp: diag: sort all #include
selftests: mptcp: join: wait for estab event instead of MPJ
selftests: mptcp: join: fix wait_mpj helper
selftests: mptcp: join: userspace: wait for new events
selftests: mptcp: join chk_stale_nr: avoid dup stats
selftests: mptcp: join: avoid declaring i if not used
selftests: mptcp: connect cleanup TFO setup
selftests: mptcp: join: no SKIP mark for group checks
Paolo Abeni (4):
mptcp: do not account for OoO in mptcp_rcvbuf_grow()
mptcp: fix receive space timestamp initialization
mptcp: consolidate rcv space init
trace: mptcp: add mptcp_rcvbuf_grow tracepoint
include/trace/events/mptcp.h | 80 ++++++++++++++++
net/mptcp/protocol.c | 56 ++++++-----
net/mptcp/protocol.h | 12 ++-
net/mptcp/subflow.c | 2 -
tools/testing/selftests/net/mptcp/mptcp_connect.c | 17 ++--
tools/testing/selftests/net/mptcp/mptcp_diag.c | 29 +++---
tools/testing/selftests/net/mptcp/mptcp_join.sh | 107 +++++++++++-----------
7 files changed, 189 insertions(+), 114 deletions(-)
---
base-commit: fae1c659d7bd5640012be21b5b5d6490b83c0df8
change-id: 20260128-net-next-mptcp-misc-feat-6-20-0eb96b13bc4a
Best regards,
--
Matthieu Baerts (NGI0) <matttbe@kernel.org>
^ permalink raw reply
* Re: [RFC PATCH v1 05/37] KVM: guest_memfd: Wire up kvm_get_memory_attributes() to per-gmem attributes
From: Jason Gunthorpe @ 2026-02-03 18:16 UTC (permalink / raw)
To: Xu Yilun
Cc: Sean Christopherson, Ackerley Tng, Alexey Kardashevskiy, cgroups,
kvm, linux-doc, linux-fsdevel, linux-kernel, linux-kselftest,
linux-mm, linux-trace-kernel, x86, akpm, binbin.wu, bp, brauner,
chao.p.peng, chenhuacai, corbet, dave.hansen, dave.hansen, david,
dmatlack, erdemaktas, fan.du, fvdl, haibo1.xu, hannes, hch, hpa,
hughd, ira.weiny, isaku.yamahata, jack, james.morse, jarkko,
jgowans, jhubbard, jroedel, jthoughton, jun.miao, kai.huang,
keirf, kent.overstreet, liam.merwick, maciej.wieczor-retman, mail,
maobibo, mathieu.desnoyers, maz, mhiramat, mhocko, mic,
michael.roth, mingo, mlevitsk, mpe, muchun.song, nikunj, nsaenz,
oliver.upton, palmer, pankaj.gupta, paul.walmsley, pbonzini,
peterx, pgonda, prsampat, pvorel, qperret, richard.weiyang,
rick.p.edgecombe, rientjes, rostedt, roypat, rppt, shakeel.butt,
shuah, steven.price, steven.sistare, suzuki.poulose, tabba, tglx,
thomas.lendacky, vannapurve, vbabka, viro, vkuznets, wei.w.wang,
will, willy, wyihan, xiaoyao.li, yan.y.zhao, yilun.xu, yuzenghui,
zhiquan1.li
In-Reply-To: <aYHGVQTF6RUs7r3g@yilunxu-OptiPlex-7050>
On Tue, Feb 03, 2026 at 05:56:37PM +0800, Xu Yilun wrote:
> > +1. For guest_memfd, we initially defined per-VM memory attributes to track
> > private vs. shared. But as Ackerley noted, we are in the process of deprecating
> > that support, e.g. by making it incompatible with various guest_memfd features,
> > in favor of having each guest_memfd instance track the state of a given page.
> >
> > The original guest_memfd design was that it would _only_ hold private pages, and
> > so tracking private vs. shared in guest_memfd didn't make any sense. As we've
> > pivoted to in-place conversion, tracking private vs. shared in the guest_memfd
> > has basically become mandatory. We could maaaaaybe make it work with per-VM
> > attributes, but it would be insanely complex.
> >
> > For a dmabuf fd, the story is the same as guest_memfd. Unless private vs. shared
> > is all or nothing, and can never change, then the only entity that can track that
> > info is the owner of the dmabuf. And even if the private vs. shared attributes
> > are constant, tracking it external to KVM makes sense, because then the provider
> > can simply hardcode %true/%false.
>
> For CoCo-VM and Tee-IO, I'm wondering if host or KVM has to maintain
> the private/shared attribute for "assigned MMIO". I'm not naming them
> "host MMIO" cause unlike RAM host never needs to access them, either in
> private manner or shared manner.
>
> Traditionally, host maps these MMIOs only because KVM needs HVA->HPA
> mapping to find pfn and setup KVM MMU.
This is not actually completely true, the host mapping still ends up
being used by KVM if it happens to trap and emulate a MMIO touching
instruction.
It really shouldn't do this, but there is a whole set of complex
machinery in KVM and qemu to handle this case.
For example if the MSI-X window is not properly aligned then you have
some MMIO that is trapped and must be reflected to real HW.
So the sharable parts of the BAR should still end up being mmaped into
userspace, I think.
Which means we need VFIO to know what they are, and hopefully it is
just static based on the TDISP reports..
Jason
^ permalink raw reply
* Re: [RFC PATCH v1 05/37] KVM: guest_memfd: Wire up kvm_get_memory_attributes() to per-gmem attributes
From: Jason Gunthorpe @ 2026-02-03 18:13 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Sean Christopherson, Ackerley Tng, cgroups, kvm, linux-doc,
linux-fsdevel, linux-kernel, linux-kselftest, linux-mm,
linux-trace-kernel, x86, akpm, binbin.wu, bp, brauner,
chao.p.peng, chenhuacai, corbet, dave.hansen, dave.hansen, david,
dmatlack, erdemaktas, fan.du, fvdl, haibo1.xu, hannes, hch, hpa,
hughd, ira.weiny, isaku.yamahata, jack, james.morse, jarkko,
jgowans, jhubbard, jroedel, jthoughton, jun.miao, kai.huang,
keirf, kent.overstreet, liam.merwick, maciej.wieczor-retman, mail,
maobibo, mathieu.desnoyers, maz, mhiramat, mhocko, mic,
michael.roth, mingo, mlevitsk, mpe, muchun.song, nikunj, nsaenz,
oliver.upton, palmer, pankaj.gupta, paul.walmsley, pbonzini,
peterx, pgonda, prsampat, pvorel, qperret, richard.weiyang,
rick.p.edgecombe, rientjes, rostedt, roypat, rppt, shakeel.butt,
shuah, steven.price, steven.sistare, suzuki.poulose, tabba, tglx,
thomas.lendacky, vannapurve, vbabka, viro, vkuznets, wei.w.wang,
will, willy, wyihan, xiaoyao.li, yan.y.zhao, yilun.xu, yuzenghui,
zhiquan1.li
In-Reply-To: <586121cf-eb31-468c-9300-e670671653e1@amd.com>
On Tue, Feb 03, 2026 at 12:07:46PM +1100, Alexey Kardashevskiy wrote:
> On 29/1/26 12:16, Jason Gunthorpe wrote:
> > On Wed, Jan 28, 2026 at 05:03:27PM -0800, Sean Christopherson wrote:
> >
> > > For a dmabuf fd, the story is the same as guest_memfd. Unless private vs. shared
> > > is all or nothing, and can never change, then the only entity that can track that
> > > info is the owner of the dmabuf. And even if the private vs. shared attributes
> > > are constant, tracking it external to KVM makes sense, because then the provider
> > > can simply hardcode %true/%false.
> >
> > Oh my I had not given that bit any thought. My remarks were just about
> > normal non-CC systems.
> >
> > So MMIO starts out shared, and then converts to private when the guest
> > triggers it. It is not all or nothing, there are permanent shared
> > holes in the MMIO ranges too.
> >
> > Beyond that I don't know what people are thinking.
> >
> > Clearly VFIO has to revoke and disable the DMABUF once any of it
> > becomes private.
>
> huh? Private MMIO still has to be mapped in the NPT (well, on
> AMD). It is the userspace mapping which we do not want^wneed and we
> do not by using dmabuf.
Well, we don't know what the DMABUF got imported into, so the non-KVM
importers using the shared mapping certainly have to drop it.
How exactly to make that happen is going to be interesting..
Jason
^ permalink raw reply
* Re: [PATCH] bpf: add missing __printf attributes
From: Alexei Starovoitov @ 2026-02-03 18:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Song Liu, KP Singh, Matt Bobrowski,
Steven Rostedt, Masami Hiramatsu, Martin KaFai Lau,
Eduard Zingerman, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Jiri Olsa, Mathieu Desnoyers,
Mykyta Yatsenko, Kumar Kartikeya Dwivedi, bpf, LKML,
linux-trace-kernel
In-Reply-To: <ab709a00-3a7f-423f-9d8b-b2cd17fef76f@app.fastmail.com>
On Tue, Feb 3, 2026 at 9:44 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Feb 3, 2026, at 18:24, Alexei Starovoitov wrote:
> > On Tue, Feb 3, 2026 at 8:58 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >> On Tue, Feb 3, 2026, at 17:34, Alexei Starovoitov wrote:
> >> > On Tue, Feb 3, 2026 at 8:27 AM Arnd Bergmann <arnd@kernel.org> wrote:
> >> >>
> >> >> From: Arnd Bergmann <arnd@arndb.de>
> >> >>
> >> >> Some internal functions in bpf produce a warning when -Wsuggest-attribute=format
> >> >> is passed to the compiler, e.g. in 'make W=1':
> >> >>
> >> >> kernel/trace/bpf_trace.c: In function '____bpf_trace_printk':
> >> >> kernel/trace/bpf_trace.c:377:9: error: function '____bpf_trace_printk' might be a candidate for 'gnu_printf' format attribute [-Werror=suggest-attribute=format]
> >> >> 377 | ret = bstr_printf(data.buf, MAX_BPRINTF_BUF, fmt, data.bin_args);
> >> >> | ^~~
> >> >>
> >> >> The attribute here is useless since there are no callers from C code,
> >> >> but it helps to shut up the output anyway so we can eventually turn
> >> >> the warning option on by default.
> >> >>
> >> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >> >
> >> > This was discussed and it's incorrect.
> >>
> >> Do you have a reference to why it's incorrect? It seems harmless
> >> and gives me a clean kernel build in combination with a handful
> >> of other fixes after enabling the option by default, but I assume
> >> I'm missing something,
> >
> > because it's not a printf format. There are no varags here.
> > gnu_printf attribute takes two arguments:
> > format (archetype, string-index, first-to-check)
> > Also
> > "GCC requires a function with the 'format' attribute to be variadic"
>
> My impression was that at least vbin_printf() falls into the
> same category as vprintf(), which is explictly mentioned in the
> gcc documentation:
>
> For functions where the arguments are not available to be checked
> (such as 'vprintf'), specify the third parameter as zero.
Not quite. That comment in gcc doc is somewhat misleading.
zero means that it should be va_list.
Examples of correct annotations:
static __attribute__((unused, format(printf, 2, 0)))
int vfprintf(FILE *stream, const char *fmt, va_list args)
static __attribute__((unused, format(printf, 2, 3)))
int fprintf(FILE *stream, const char *fmt, ...)
A comment in gcc sources:
/* Functions taking a va_list normally pass a non-literal format
string. These functions typically are declared with
first_arg_num == 0, ...
Currently gcc doesn't go deep into va_list to validate them,
since they're likely not compile time constants,
but that's the meaning of zero.
> I also see the comment about bstr_printf() mention that it
> uses a vsnprintf() compatible format, which would indicate that
> marking the format argument isn't wrong, though I agree it is
> not actually useful if there are no callers that pass a string
> literal.
In general I don't think it's a good idea to add nop annotations
just to shut up over eager compiler warning.
^ permalink raw reply
* Re: [PATCH] bpf: add missing __printf attributes
From: Arnd Bergmann @ 2026-02-03 17:44 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Arnd Bergmann, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Song Liu, KP Singh, Matt Bobrowski,
Steven Rostedt, Masami Hiramatsu, Martin KaFai Lau,
Eduard Zingerman, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Jiri Olsa, Mathieu Desnoyers,
Mykyta Yatsenko, Kumar Kartikeya Dwivedi, bpf, LKML,
linux-trace-kernel
In-Reply-To: <CAADnVQKn4xP9s_koBuP7D_eqUX0dSPwUr-dOj3mTZNTh_VxqKQ@mail.gmail.com>
On Tue, Feb 3, 2026, at 18:24, Alexei Starovoitov wrote:
> On Tue, Feb 3, 2026 at 8:58 AM Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tue, Feb 3, 2026, at 17:34, Alexei Starovoitov wrote:
>> > On Tue, Feb 3, 2026 at 8:27 AM Arnd Bergmann <arnd@kernel.org> wrote:
>> >>
>> >> From: Arnd Bergmann <arnd@arndb.de>
>> >>
>> >> Some internal functions in bpf produce a warning when -Wsuggest-attribute=format
>> >> is passed to the compiler, e.g. in 'make W=1':
>> >>
>> >> kernel/trace/bpf_trace.c: In function '____bpf_trace_printk':
>> >> kernel/trace/bpf_trace.c:377:9: error: function '____bpf_trace_printk' might be a candidate for 'gnu_printf' format attribute [-Werror=suggest-attribute=format]
>> >> 377 | ret = bstr_printf(data.buf, MAX_BPRINTF_BUF, fmt, data.bin_args);
>> >> | ^~~
>> >>
>> >> The attribute here is useless since there are no callers from C code,
>> >> but it helps to shut up the output anyway so we can eventually turn
>> >> the warning option on by default.
>> >>
>> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> >
>> > This was discussed and it's incorrect.
>>
>> Do you have a reference to why it's incorrect? It seems harmless
>> and gives me a clean kernel build in combination with a handful
>> of other fixes after enabling the option by default, but I assume
>> I'm missing something,
>
> because it's not a printf format. There are no varags here.
> gnu_printf attribute takes two arguments:
> format (archetype, string-index, first-to-check)
> Also
> "GCC requires a function with the 'format' attribute to be variadic"
My impression was that at least vbin_printf() falls into the
same category as vprintf(), which is explictly mentioned in the
gcc documentation:
For functions where the arguments are not available to be checked
(such as 'vprintf'), specify the third parameter as zero.
I also see the comment about bstr_printf() mention that it
uses a vsnprintf() compatible format, which would indicate that
marking the format argument isn't wrong, though I agree it is
not actually useful if there are no callers that pass a string
literal.
>> > Commit 7bf819aa992f ("vsnprintf: Mark binary printing functions with
>> > __printf() attribute") should be reverted instead.
>>
>> Reverting that one would appear to introduce warnings elsewhere,
>> so that would not be a complete fix either.
>
> Somebody needs to root cause it and fix it properly.
> Adding more incorrect annotation is not a solution.
I've tried reverting it here now, will see what I can come up
with. We can probably use the same trick that I used "[PATCH]
[v2] tracing: move __printf() attribute on __ftrace_vbprintk()",
annotate only the definition but not the declaration so the
format string warning doesn't propagate to the callers.
Arnd
^ permalink raw reply
* Re: [PATCH v7 2/6] x86/asm: Avoid emitting DWARF CFI for non-VDSO
From: H. Peter Anvin @ 2026-02-03 17:35 UTC (permalink / raw)
To: Jens Remus, linux-kernel, linux-trace-kernel, bpf, x86, linux-mm,
Steven Rostedt
Cc: Josh Poimboeuf, Masami Hiramatsu, Mathieu Desnoyers,
Peter Zijlstra, Ingo Molnar, Jiri Olsa, Arnaldo Carvalho de Melo,
Namhyung Kim, Thomas Gleixner, Andrii Nakryiko, Indu Bhagat,
Jose E. Marchesi, Beau Belgrave, Linus Torvalds, Andrew Morton,
Florian Weimer, Kees Cook, Carlos O'Donell, Sam James,
Dylan Hatch, Borislav Petkov, Dave Hansen, David Hildenbrand,
Liam R. Howlett, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Suren Baghdasaryan, Vlastimil Babka, Heiko Carstens,
Vasily Gorbik, Steven Rostedt (Google)
In-Reply-To: <20260203171958.1522030-3-jremus@linux.ibm.com>
On February 3, 2026 9:19:53 AM PST, Jens Remus <jremus@linux.ibm.com> wrote:
>From: Josh Poimboeuf <jpoimboe@kernel.org>
>
>It was decided years ago that .cfi_* annotations aren't maintainable in
>the kernel. They were replaced by objtool unwind hints. For the kernel
>proper, ensure the CFI_* macros don't do anything.
>
>On the other hand the VDSO library *does* use them, so user space can
>unwind through it.
>
>Make sure these macros only work for VDSO. They aren't actually being
>used outside of VDSO anyway, so there's no functional change.
>
>Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
>Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
>Signed-off-by: Jens Remus <jremus@linux.ibm.com>
>---
> arch/x86/include/asm/dwarf2.h | 51 ++++++++++++++++++++++++-----------
> 1 file changed, 35 insertions(+), 16 deletions(-)
>
>diff --git a/arch/x86/include/asm/dwarf2.h b/arch/x86/include/asm/dwarf2.h
>index 09c9684d3ad6..7cc30500c095 100644
>--- a/arch/x86/include/asm/dwarf2.h
>+++ b/arch/x86/include/asm/dwarf2.h
>@@ -6,6 +6,15 @@
> #warning "asm/dwarf2.h should be only included in pure assembly files"
> #endif
>
>+#ifdef BUILD_VDSO
>+
>+ /*
>+ * For the vDSO, emit both runtime unwind information and debug
>+ * symbols for the .dbg file.
>+ */
>+
>+ .cfi_sections .eh_frame, .debug_frame
>+
> #define CFI_STARTPROC .cfi_startproc
> #define CFI_ENDPROC .cfi_endproc
> #define CFI_DEF_CFA .cfi_def_cfa
>@@ -22,21 +31,31 @@
> #define CFI_ESCAPE .cfi_escape
> #define CFI_SIGNAL_FRAME .cfi_signal_frame
>
>-#ifndef BUILD_VDSO
>- /*
>- * Emit CFI data in .debug_frame sections, not .eh_frame sections.
>- * The latter we currently just discard since we don't do DWARF
>- * unwinding at runtime. So only the offline DWARF information is
>- * useful to anyone. Note we should not use this directive if we
>- * ever decide to enable DWARF unwinding at runtime.
>- */
>- .cfi_sections .debug_frame
>-#else
>- /*
>- * For the vDSO, emit both runtime unwind information and debug
>- * symbols for the .dbg file.
>- */
>- .cfi_sections .eh_frame, .debug_frame
>-#endif
>+#else /* !BUILD_VDSO */
>+
>+/*
>+ * On x86, these macros aren't used outside VDSO. As well they shouldn't be:
>+ * they're fragile and very difficult to maintain.
>+ */
>+
>+.macro nocfi args:vararg
>+.endm
>+
>+#define CFI_STARTPROC nocfi
>+#define CFI_ENDPROC nocfi
>+#define CFI_DEF_CFA nocfi
>+#define CFI_DEF_CFA_REGISTER nocfi
>+#define CFI_DEF_CFA_OFFSET nocfi
>+#define CFI_ADJUST_CFA_OFFSET nocfi
>+#define CFI_OFFSET nocfi
>+#define CFI_REL_OFFSET nocfi
>+#define CFI_REGISTER nocfi
>+#define CFI_RESTORE nocfi
>+#define CFI_REMEMBER_STATE nocfi
>+#define CFI_RESTORE_STATE nocfi
>+#define CFI_UNDEFINED nocfi
>+#define CFI_ESCAPE nocfi
>+
>+#endif /* !BUILD_VDSO */
>
> #endif /* _ASM_X86_DWARF2_H */
Maybe we should move these into x86/entry/vdso/common instead?
^ permalink raw reply
* Re: [PATCH] bpf: add missing __printf attributes
From: Alexei Starovoitov @ 2026-02-03 17:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Song Liu, KP Singh, Matt Bobrowski,
Steven Rostedt, Masami Hiramatsu, Martin KaFai Lau,
Eduard Zingerman, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Jiri Olsa, Mathieu Desnoyers,
Mykyta Yatsenko, Kumar Kartikeya Dwivedi, bpf, LKML,
linux-trace-kernel
In-Reply-To: <5f9c89fe-df1d-4eb4-b724-08f8d90fcc59@app.fastmail.com>
On Tue, Feb 3, 2026 at 8:58 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Feb 3, 2026, at 17:34, Alexei Starovoitov wrote:
> > On Tue, Feb 3, 2026 at 8:27 AM Arnd Bergmann <arnd@kernel.org> wrote:
> >>
> >> From: Arnd Bergmann <arnd@arndb.de>
> >>
> >> Some internal functions in bpf produce a warning when -Wsuggest-attribute=format
> >> is passed to the compiler, e.g. in 'make W=1':
> >>
> >> kernel/trace/bpf_trace.c: In function '____bpf_trace_printk':
> >> kernel/trace/bpf_trace.c:377:9: error: function '____bpf_trace_printk' might be a candidate for 'gnu_printf' format attribute [-Werror=suggest-attribute=format]
> >> 377 | ret = bstr_printf(data.buf, MAX_BPRINTF_BUF, fmt, data.bin_args);
> >> | ^~~
> >>
> >> The attribute here is useless since there are no callers from C code,
> >> but it helps to shut up the output anyway so we can eventually turn
> >> the warning option on by default.
> >>
> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >
> > This was discussed and it's incorrect.
>
> Do you have a reference to why it's incorrect? It seems harmless
> and gives me a clean kernel build in combination with a handful
> of other fixes after enabling the option by default, but I assume
> I'm missing something,
because it's not a printf format. There are no varags here.
gnu_printf attribute takes two arguments:
format (archetype, string-index, first-to-check)
Also
"GCC requires a function with the 'format' attribute to be variadic"
> > Commit 7bf819aa992f ("vsnprintf: Mark binary printing functions with
> > __printf() attribute") should be reverted instead.
>
> Reverting that one would appear to introduce warnings elsewhere,
> so that would not be a complete fix either.
Somebody needs to root cause it and fix it properly.
Adding more incorrect annotation is not a solution.
^ permalink raw reply
* Re: [PATCH v6 0/6] x86/vdso: VDSO updates and fixes for sframes
From: Jens Remus @ 2026-02-03 17:22 UTC (permalink / raw)
To: H. Peter Anvin, linux-kernel, linux-trace-kernel, bpf, x86,
linux-mm, Steven Rostedt
Cc: Josh Poimboeuf, Masami Hiramatsu, Mathieu Desnoyers,
Peter Zijlstra, Ingo Molnar, Jiri Olsa, Arnaldo Carvalho de Melo,
Namhyung Kim, Thomas Gleixner, Andrii Nakryiko, Indu Bhagat,
Jose E. Marchesi, Beau Belgrave, Linus Torvalds, Andrew Morton,
Florian Weimer, Kees Cook, Carlos O'Donell, Sam James,
Dylan Hatch, Borislav Petkov, Dave Hansen, David Hildenbrand,
Liam R. Howlett, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Suren Baghdasaryan, Vlastimil Babka, Heiko Carstens,
Vasily Gorbik
In-Reply-To: <B1CDD538-668D-48E3-A937-740B7D6575FA@zytor.com>
On 2/1/2026 9:23 AM, H. Peter Anvin wrote:
> On January 29, 2026 3:27:20 AM PST, Jens Remus <jremus@linux.ibm.com> wrote:
>> This enables generation of SFrame V3 stack trace information for VDSO on
>> x86-64. It's a continuation of Josh's and Steve's work:
>>
>> https://lore.kernel.org/all/cover.1737511963.git.jpoimboe@kernel.org/
>> https://lore.kernel.org/all/20250422183439.895236512@goodmis.org/
>>
>> This series focuses only on the VDSO code. They are helpful fixes
>> and updates that doesn't rely on sframes (although the last patch
>> is sframe related).
>>
>> This series applies on top of the latest unwind user sframe series
>> "[PATCH v13 00/18] unwind_deferred: Implement sframe handling":
>> https://lore.kernel.org/all/20260127150554.2760964-1-jremus@linux.ibm.com/
>>
>> Like above series it depends on the upcoming binutils 2.46 release to
>> be used to build executables and libraries such as VDSO with SFrame V3
>> stack trace information (using the assembler option --gsframe-3).
>> Josh Poimboeuf (6):
>> x86/vdso: Fix DWARF generation for getrandom()
>> x86/asm: Avoid emitting DWARF CFI for non-VDSO
>> x86/asm: Simplify VDSO DWARF generation
>> x86/vdso: Use SYM_FUNC_{START,END} in __kernel_vsyscall()
>> x86/vdso: Use CFI macros in __vdso_sgx_enter_enclave()
>> x86/vdso: Enable sframe generation in VDSO
>>
>> arch/Kconfig | 7 +++
>> arch/x86/entry/vdso/Makefile | 10 +++--
>> arch/x86/entry/vdso/vdso-layout.lds.S | 9 +++-
>> arch/x86/entry/vdso/vdso32/system_call.S | 10 +----
>> arch/x86/entry/vdso/vgetrandom-chacha.S | 3 +-
>> arch/x86/entry/vdso/vsgx.S | 19 +++------
>> arch/x86/include/asm/dwarf2.h | 54 +++++++++++++++++-------
>> arch/x86/include/asm/linkage.h | 33 ++++++++++++---
>> arch/x86/include/asm/vdso.h | 1 -
>> 9 files changed, 97 insertions(+), 49 deletions(-)
>>
>
> This patchset clashes *hard* with the changes already in tip:x86/entry.
Thank you for the hint! I have rebased the series on top of
tip:x86/entry and sent a v7 for review:
[PATCH v7 0/6] x86/vdso: VDSO updates and fixes for sframes
https://lore.kernel.org/all/20260203171958.1522030-1-jremus@linux.ibm.com/
Regards,
Jens
--
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.ibm.com
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
^ permalink raw reply
* [PATCH v7 3/6] x86/asm: Simplify VDSO DWARF generation
From: Jens Remus @ 2026-02-03 17:19 UTC (permalink / raw)
To: linux-kernel, linux-trace-kernel, bpf, x86, linux-mm,
Steven Rostedt
Cc: Jens Remus, Josh Poimboeuf, Masami Hiramatsu, Mathieu Desnoyers,
Peter Zijlstra, Ingo Molnar, Jiri Olsa, Arnaldo Carvalho de Melo,
Namhyung Kim, Thomas Gleixner, Andrii Nakryiko, Indu Bhagat,
Jose E. Marchesi, Beau Belgrave, Linus Torvalds, Andrew Morton,
Florian Weimer, Kees Cook, Carlos O'Donell, Sam James,
Dylan Hatch, Borislav Petkov, Dave Hansen, David Hildenbrand,
H. Peter Anvin, Liam R. Howlett, Lorenzo Stoakes, Michal Hocko,
Mike Rapoport, Suren Baghdasaryan, Vlastimil Babka,
Heiko Carstens, Vasily Gorbik, Steven Rostedt (Google)
In-Reply-To: <20260203171958.1522030-1-jremus@linux.ibm.com>
From: Josh Poimboeuf <jpoimboe@kernel.org>
Add CFI_STARTPROC and CFI_ENDPROC annotations to the SYM_FUNC_* macros
so the VDSO asm functions don't need to add them manually. Note this
only affects VDSO, the CFI_* macros are empty for the kernel proper.
[ Jens Remus: Reword commit subject and message as suggested by Josh. ]
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
---
arch/x86/entry/vdso/common/vdso-layout.lds.S | 2 +-
.../x86/entry/vdso/vdso64/vgetrandom-chacha.S | 2 --
arch/x86/entry/vdso/vdso64/vsgx.S | 4 ---
arch/x86/include/asm/linkage.h | 33 +++++++++++++++----
arch/x86/include/asm/vdso.h | 1 -
5 files changed, 28 insertions(+), 14 deletions(-)
diff --git a/arch/x86/entry/vdso/common/vdso-layout.lds.S b/arch/x86/entry/vdso/common/vdso-layout.lds.S
index a1e30be3e83d..856b8b9d278c 100644
--- a/arch/x86/entry/vdso/common/vdso-layout.lds.S
+++ b/arch/x86/entry/vdso/common/vdso-layout.lds.S
@@ -1,5 +1,5 @@
/* SPDX-License-Identifier: GPL-2.0 */
-#include <asm/vdso.h>
+#include <asm/page_types.h>
#include <asm/vdso/vsyscall.h>
#include <vdso/datapage.h>
diff --git a/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S b/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S
index cc82da9216fb..a33212594731 100644
--- a/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S
+++ b/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S
@@ -22,7 +22,6 @@ CONSTANTS: .octa 0x6b20657479622d323320646e61707865
* rcx: number of 64-byte blocks to write to output
*/
SYM_FUNC_START(__arch_chacha20_blocks_nostack)
- CFI_STARTPROC
.set output, %rdi
.set key, %rsi
.set counter, %rdx
@@ -175,5 +174,4 @@ SYM_FUNC_START(__arch_chacha20_blocks_nostack)
pxor temp,temp
ret
- CFI_ENDPROC
SYM_FUNC_END(__arch_chacha20_blocks_nostack)
diff --git a/arch/x86/entry/vdso/vdso64/vsgx.S b/arch/x86/entry/vdso/vdso64/vsgx.S
index 37a3d4c02366..c0342238c976 100644
--- a/arch/x86/entry/vdso/vdso64/vsgx.S
+++ b/arch/x86/entry/vdso/vdso64/vsgx.S
@@ -24,8 +24,6 @@
.section .text, "ax"
SYM_FUNC_START(__vdso_sgx_enter_enclave)
- /* Prolog */
- .cfi_startproc
push %rbp
.cfi_adjust_cfa_offset 8
.cfi_rel_offset %rbp, 0
@@ -143,8 +141,6 @@ SYM_FUNC_START(__vdso_sgx_enter_enclave)
jle .Lout
jmp .Lenter_enclave
- .cfi_endproc
-
_ASM_VDSO_EXTABLE_HANDLE(.Lenclu_eenter_eresume, .Lhandle_exception)
SYM_FUNC_END(__vdso_sgx_enter_enclave)
diff --git a/arch/x86/include/asm/linkage.h b/arch/x86/include/asm/linkage.h
index 9d38ae744a2e..9d7f90c57451 100644
--- a/arch/x86/include/asm/linkage.h
+++ b/arch/x86/include/asm/linkage.h
@@ -40,6 +40,10 @@
#ifdef __ASSEMBLER__
+#ifndef LINKER_SCRIPT
+#include <asm/dwarf2.h>
+#endif
+
#if defined(CONFIG_MITIGATION_RETHUNK) && !defined(__DISABLE_EXPORTS) && !defined(BUILD_VDSO)
#define RET jmp __x86_return_thunk
#else /* CONFIG_MITIGATION_RETPOLINE */
@@ -112,34 +116,51 @@
# define SYM_FUNC_ALIAS_MEMFUNC SYM_FUNC_ALIAS
#endif
+#define __SYM_FUNC_START \
+ CFI_STARTPROC ASM_NL
+
+#define __SYM_FUNC_END \
+ CFI_ENDPROC ASM_NL
+
/* SYM_TYPED_FUNC_START -- use for indirectly called globals, w/ CFI type */
#define SYM_TYPED_FUNC_START(name) \
SYM_TYPED_START(name, SYM_L_GLOBAL, SYM_F_ALIGN) \
+ __SYM_FUNC_START \
ENDBR
/* SYM_FUNC_START -- use for global functions */
#define SYM_FUNC_START(name) \
- SYM_START(name, SYM_L_GLOBAL, SYM_F_ALIGN)
+ SYM_START(name, SYM_L_GLOBAL, SYM_F_ALIGN) \
+ __SYM_FUNC_START
/* SYM_FUNC_START_NOALIGN -- use for global functions, w/o alignment */
#define SYM_FUNC_START_NOALIGN(name) \
- SYM_START(name, SYM_L_GLOBAL, SYM_A_NONE)
+ SYM_START(name, SYM_L_GLOBAL, SYM_A_NONE) \
+ __SYM_FUNC_START
/* SYM_FUNC_START_LOCAL -- use for local functions */
#define SYM_FUNC_START_LOCAL(name) \
- SYM_START(name, SYM_L_LOCAL, SYM_F_ALIGN)
+ SYM_START(name, SYM_L_LOCAL, SYM_F_ALIGN) \
+ __SYM_FUNC_START
/* SYM_FUNC_START_LOCAL_NOALIGN -- use for local functions, w/o alignment */
#define SYM_FUNC_START_LOCAL_NOALIGN(name) \
- SYM_START(name, SYM_L_LOCAL, SYM_A_NONE)
+ SYM_START(name, SYM_L_LOCAL, SYM_A_NONE) \
+ __SYM_FUNC_START
/* SYM_FUNC_START_WEAK -- use for weak functions */
#define SYM_FUNC_START_WEAK(name) \
- SYM_START(name, SYM_L_WEAK, SYM_F_ALIGN)
+ SYM_START(name, SYM_L_WEAK, SYM_F_ALIGN) \
+ __SYM_FUNC_START
/* SYM_FUNC_START_WEAK_NOALIGN -- use for weak functions, w/o alignment */
#define SYM_FUNC_START_WEAK_NOALIGN(name) \
- SYM_START(name, SYM_L_WEAK, SYM_A_NONE)
+ SYM_START(name, SYM_L_WEAK, SYM_A_NONE) \
+ __SYM_FUNC_START
+
+#define SYM_FUNC_END(name) \
+ __SYM_FUNC_END \
+ SYM_END(name, SYM_T_FUNC)
/*
* Expose 'sym' to the startup code in arch/x86/boot/startup/, by emitting an
diff --git a/arch/x86/include/asm/vdso.h b/arch/x86/include/asm/vdso.h
index e8afbe9faa5b..498ac423741c 100644
--- a/arch/x86/include/asm/vdso.h
+++ b/arch/x86/include/asm/vdso.h
@@ -2,7 +2,6 @@
#ifndef _ASM_X86_VDSO_H
#define _ASM_X86_VDSO_H
-#include <asm/page_types.h>
#include <linux/linkage.h>
#include <linux/init.h>
--
2.51.0
^ permalink raw reply related
* [PATCH v7 0/6] x86/vdso: VDSO updates and fixes for sframes
From: Jens Remus @ 2026-02-03 17:19 UTC (permalink / raw)
To: linux-kernel, linux-trace-kernel, bpf, x86, linux-mm,
Steven Rostedt
Cc: Jens Remus, Josh Poimboeuf, Masami Hiramatsu, Mathieu Desnoyers,
Peter Zijlstra, Ingo Molnar, Jiri Olsa, Arnaldo Carvalho de Melo,
Namhyung Kim, Thomas Gleixner, Andrii Nakryiko, Indu Bhagat,
Jose E. Marchesi, Beau Belgrave, Linus Torvalds, Andrew Morton,
Florian Weimer, Kees Cook, Carlos O'Donell, Sam James,
Dylan Hatch, Borislav Petkov, Dave Hansen, David Hildenbrand,
H. Peter Anvin, Liam R. Howlett, Lorenzo Stoakes, Michal Hocko,
Mike Rapoport, Suren Baghdasaryan, Vlastimil Babka,
Heiko Carstens, Vasily Gorbik
This enables generation of SFrame V3 stack trace information for VDSO on
x86-64. It's a continuation of Josh's and Steve's work:
https://lore.kernel.org/all/cover.1737511963.git.jpoimboe@kernel.org/
https://lore.kernel.org/all/20250422183439.895236512@goodmis.org/
This series focuses only on the VDSO code. They are helpful fixes
and updates that doesn't rely on sframes (although the last patch
is sframe related).
This series applies on top of tip:x86/entry:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/entry
Like the unwind user sframe series [1] it depends on the upcoming
binutils 2.46 release to be used to build the VDSO with SFrame V3
stack trace information (using the assembler option --gsframe-3).
[1]: [PATCH v13 00/18] unwind_deferred: Implement sframe handling,
https://lore.kernel.org/all/20260127150554.2760964-1-jremus@linux.ibm.com/
Changes in v7 (see individual patch notes):
- Rebase on H. Peter Anvin's vDSO changes on tip:x86/entry. (Peter)
- Simplify adding assembler option -Wa,--gsframe-3. Add for vdso64
only.
- Align to .eh_frame and mark .sframe as KEEP in vDSO linker script.
Note that GNU linker 2.46 will mark .sframe as KEEP in its default
linker script as well.
Changes in v6:
- SFrame V3 support (SFrame V2 is not supported).
- Prevent GNU_SFRAME program table entry to empty .sframe section.
- Integrate v5 review feedback. (Josh)
Regards,
Jens
Josh Poimboeuf (6):
x86/vdso: Fix DWARF generation for getrandom()
x86/asm: Avoid emitting DWARF CFI for non-VDSO
x86/asm: Simplify VDSO DWARF generation
x86/vdso: Use SYM_FUNC_{START,END} in __kernel_vsyscall()
x86/vdso: Use CFI macros in __vdso_sgx_enter_enclave()
x86/vdso: Enable sframe generation in VDSO
arch/Kconfig | 7 +++
arch/x86/entry/vdso/common/vdso-layout.lds.S | 13 ++++-
arch/x86/entry/vdso/vdso32/system_call.S | 10 +---
arch/x86/entry/vdso/vdso64/Makefile | 1 +
.../x86/entry/vdso/vdso64/vgetrandom-chacha.S | 3 +-
arch/x86/entry/vdso/vdso64/vsgx.S | 19 +++----
arch/x86/include/asm/dwarf2.h | 54 +++++++++++++------
arch/x86/include/asm/linkage.h | 33 +++++++++---
arch/x86/include/asm/vdso.h | 1 -
9 files changed, 95 insertions(+), 46 deletions(-)
--
2.51.0
^ permalink raw reply
* [PATCH v7 1/6] x86/vdso: Fix DWARF generation for getrandom()
From: Jens Remus @ 2026-02-03 17:19 UTC (permalink / raw)
To: linux-kernel, linux-trace-kernel, bpf, x86, linux-mm,
Steven Rostedt
Cc: Jens Remus, Josh Poimboeuf, Masami Hiramatsu, Mathieu Desnoyers,
Peter Zijlstra, Ingo Molnar, Jiri Olsa, Arnaldo Carvalho de Melo,
Namhyung Kim, Thomas Gleixner, Andrii Nakryiko, Indu Bhagat,
Jose E. Marchesi, Beau Belgrave, Linus Torvalds, Andrew Morton,
Florian Weimer, Kees Cook, Carlos O'Donell, Sam James,
Dylan Hatch, Borislav Petkov, Dave Hansen, David Hildenbrand,
H. Peter Anvin, Liam R. Howlett, Lorenzo Stoakes, Michal Hocko,
Mike Rapoport, Suren Baghdasaryan, Vlastimil Babka,
Heiko Carstens, Vasily Gorbik, Steven Rostedt (Google)
In-Reply-To: <20260203171958.1522030-1-jremus@linux.ibm.com>
From: Josh Poimboeuf <jpoimboe@kernel.org>
Add CFI annotations to the VDSO implementation of getrandom() so it will
have valid DWARF unwinding metadata.
Fixes: 33385150ac45 ("x86: vdso: Wire up getrandom() vDSO implementation")
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
---
arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S b/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S
index bcba5639b8ee..cc82da9216fb 100644
--- a/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S
+++ b/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S
@@ -4,7 +4,7 @@
*/
#include <linux/linkage.h>
-#include <asm/frame.h>
+#include <asm/dwarf2.h>
.section .rodata, "a"
.align 16
@@ -22,7 +22,7 @@ CONSTANTS: .octa 0x6b20657479622d323320646e61707865
* rcx: number of 64-byte blocks to write to output
*/
SYM_FUNC_START(__arch_chacha20_blocks_nostack)
-
+ CFI_STARTPROC
.set output, %rdi
.set key, %rsi
.set counter, %rdx
@@ -175,4 +175,5 @@ SYM_FUNC_START(__arch_chacha20_blocks_nostack)
pxor temp,temp
ret
+ CFI_ENDPROC
SYM_FUNC_END(__arch_chacha20_blocks_nostack)
--
2.51.0
^ permalink raw reply related
* [PATCH v7 4/6] x86/vdso: Use SYM_FUNC_{START,END} in __kernel_vsyscall()
From: Jens Remus @ 2026-02-03 17:19 UTC (permalink / raw)
To: linux-kernel, linux-trace-kernel, bpf, x86, linux-mm,
Steven Rostedt
Cc: Jens Remus, Josh Poimboeuf, Masami Hiramatsu, Mathieu Desnoyers,
Peter Zijlstra, Ingo Molnar, Jiri Olsa, Arnaldo Carvalho de Melo,
Namhyung Kim, Thomas Gleixner, Andrii Nakryiko, Indu Bhagat,
Jose E. Marchesi, Beau Belgrave, Linus Torvalds, Andrew Morton,
Florian Weimer, Kees Cook, Carlos O'Donell, Sam James,
Dylan Hatch, Borislav Petkov, Dave Hansen, David Hildenbrand,
H. Peter Anvin, Liam R. Howlett, Lorenzo Stoakes, Michal Hocko,
Mike Rapoport, Suren Baghdasaryan, Vlastimil Babka,
Heiko Carstens, Vasily Gorbik, Steven Rostedt (Google)
In-Reply-To: <20260203171958.1522030-1-jremus@linux.ibm.com>
From: Josh Poimboeuf <jpoimboe@kernel.org>
Use SYM_FUNC_{START,END} instead of all the boilerplate. No functional
change.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
---
Notes (jremus):
Changes in v7:
- Rebase on H. Peter Anvin's vDSO changes on tip:x86/entry.
arch/x86/entry/vdso/vdso32/system_call.S | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/x86/entry/vdso/vdso32/system_call.S b/arch/x86/entry/vdso/vdso32/system_call.S
index 9157cf9c5749..a90f4f7de396 100644
--- a/arch/x86/entry/vdso/vdso32/system_call.S
+++ b/arch/x86/entry/vdso/vdso32/system_call.S
@@ -9,11 +9,7 @@
#include <asm/alternative.h>
.text
- .globl __kernel_vsyscall
- .type __kernel_vsyscall,@function
- ALIGN
-__kernel_vsyscall:
- CFI_STARTPROC
+SYM_FUNC_START(__kernel_vsyscall)
/*
* If using int $0x80, there is no reason to muck about with the
@@ -85,7 +81,5 @@ SYM_INNER_LABEL(int80_landing_pad, SYM_L_GLOBAL)
CFI_RESTORE ecx
CFI_ADJUST_CFA_OFFSET -4
RET
- CFI_ENDPROC
-
- .size __kernel_vsyscall,.-__kernel_vsyscall
+SYM_FUNC_END(__kernel_vsyscall)
.previous
--
2.51.0
^ permalink raw reply related
* [PATCH v7 5/6] x86/vdso: Use CFI macros in __vdso_sgx_enter_enclave()
From: Jens Remus @ 2026-02-03 17:19 UTC (permalink / raw)
To: linux-kernel, linux-trace-kernel, bpf, x86, linux-mm,
Steven Rostedt
Cc: Jens Remus, Josh Poimboeuf, Masami Hiramatsu, Mathieu Desnoyers,
Peter Zijlstra, Ingo Molnar, Jiri Olsa, Arnaldo Carvalho de Melo,
Namhyung Kim, Thomas Gleixner, Andrii Nakryiko, Indu Bhagat,
Jose E. Marchesi, Beau Belgrave, Linus Torvalds, Andrew Morton,
Florian Weimer, Kees Cook, Carlos O'Donell, Sam James,
Dylan Hatch, Borislav Petkov, Dave Hansen, David Hildenbrand,
H. Peter Anvin, Liam R. Howlett, Lorenzo Stoakes, Michal Hocko,
Mike Rapoport, Suren Baghdasaryan, Vlastimil Babka,
Heiko Carstens, Vasily Gorbik, Steven Rostedt (Google)
In-Reply-To: <20260203171958.1522030-1-jremus@linux.ibm.com>
From: Josh Poimboeuf <jpoimboe@kernel.org>
Use the CFI macros instead of the raw .cfi_* directives to be consistent
with the rest of the VDSO asm. It's also easier on the eyes.
No functional changes.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
---
arch/x86/entry/vdso/vdso64/vsgx.S | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/x86/entry/vdso/vdso64/vsgx.S b/arch/x86/entry/vdso/vdso64/vsgx.S
index c0342238c976..8d7b8eb45c50 100644
--- a/arch/x86/entry/vdso/vdso64/vsgx.S
+++ b/arch/x86/entry/vdso/vdso64/vsgx.S
@@ -24,13 +24,14 @@
.section .text, "ax"
SYM_FUNC_START(__vdso_sgx_enter_enclave)
+ SYM_F_ALIGN
push %rbp
- .cfi_adjust_cfa_offset 8
- .cfi_rel_offset %rbp, 0
+ CFI_ADJUST_CFA_OFFSET 8
+ CFI_REL_OFFSET %rbp, 0
mov %rsp, %rbp
- .cfi_def_cfa_register %rbp
+ CFI_DEF_CFA_REGISTER %rbp
push %rbx
- .cfi_rel_offset %rbx, -8
+ CFI_REL_OFFSET %rbx, -8
mov %ecx, %eax
.Lenter_enclave:
@@ -77,13 +78,11 @@ SYM_FUNC_START(__vdso_sgx_enter_enclave)
.Lout:
pop %rbx
leave
- .cfi_def_cfa %rsp, 8
+ CFI_DEF_CFA %rsp, 8
RET
- /* The out-of-line code runs with the pre-leave stack frame. */
- .cfi_def_cfa %rbp, 16
-
.Linvalid_input:
+ CFI_DEF_CFA %rbp, 16
mov $(-EINVAL), %eax
jmp .Lout
--
2.51.0
^ permalink raw reply related
* [PATCH v7 2/6] x86/asm: Avoid emitting DWARF CFI for non-VDSO
From: Jens Remus @ 2026-02-03 17:19 UTC (permalink / raw)
To: linux-kernel, linux-trace-kernel, bpf, x86, linux-mm,
Steven Rostedt
Cc: Jens Remus, Josh Poimboeuf, Masami Hiramatsu, Mathieu Desnoyers,
Peter Zijlstra, Ingo Molnar, Jiri Olsa, Arnaldo Carvalho de Melo,
Namhyung Kim, Thomas Gleixner, Andrii Nakryiko, Indu Bhagat,
Jose E. Marchesi, Beau Belgrave, Linus Torvalds, Andrew Morton,
Florian Weimer, Kees Cook, Carlos O'Donell, Sam James,
Dylan Hatch, Borislav Petkov, Dave Hansen, David Hildenbrand,
H. Peter Anvin, Liam R. Howlett, Lorenzo Stoakes, Michal Hocko,
Mike Rapoport, Suren Baghdasaryan, Vlastimil Babka,
Heiko Carstens, Vasily Gorbik, Steven Rostedt (Google)
In-Reply-To: <20260203171958.1522030-1-jremus@linux.ibm.com>
From: Josh Poimboeuf <jpoimboe@kernel.org>
It was decided years ago that .cfi_* annotations aren't maintainable in
the kernel. They were replaced by objtool unwind hints. For the kernel
proper, ensure the CFI_* macros don't do anything.
On the other hand the VDSO library *does* use them, so user space can
unwind through it.
Make sure these macros only work for VDSO. They aren't actually being
used outside of VDSO anyway, so there's no functional change.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
---
arch/x86/include/asm/dwarf2.h | 51 ++++++++++++++++++++++++-----------
1 file changed, 35 insertions(+), 16 deletions(-)
diff --git a/arch/x86/include/asm/dwarf2.h b/arch/x86/include/asm/dwarf2.h
index 09c9684d3ad6..7cc30500c095 100644
--- a/arch/x86/include/asm/dwarf2.h
+++ b/arch/x86/include/asm/dwarf2.h
@@ -6,6 +6,15 @@
#warning "asm/dwarf2.h should be only included in pure assembly files"
#endif
+#ifdef BUILD_VDSO
+
+ /*
+ * For the vDSO, emit both runtime unwind information and debug
+ * symbols for the .dbg file.
+ */
+
+ .cfi_sections .eh_frame, .debug_frame
+
#define CFI_STARTPROC .cfi_startproc
#define CFI_ENDPROC .cfi_endproc
#define CFI_DEF_CFA .cfi_def_cfa
@@ -22,21 +31,31 @@
#define CFI_ESCAPE .cfi_escape
#define CFI_SIGNAL_FRAME .cfi_signal_frame
-#ifndef BUILD_VDSO
- /*
- * Emit CFI data in .debug_frame sections, not .eh_frame sections.
- * The latter we currently just discard since we don't do DWARF
- * unwinding at runtime. So only the offline DWARF information is
- * useful to anyone. Note we should not use this directive if we
- * ever decide to enable DWARF unwinding at runtime.
- */
- .cfi_sections .debug_frame
-#else
- /*
- * For the vDSO, emit both runtime unwind information and debug
- * symbols for the .dbg file.
- */
- .cfi_sections .eh_frame, .debug_frame
-#endif
+#else /* !BUILD_VDSO */
+
+/*
+ * On x86, these macros aren't used outside VDSO. As well they shouldn't be:
+ * they're fragile and very difficult to maintain.
+ */
+
+.macro nocfi args:vararg
+.endm
+
+#define CFI_STARTPROC nocfi
+#define CFI_ENDPROC nocfi
+#define CFI_DEF_CFA nocfi
+#define CFI_DEF_CFA_REGISTER nocfi
+#define CFI_DEF_CFA_OFFSET nocfi
+#define CFI_ADJUST_CFA_OFFSET nocfi
+#define CFI_OFFSET nocfi
+#define CFI_REL_OFFSET nocfi
+#define CFI_REGISTER nocfi
+#define CFI_RESTORE nocfi
+#define CFI_REMEMBER_STATE nocfi
+#define CFI_RESTORE_STATE nocfi
+#define CFI_UNDEFINED nocfi
+#define CFI_ESCAPE nocfi
+
+#endif /* !BUILD_VDSO */
#endif /* _ASM_X86_DWARF2_H */
--
2.51.0
^ permalink raw reply related
* [PATCH v7 6/6] x86/vdso: Enable sframe generation in VDSO
From: Jens Remus @ 2026-02-03 17:19 UTC (permalink / raw)
To: linux-kernel, linux-trace-kernel, bpf, x86, linux-mm,
Steven Rostedt
Cc: Jens Remus, Josh Poimboeuf, Masami Hiramatsu, Mathieu Desnoyers,
Peter Zijlstra, Ingo Molnar, Jiri Olsa, Arnaldo Carvalho de Melo,
Namhyung Kim, Thomas Gleixner, Andrii Nakryiko, Indu Bhagat,
Jose E. Marchesi, Beau Belgrave, Linus Torvalds, Andrew Morton,
Florian Weimer, Kees Cook, Carlos O'Donell, Sam James,
Dylan Hatch, Borislav Petkov, Dave Hansen, David Hildenbrand,
H. Peter Anvin, Liam R. Howlett, Lorenzo Stoakes, Michal Hocko,
Mike Rapoport, Suren Baghdasaryan, Vlastimil Babka,
Heiko Carstens, Vasily Gorbik, Steven Rostedt (Google)
In-Reply-To: <20260203171958.1522030-1-jremus@linux.ibm.com>
From: Josh Poimboeuf <jpoimboe@kernel.org>
Enable sframe generation in the VDSO library so kernel and user space
can unwind through it.
[ Jens Remus: Add support for SFrame V3. Prevent GNU_SFRAME program
table entry to empty .sframe section. ]
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
---
Notes (jremus):
Changes in v7:
- Rebase on H. Peter Anvin's vDSO changes on tip:x86/entry.
- Simplify adding assembler option -Wa,--gsframe-3. Add for
vdso64 only.
- Align to .eh_frame and mark .sframe as KEEP in vDSO linker script.
Note that GNU linker 2.46 will mark .sframe as KEEP in its default
linker script as well.
arch/Kconfig | 7 +++++++
arch/x86/entry/vdso/common/vdso-layout.lds.S | 11 +++++++++++
arch/x86/entry/vdso/vdso64/Makefile | 1 +
arch/x86/include/asm/dwarf2.h | 5 ++++-
4 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 31220f512b16..8170e492a44c 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -479,6 +479,13 @@ config HAVE_HARDLOCKUP_DETECTOR_ARCH
It uses the same command line parameters, and sysctl interface,
as the generic hardlockup detectors.
+config AS_SFRAME
+ bool
+
+config AS_SFRAME3
+ def_bool $(as-instr,.cfi_startproc\n.cfi_endproc,-Wa$(comma)--gsframe-3)
+ select AS_SFRAME
+
config UNWIND_USER
bool
diff --git a/arch/x86/entry/vdso/common/vdso-layout.lds.S b/arch/x86/entry/vdso/common/vdso-layout.lds.S
index 856b8b9d278c..421eb4ca9131 100644
--- a/arch/x86/entry/vdso/common/vdso-layout.lds.S
+++ b/arch/x86/entry/vdso/common/vdso-layout.lds.S
@@ -60,6 +60,13 @@ SECTIONS
*(.eh_frame.*)
} :text
+#ifdef CONFIG_AS_SFRAME
+ .sframe : {
+ KEEP (*(.sframe))
+ *(.sframe.*)
+ } :text :sframe
+#endif
+
/*
* Text is well-separated from actual data: there's plenty of
* stuff that isn't used at runtime in between.
@@ -89,6 +96,7 @@ SECTIONS
#define PT_GNU_EH_FRAME 0x6474e550
#define PT_GNU_STACK 0x6474e551
#define PT_GNU_PROPERTY 0x6474e553
+#define PT_GNU_SFRAME 0x6474e554
/*
* We must supply the ELF program headers explicitly to get just one
@@ -104,6 +112,9 @@ PHDRS
dynamic PT_DYNAMIC PF_R;
note PT_NOTE PF_R;
eh_frame_hdr PT_GNU_EH_FRAME PF_R;
+#ifdef CONFIG_AS_SFRAME
+ sframe PT_GNU_SFRAME PF_R;
+#endif
gnu_stack PT_GNU_STACK PF_RW;
gnu_property PT_GNU_PROPERTY PF_R;
}
diff --git a/arch/x86/entry/vdso/vdso64/Makefile b/arch/x86/entry/vdso/vdso64/Makefile
index bfffaf1aeecc..459f8026531e 100644
--- a/arch/x86/entry/vdso/vdso64/Makefile
+++ b/arch/x86/entry/vdso/vdso64/Makefile
@@ -14,6 +14,7 @@ vobjs-$(CONFIG_X86_SGX) += vsgx.o
# Compilation flags
flags-y := -DBUILD_VDSO64 -m64 -mcmodel=small
+flags-$(CONFIG_AS_SFRAME3) += -Wa,--gsframe-3
# The location of this include matters!
include $(src)/../common/Makefile.include
diff --git a/arch/x86/include/asm/dwarf2.h b/arch/x86/include/asm/dwarf2.h
index 7cc30500c095..90b42367815e 100644
--- a/arch/x86/include/asm/dwarf2.h
+++ b/arch/x86/include/asm/dwarf2.h
@@ -12,8 +12,11 @@
* For the vDSO, emit both runtime unwind information and debug
* symbols for the .dbg file.
*/
-
+#if defined(__x86_64__) && defined(CONFIG_AS_SFRAME)
+ .cfi_sections .eh_frame, .debug_frame, .sframe
+#else
.cfi_sections .eh_frame, .debug_frame
+#endif
#define CFI_STARTPROC .cfi_startproc
#define CFI_ENDPROC .cfi_endproc
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] tracing: remove __printf() attribute on __ftrace_vbprintk()
From: Andy Shevchenko @ 2026-02-03 17:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: kernel test robot, Arnd Bergmann, Steven Rostedt,
Masami Hiramatsu, Simon Horman, Jeff Layton, Anna Schumaker,
Chuck Lever, llvm, oe-kbuild-all, Mathieu Desnoyers,
Andrew Morton, Linux Memory Management List, Randy Dunlap,
Yury Norov, Joel Fernandes, linux-kernel, linux-trace-kernel
In-Reply-To: <d777a8f0-41ab-48f8-93db-268f493ac656@app.fastmail.com>
On Tue, Feb 03, 2026 at 04:56:03PM +0100, Arnd Bergmann wrote:
> On Tue, Feb 3, 2026, at 15:58, Andy Shevchenko wrote:
> > On Tue, Feb 03, 2026 at 08:12:57PM +0800, kernel test robot wrote:
> >
> >> kernel test robot noticed the following build warnings:
> >
> > Yeah, you need to go for the full stack of these calls and mark the
> > bottom one with __diag() to avoid these warnings. That's my understanding
> > and what BPF people required. Chasing this one-by-one would produce
> > unneeded churn.
>
> From what I can tell, I can just move the printf attribute
> to the __ftrace_vbprintk() definition to make this bit work.
Ah, that's cool!
...
> There are unrelated warnings for BPF that I managed to
> shut up the same way, doing
BPF rejected such an approach, see lore discussions in the past
(patches from me). Here some pointers (but not all of them):
20251208141618.2805983-1-andriy.shevchenko@linux.intel.com
202512090407.VxRO6xAS-lkp@intel.com
20251210131234.3185985-1-andriy.shevchenko@linux.intel.com
20251216122514.7ee70d5f@canb.auug.org.au
20251215202430.c35c2d29c4f9ff614d2ab534@linux-foundation.org
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] bpf: add missing __printf attributes
From: Arnd Bergmann @ 2026-02-03 16:57 UTC (permalink / raw)
To: Alexei Starovoitov, Arnd Bergmann
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Song Liu,
KP Singh, Matt Bobrowski, Steven Rostedt, Masami Hiramatsu,
Martin KaFai Lau, Eduard Zingerman, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Jiri Olsa, Mathieu Desnoyers,
Mykyta Yatsenko, Kumar Kartikeya Dwivedi, bpf, LKML,
linux-trace-kernel
In-Reply-To: <CAADnVQ+14yum8okMmjuqF5m5DafWo1fY1EuPj-QU_ykYbQ01uw@mail.gmail.com>
On Tue, Feb 3, 2026, at 17:34, Alexei Starovoitov wrote:
> On Tue, Feb 3, 2026 at 8:27 AM Arnd Bergmann <arnd@kernel.org> wrote:
>>
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> Some internal functions in bpf produce a warning when -Wsuggest-attribute=format
>> is passed to the compiler, e.g. in 'make W=1':
>>
>> kernel/trace/bpf_trace.c: In function '____bpf_trace_printk':
>> kernel/trace/bpf_trace.c:377:9: error: function '____bpf_trace_printk' might be a candidate for 'gnu_printf' format attribute [-Werror=suggest-attribute=format]
>> 377 | ret = bstr_printf(data.buf, MAX_BPRINTF_BUF, fmt, data.bin_args);
>> | ^~~
>>
>> The attribute here is useless since there are no callers from C code,
>> but it helps to shut up the output anyway so we can eventually turn
>> the warning option on by default.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> This was discussed and it's incorrect.
Do you have a reference to why it's incorrect? It seems harmless
and gives me a clean kernel build in combination with a handful
of other fixes after enabling the option by default, but I assume
I'm missing something,
> Commit 7bf819aa992f ("vsnprintf: Mark binary printing functions with
> __printf() attribute") should be reverted instead.
Reverting that one would appear to introduce warnings elsewhere,
so that would not be a complete fix either.
Arnd
^ permalink raw reply
* [PATCH] [v2] tracing: move __printf() attribute on __ftrace_vbprintk()
From: Arnd Bergmann @ 2026-02-03 16:45 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu, Anna Schumaker, Jeff Layton,
Chuck Lever, Simon Horman
Cc: Arnd Bergmann, Mathieu Desnoyers, Andrew Morton, Andy Shevchenko,
Yury Norov, Randy Dunlap, linux-kernel, linux-trace-kernel
From: Arnd Bergmann <arnd@arndb.de>
The sunrpc change to use trace_printk() for debugging caused
a new warning for every instance of dprintk() in some configurations,
when -Wformat-security is enabled:
fs/nfs/getroot.c: In function 'nfs_get_root':
fs/nfs/getroot.c:90:17: error: format not a string literal and no format arguments [-Werror=format-security]
90 | nfs_errorf(fc, "NFS: Couldn't getattr on root");
I've been slowly chipping away at those warnings over time with the
intention of enabling them by default in the future. While I could not
figure out why this only happens for this one instance, I see that the
__trace_bprintk() function is always called with a local variable as
the format string, rather than a literal.
Move the __printf(2,3) annotation on this function from the declaration
to the caller. As this is can only be validated for literals, the
attribute on the declaration causes the warnings every time, but
removing it entirely introduces a new warning on the __ftrace_vbprintk()
definition.
The format strings still get checked because the underlying literal keeps
getting passed into __trace_printk() in the "else" branch, which is not
taken but still evaluated for compile-time warnings.
Fixes: ec7d8e68ef0e ("sunrpc: add a Kconfig option to redirect dfprintk() output to trace buffer")
Acked-by: Jeff Layton <jlayton@kernel.org>
Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
v2: included fix for regression reported by kernel test robot <lkp@intel.com>
---
include/linux/trace_printk.h | 1 -
kernel/trace/trace_printk.c | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/trace_printk.h b/include/linux/trace_printk.h
index bb5874097f24..2670ec7f4262 100644
--- a/include/linux/trace_printk.h
+++ b/include/linux/trace_printk.h
@@ -107,7 +107,6 @@ do { \
__trace_printk(_THIS_IP_, fmt, ##args); \
} while (0)
-extern __printf(2, 3)
int __trace_bprintk(unsigned long ip, const char *fmt, ...);
extern __printf(2, 3)
diff --git a/kernel/trace/trace_printk.c b/kernel/trace/trace_printk.c
index 29f6e95439b6..48c085fcae7a 100644
--- a/kernel/trace/trace_printk.c
+++ b/kernel/trace/trace_printk.c
@@ -197,6 +197,7 @@ struct notifier_block module_trace_bprintk_format_nb = {
.notifier_call = module_trace_bprintk_format_notify,
};
+__printf(2, 3)
int __trace_bprintk(unsigned long ip, const char *fmt, ...)
{
int ret;
--
2.39.5
^ permalink raw reply related
* Re: [PATCH] bpf: add missing __printf attributes
From: Alexei Starovoitov @ 2026-02-03 16:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Song Liu,
KP Singh, Matt Bobrowski, Steven Rostedt, Masami Hiramatsu,
Arnd Bergmann, Martin KaFai Lau, Eduard Zingerman, Yonghong Song,
John Fastabend, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mathieu Desnoyers, Mykyta Yatsenko, Kumar Kartikeya Dwivedi, bpf,
LKML, linux-trace-kernel
In-Reply-To: <20260203162746.2337002-1-arnd@kernel.org>
On Tue, Feb 3, 2026 at 8:27 AM Arnd Bergmann <arnd@kernel.org> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
>
> Some internal functions in bpf produce a warning when -Wsuggest-attribute=format
> is passed to the compiler, e.g. in 'make W=1':
>
> kernel/trace/bpf_trace.c: In function '____bpf_trace_printk':
> kernel/trace/bpf_trace.c:377:9: error: function '____bpf_trace_printk' might be a candidate for 'gnu_printf' format attribute [-Werror=suggest-attribute=format]
> 377 | ret = bstr_printf(data.buf, MAX_BPRINTF_BUF, fmt, data.bin_args);
> | ^~~
>
> The attribute here is useless since there are no callers from C code,
> but it helps to shut up the output anyway so we can eventually turn
> the warning option on by default.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This was discussed and it's incorrect.
Commit 7bf819aa992f ("vsnprintf: Mark binary printing functions with
__printf() attribute")
should be reverted instead.
pw-bot: cr
^ permalink raw reply
* [PATCH] bpf: add missing __printf attributes
From: Arnd Bergmann @ 2026-02-03 16:27 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, Song Liu,
KP Singh, Matt Bobrowski, Steven Rostedt, Masami Hiramatsu
Cc: Arnd Bergmann, Martin KaFai Lau, Eduard Zingerman, Yonghong Song,
John Fastabend, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mathieu Desnoyers, Mykyta Yatsenko, Kumar Kartikeya Dwivedi, bpf,
linux-kernel, linux-trace-kernel
From: Arnd Bergmann <arnd@arndb.de>
Some internal functions in bpf produce a warning when -Wsuggest-attribute=format
is passed to the compiler, e.g. in 'make W=1':
kernel/trace/bpf_trace.c: In function '____bpf_trace_printk':
kernel/trace/bpf_trace.c:377:9: error: function '____bpf_trace_printk' might be a candidate for 'gnu_printf' format attribute [-Werror=suggest-attribute=format]
377 | ret = bstr_printf(data.buf, MAX_BPRINTF_BUF, fmt, data.bin_args);
| ^~~
The attribute here is useless since there are no callers from C code,
but it helps to shut up the output anyway so we can eventually turn
the warning option on by default.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
kernel/bpf/helpers.c | 1 +
kernel/bpf/stream.c | 1 +
kernel/trace/bpf_trace.c | 3 +++
3 files changed, 5 insertions(+)
diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index b54ec0e945aa..45d026fc4e8a 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -1046,6 +1046,7 @@ int bpf_bprintf_prepare(const char *fmt, u32 fmt_size, const u64 *raw_args,
return err;
}
+__printf(3, 0)
BPF_CALL_5(bpf_snprintf, char *, str, u32, str_size, char *, fmt,
const void *, args, u32, data_len)
{
diff --git a/kernel/bpf/stream.c b/kernel/bpf/stream.c
index 24730df55e69..816fd7fba3d2 100644
--- a/kernel/bpf/stream.c
+++ b/kernel/bpf/stream.c
@@ -212,6 +212,7 @@ __bpf_kfunc_start_defs();
* Avoid using enum bpf_stream_id so that kfunc users don't have to pull in the
* enum in headers.
*/
+__printf(2, 0)
__bpf_kfunc int bpf_stream_vprintk(int stream_id, const char *fmt__str, const void *args,
u32 len__sz, struct bpf_prog_aux *aux)
{
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index eadaef8592a3..2d3de71ab86a 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -359,6 +359,7 @@ static const struct bpf_func_proto bpf_probe_write_user_proto = {
#define MAX_TRACE_PRINTK_VARARGS 3
#define BPF_TRACE_PRINTK_SIZE 1024
+__printf(1, 0)
BPF_CALL_5(bpf_trace_printk, char *, fmt, u32, fmt_size, u64, arg1,
u64, arg2, u64, arg3)
{
@@ -412,6 +413,7 @@ const struct bpf_func_proto *bpf_get_trace_printk_proto(void)
return &bpf_trace_printk_proto;
}
+__printf(1, 0)
BPF_CALL_4(bpf_trace_vprintk, char *, fmt, u32, fmt_size, const void *, args,
u32, data_len)
{
@@ -455,6 +457,7 @@ const struct bpf_func_proto *bpf_get_trace_vprintk_proto(void)
return &bpf_trace_vprintk_proto;
}
+__printf(2, 0)
BPF_CALL_5(bpf_seq_printf, struct seq_file *, m, char *, fmt, u32, fmt_size,
const void *, args, u32, data_len)
{
--
2.39.5
^ permalink raw reply related
* Re: [PATCH v2] tracing: Fix funcgraph_exit calltime/rettime offset for 32-bit ARM
From: Steven Rostedt @ 2026-02-03 16:20 UTC (permalink / raw)
To: jempty.liang
Cc: mhiramat, mark.rutland, mathieu.desnoyers, linux-kernel,
linux-trace-kernel
In-Reply-To: <20260203093018.66c3b3b2@gandalf.local.home>
On Tue, 3 Feb 2026 09:30:18 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> > On the 32-bit ARM platform, when _type is unsigned long long, the resulting align value is 8 instead of the expected 4.
> > >
>
> Are you saying this still doesn't work?
>
> That would be an issue because then it would have the same bugs with
> generic trace events which uses the same solution.
OK, so talking with others that know more about arm32 than I do, it can
indeed still produce an 8 byte alignment.
Anyway, I still want to fix it properly. Does this patch work for you?
-- Steve
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index b6d42fe06115..c11edec5d8f5 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -68,14 +68,17 @@ enum trace_type {
#undef __field_fn
#define __field_fn(type, item) type item;
+#undef __field_packed
+#define __field_packed(type, item) type item;
+
#undef __field_struct
#define __field_struct(type, item) __field(type, item)
#undef __field_desc
#define __field_desc(type, container, item)
-#undef __field_packed
-#define __field_packed(type, container, item)
+#undef __field_desc_packed
+#define __field_desc_packed(type, container, item)
#undef __array
#define __array(type, item, size) type item[size];
diff --git a/kernel/trace/trace_entries.h b/kernel/trace/trace_entries.h
index f6a8d29c0d76..54417468fdeb 100644
--- a/kernel/trace/trace_entries.h
+++ b/kernel/trace/trace_entries.h
@@ -79,8 +79,8 @@ FTRACE_ENTRY(funcgraph_entry, ftrace_graph_ent_entry,
F_STRUCT(
__field_struct( struct ftrace_graph_ent, graph_ent )
- __field_packed( unsigned long, graph_ent, func )
- __field_packed( unsigned long, graph_ent, depth )
+ __field_desc_packed(unsigned long, graph_ent, func )
+ __field_desc_packed(unsigned long, graph_ent, depth )
__dynamic_array(unsigned long, args )
),
@@ -96,9 +96,9 @@ FTRACE_ENTRY_PACKED(fgraph_retaddr_entry, fgraph_retaddr_ent_entry,
F_STRUCT(
__field_struct( struct fgraph_retaddr_ent, graph_rent )
- __field_packed( unsigned long, graph_rent.ent, func )
- __field_packed( unsigned long, graph_rent.ent, depth )
- __field_packed( unsigned long, graph_rent, retaddr )
+ __field_desc_packed( unsigned long, graph_rent.ent, func )
+ __field_desc_packed( unsigned long, graph_rent.ent, depth )
+ __field_desc_packed( unsigned long, graph_rent, retaddr )
__dynamic_array(unsigned long, args )
),
@@ -123,12 +123,12 @@ FTRACE_ENTRY_PACKED(funcgraph_exit, ftrace_graph_ret_entry,
F_STRUCT(
__field_struct( struct ftrace_graph_ret, ret )
- __field_packed( unsigned long, ret, func )
- __field_packed( unsigned long, ret, retval )
- __field_packed( unsigned int, ret, depth )
- __field_packed( unsigned int, ret, overrun )
- __field(unsigned long long, calltime )
- __field(unsigned long long, rettime )
+ __field_desc_packed( unsigned long, ret, func )
+ __field_desc_packed( unsigned long, ret, retval )
+ __field_desc_packed( unsigned int, ret, depth )
+ __field_desc_packed( unsigned int, ret, overrun )
+ __field_packed(unsigned long long, calltime)
+ __field_packed(unsigned long long, rettime )
),
F_printk("<-- %ps (%u) (start: %llx end: %llx) over: %u retval: %lx",
@@ -146,11 +146,11 @@ FTRACE_ENTRY_PACKED(funcgraph_exit, ftrace_graph_ret_entry,
F_STRUCT(
__field_struct( struct ftrace_graph_ret, ret )
- __field_packed( unsigned long, ret, func )
- __field_packed( unsigned int, ret, depth )
- __field_packed( unsigned int, ret, overrun )
- __field(unsigned long long, calltime )
- __field(unsigned long long, rettime )
+ __field_desc_packed( unsigned long, ret, func )
+ __field_desc_packed( unsigned int, ret, depth )
+ __field_desc_packed( unsigned int, ret, overrun )
+ __field_packed(unsigned long long, calltime )
+ __field_packed(unsigned long long, rettime )
),
F_printk("<-- %ps (%u) (start: %llx end: %llx) over: %u",
diff --git a/kernel/trace/trace_export.c b/kernel/trace/trace_export.c
index 1698fc22afa0..32a42ef31855 100644
--- a/kernel/trace/trace_export.c
+++ b/kernel/trace/trace_export.c
@@ -42,11 +42,14 @@ static int ftrace_event_register(struct trace_event_call *call,
#undef __field_fn
#define __field_fn(type, item) type item;
+#undef __field_packed
+#define __field_packed(type, item) type item;
+
#undef __field_desc
#define __field_desc(type, container, item) type item;
-#undef __field_packed
-#define __field_packed(type, container, item) type item;
+#undef __field_desc_packed
+#define __field_desc_packed(type, container, item) type item;
#undef __array
#define __array(type, item, size) type item[size];
@@ -104,11 +107,14 @@ static void __always_unused ____ftrace_check_##name(void) \
#undef __field_fn
#define __field_fn(_type, _item) __field_ext(_type, _item, FILTER_TRACE_FN)
+#undef __field_packed
+#define __field_packed(_type, _item) __field_ext_packed(_type, _item, FILTER_OTHER)
+
#undef __field_desc
#define __field_desc(_type, _container, _item) __field_ext(_type, _item, FILTER_OTHER)
-#undef __field_packed
-#define __field_packed(_type, _container, _item) __field_ext_packed(_type, _item, FILTER_OTHER)
+#undef __field_desc_packed
+#define __field_desc_packed(_type, _container, _item) __field_ext_packed(_type, _item, FILTER_OTHER)
#undef __array
#define __array(_type, _item, _len) { \
@@ -146,11 +152,14 @@ static struct trace_event_fields ftrace_event_fields_##name[] = { \
#undef __field_fn
#define __field_fn(type, item)
+#undef __field_packed
+#define __field_packed(type, item)
+
#undef __field_desc
#define __field_desc(type, container, item)
-#undef __field_packed
-#define __field_packed(type, container, item)
+#undef __field_desc_packed
+#define __field_desc_packed(type, container, item)
#undef __array
#define __array(type, item, len)
^ permalink raw reply related
* Re: [PATCH 2/2] tracing: resolve enum names for function arguments via BTF
From: Alexei Starovoitov @ 2026-02-03 16:00 UTC (permalink / raw)
To: Steven Rostedt
Cc: Donglin Peng, Andrii Nakryiko, Alexei Starovoitov,
Masami Hiramatsu, LKML, Donglin Peng, linux-trace-kernel, bpf,
Eduard Zingerman
In-Reply-To: <20260203101707.52965eb0@gandalf.local.home>
On Tue, Feb 3, 2026 at 7:16 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Tue, 3 Feb 2026 21:50:47 +0800
> Donglin Peng <dolinux.peng@gmail.com> wrote:
>
> > Testing revealed that sorting within resolve_btfids introduces issues with
> > btf__dedup. Therefore, I plan to move the sorting logic directly into
> > btf__add_enum_value and btf__add_enum64_value in libbpf, which are
> > invoked by pahole. However, it means that we need a newer pahole
> > version.
>
> Sorting isn't a requirement just something I wanted to bring up. If it's
> too complex and doesn't achieve much benefit then let's not do it.
>
> My worry is because "cat trace" takes quite a long time just reading the
> BTF arguments. I'm worried it will just get worse with enums as well.
>
> I have trace-cmd reading BTF now (just haven't officially released it) and
> doing an extract and reading the trace.dat file is much faster than reading
> the trace file with arguments. I'll need to implement the enum logic too in
> libtraceevent.
If you mean to do pretty printing of the trace in user space then +1 from me.
I don't like sorting enums either in resolve_btfid, pahole or kernel.
Sorted BTF by name was ok, since it doesn't change original semantics.
While sorting enums by value gets us to the grey zone where
the sequence of enum names in vmlinux.h becomes different than in dwarf.
Also id->name mapping in general is not precise.
There is no requirement for enums to be unique.
Just grabbing the first one:
ATA_PIO0 = 1,
ATA_PIO1 = 3,
ATA_PIO2 = 7,
ATA_UDMA0 = 1,
ATA_UDMA1 = 3,
ATA_UDMA2 = 7,
ATA_ID_CYLS = 1,
ATA_ID_HEADS = 3,
SCR_ERROR = 1,
SCR_CONTROL = 2,
SCR_ACTIVE = 3,
All these names are part of the same enum type.
Which one to print? First one?
another example:
enum {
BPF_LOCAL_STORAGE_GET_F_CREATE = 1,
BPF_SK_STORAGE_GET_F_CREATE = 1,
};
and another:
enum {
BPF_SKB_TSTAMP_UNSPEC = 0,
BPF_SKB_TSTAMP_DELIVERY_MONO = 1,
BPF_SKB_CLOCK_REALTIME = 0,
BPF_SKB_CLOCK_MONOTONIC = 1,
BPF_SKB_CLOCK_TAI = 2,
};
I'd rather not print any and keep it integer only.
pw-bot: cr
^ permalink raw reply
* Re: [PATCH] tracing: remove __printf() attribute on __ftrace_vbprintk()
From: Arnd Bergmann @ 2026-02-03 15:56 UTC (permalink / raw)
To: Andy Shevchenko, kernel test robot
Cc: Arnd Bergmann, Steven Rostedt, Masami Hiramatsu, Simon Horman,
Jeff Layton, Anna Schumaker, Chuck Lever, llvm, oe-kbuild-all,
Mathieu Desnoyers, Andrew Morton, Linux Memory Management List,
Randy Dunlap, Yury Norov, Joel Fernandes, linux-kernel,
linux-trace-kernel
In-Reply-To: <aYINAPJS9zXlUGCw@smile.fi.intel.com>
On Tue, Feb 3, 2026, at 15:58, Andy Shevchenko wrote:
> On Tue, Feb 03, 2026 at 08:12:57PM +0800, kernel test robot wrote:
>
>> kernel test robot noticed the following build warnings:
>
> Yeah, you need to go for the full stack of these calls and mark the
> bottom one with __diag() to avoid these warnings. That's my understanding
> and what BPF people required. Chasing this one-by-one would produce
> unneeded churn.
From what I can tell, I can just move the printf attribute
to the __ftrace_vbprintk() definition to make this bit work.
I'll send an updated patch:
--- a/kernel/trace/trace_printk.c
+++ b/kernel/trace/trace_printk.c
@@ -197,6 +197,7 @@ struct notifier_block module_trace_bprintk_format_nb = {
.notifier_call = module_trace_bprintk_format_notify,
};
+__printf(2, 3)
int __trace_bprintk(unsigned long ip, const char *fmt, ...)
{
int ret;
There are unrelated warnings for BPF that I managed to
shut up the same way, doing
diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index b54ec0e945aa..45d026fc4e8a 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -1046,6 +1046,7 @@ int bpf_bprintf_prepare(const char *fmt, u32 fmt_size, const u64 *raw_args,
return err;
}
+__printf(3, 0)
BPF_CALL_5(bpf_snprintf, char *, str, u32, str_size, char *, fmt,
const void *, args, u32, data_len)
{
diff --git a/kernel/bpf/stream.c b/kernel/bpf/stream.c
index 24730df55e69..816fd7fba3d2 100644
--- a/kernel/bpf/stream.c
+++ b/kernel/bpf/stream.c
@@ -212,6 +212,7 @@ __bpf_kfunc_start_defs();
* Avoid using enum bpf_stream_id so that kfunc users don't have to pull in the
* enum in headers.
*/
+__printf(2, 0)
__bpf_kfunc int bpf_stream_vprintk(int stream_id, const char *fmt__str, const void *args,
u32 len__sz, struct bpf_prog_aux *aux)
{
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index eadaef8592a3..2d3de71ab86a 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -359,6 +359,7 @@ static const struct bpf_func_proto bpf_probe_write_user_proto = {
#define MAX_TRACE_PRINTK_VARARGS 3
#define BPF_TRACE_PRINTK_SIZE 1024
+__printf(1, 0)
BPF_CALL_5(bpf_trace_printk, char *, fmt, u32, fmt_size, u64, arg1,
u64, arg2, u64, arg3)
{
@@ -412,6 +413,7 @@ const struct bpf_func_proto *bpf_get_trace_printk_proto(void)
return &bpf_trace_printk_proto;
}
+__printf(1, 0)
BPF_CALL_4(bpf_trace_vprintk, char *, fmt, u32, fmt_size, const void *, args,
u32, data_len)
{
@@ -455,6 +457,7 @@ const struct bpf_func_proto *bpf_get_trace_vprintk_proto(void)
return &bpf_trace_vprintk_proto;
}
+__printf(2, 0)
BPF_CALL_5(bpf_seq_printf, struct seq_file *, m, char *, fmt, u32, fmt_size,
const void *, args, u32, data_len)
{
Since those functions have no callers, the annotation on the
print functions does nothing.
With those added, and a couple of drivers fixed to use the
correct printf attributes, the only remaining one I see is
in samples/trace_events/trace-events-sample.h:
In file included from /home/arnd/arm-soc/include/trace/define_trace.h:132,
from /home/arnd/arm-soc/samples/trace_events/trace-events-sample.h:640,
from /home/arnd/arm-soc/samples/trace_events/trace-events-sample.c:12:
/home/arnd/arm-soc/samples/trace_events/./trace-events-sample.h: In function 'trace_event_get_offsets_foo_bar':
/home/arnd/arm-soc/include/trace/stages/stage5_get_offsets.h:33:31: error: function 'trace_event_get_offsets_foo_bar' might be a candidate for 'gnu_printf' format attribute [-Werror=suggest-attribute=format]
33 | { (void)sizeof(struct _test_no_array_##item *); }
| ^~~~~~~~~~~~~~~
/home/arnd/arm-soc/include/trace/trace_events.h:285:9: note: in definition of macro 'DECLARE_EVENT_CLASS'
285 | tstruct; \
| ^~~~~~~
/home/arnd/arm-soc/include/trace/trace_events.h:43:30: note: in expansion of macro 'PARAMS'
43 | PARAMS(tstruct), \
| ^~~~~~
/home/arnd/arm-soc/samples/trace_events/./trace-events-sample.h:291:1: note: in expansion of macro 'TRACE_EVENT'
291 | TRACE_EVENT(foo_bar,
| ^~~~~~~~~~~
/home/arnd/arm-soc/samples/trace_events/./trace-events-sample.h:299:9: note: in expansion of macro 'TP_STRUCT__entry'
299 | TP_STRUCT__entry(
| ^~~~~~~~~~~~~~~~
/home/arnd/arm-soc/samples/trace_events/./trace-events-sample.h:301:17: note: in expansion of macro '__field'
301 | __field( int, bar )
| ^~~~~~~
/home/arnd/arm-soc/samples/trace_events/./trace-events-sample.h: In function 'do_trace_event_raw_event_foo_bar':
I don't think this is related, but I also don't see an obvious
workaround other than forcing the warning off around that
definition.
Arnd
^ 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