[GIT PULL] perf tools fixes for v7.0: 2nd batch

[GIT PULL] perf tools fixes for v7.0: 2nd batch

[Arnaldo Carvalho de Melo]

Hi Linus,

	Please consider pulling,

Best regards,

- Arnaldo

The following changes since commit 04a9f1766954687f0a1b7a0f7184dc4f86edcb30:

  Merge tag 'soc-fixes-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc (2026-03-18 08:28:54 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools.git tags/perf-tools-fixes-for-v7.0-2-2026-03-23

for you to fetch changes up to 493ad070cbcb0d62deed877d90e80e554cac7f01:

  tools headers: Synchronize linux/build_bug.h with the kernel sources (2026-03-22 18:34:39 -0300)

----------------------------------------------------------------
perf tools fixes for v7.0: 2nd batch

o Fix parsing 'overwrite' in command line event definitions in
  big-endian machines by writing correct union member.

o Fix finding default metric in 'perf stat'.

o Fix relative paths for including headers in 'perf kvm stat'.

o Sync header copies with the kernel sources: msr-index.h, kvm,
  build_bug.h.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
--
2.53.0

----------------------------------------------------------------
Arnaldo Carvalho de Melo (5):
      Merge remote-tracking branch 'torvalds/master' into perf-tools
      tools arch x86: Sync the msr-index.h copy with the kernel sources
      tools headers UAPI: Sync linux/kvm.h with the kernel sources
      tools headers UAPI: Sync x86's asm/kvm.h with the kernel sources
      tools headers: Synchronize linux/build_bug.h with the kernel sources

Ian Rogers (1):
      perf metricgroup: Fix metricgroup__has_metric_or_groups()

Leo Yan (2):
      tools headers: Skip arm64 cputype.h check
      perf kvm stat: Fix relative paths for including headers

Thomas Richter (1):
      perf parse-events: Fix big-endian 'overwrite' by writing correct union member

 tools/arch/x86/include/asm/msr-index.h       |  5 +-
 tools/arch/x86/include/uapi/asm/kvm.h        |  1 +
 tools/include/linux/build_bug.h              |  4 +-
 tools/include/uapi/linux/kvm.h               |  8 +++
 tools/perf/check-headers.sh                  |  1 -
 tools/perf/util/kvm-stat-arch/kvm-stat-x86.c |  6 +-
 tools/perf/util/metricgroup.c                |  6 +-
 tools/perf/util/parse-events.c               | 82 ++++++++++++++++++++++------
 8 files changed, 87 insertions(+), 26 deletions(-)

Re: [GIT PULL] perf tools fixes for v7.0: 2nd batch

[Linus Torvalds]

On Mon, 23 Mar 2026 at 03:57, Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
>       tools arch x86: Sync the msr-index.h copy with the kernel sources
>       tools headers UAPI: Sync linux/kvm.h with the kernel sources
>       tools headers UAPI: Sync x86's asm/kvm.h with the kernel sources
>       tools headers: Synchronize linux/build_bug.h with the kernel sources

So I think we need to come up with some solution to *not* do this all,
because honestly, it's getting hugely annoying.

And it's not annoying due to the unnecessary diffs per se, but because
this tool header sync then causes 'objtool' - which also uses some of
those headers - to be rebuilt, and then that causes *everything* to be
rebuilt.

Just because the perf tree decided it needed to sync headers for
unexplained reasons.

The docs say "this works surprisingly well". That *used* to be the
case. But with objtool also being affected, it really does *not* work
well at all.

And no, the tools cannot use the kernel headers directly. That
*really* didn't work well, and required synchronizing kernel changes
with tooling changes, and was just a pain.

So the "header copies" solved a real problem, but we need to figure
out something better.

And honestly, the "something better" may be to just remove the
mindless check for "headers aren't 100% sync".

Because 99% of the time nobody cares. This time, for example, the
header changes in question were comments and stuff that was inside a
__KERNEL__ guard.

So how about just at least as a first step trying to remove the
warning that is actively detrimental, and only do header syncs when
there is a *real* reason for them?

                 Linus

Re: [GIT PULL] perf tools fixes for v7.0: 2nd batch

[pr-tracker-bot]

The pull request you sent on Mon, 23 Mar 2026 07:57:25 -0300:

> git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools.git tags/perf-tools-fixes-for-v7.0-2-2026-03-23

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/26a01984ddc1e67025fd150e845ab61d5271d6b7

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] perf tools fixes for v7.0: 2nd batch

[Arnaldo Melo]

On March 24, 2026 1:17:18 PM GMT-03:00, Arnaldo Melo <arnaldo.melo@gmail.com> wrote:
>
>
>On March 24, 2026 1:12:08 PM GMT-03:00, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>On Mon, 23 Mar 2026 at 03:57, Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>>>
>>>       tools arch x86: Sync the msr-index.h copy with the kernel sources
>>>       tools headers UAPI: Sync linux/kvm.h with the kernel sources
>>>       tools headers UAPI: Sync x86's asm/kvm.h with the kernel sources
>>>       tools headers: Synchronize linux/build_bug.h with the kernel sources
>>
>>So I think we need to come up with some solution to *not* do this all,
>>because honestly, it's getting hugely annoying.
>>
>>And it's not annoying due to the unnecessary diffs per se, but because
>>this tool header sync then causes 'objtool' - which also uses some of
>>those headers - to be rebuilt, and then that causes *everything* to be
>>rebuilt.
>>
>>Just because the perf tree decided it needed to sync headers for
>>unexplained reasons.
>>
>>The docs say "this works surprisingly well". That *used* to be the
>>case. But with objtool also being affected, it really does *not* work
>>well at all.
>>
>>And no, the tools cannot use the kernel headers directly. That
>>*really* didn't work well, and required synchronizing kernel changes
>>with tooling changes, and was just a pain.
>>
>>So the "header copies" solved a real problem, but we need to figure
>>out something better.
>>
>>And honestly, the "something better" may be to just remove the
>>mindless check for "headers aren't 100% sync".
>>
>>Because 99% of the time nobody cares. This time, for example, the
>>header changes in question were comments and stuff that was inside a
>>__KERNEL__ guard.
>>
>>So how about just at least as a first step trying to remove the
>>warning that is actively detrimental, and only do header syncs when
>>there is a *real* reason for them?
>
>Yeah, I agree, annoying, I'll work on making this opt-in, i.e. no warnings by default, a new target to check if drift happened. 

Also maybe this is something for Sashiko or some other AI agent, to automate/suggest/do the sync when it makes sense and not just out of making it is in sync no matter what.

- Arnaldo

Sry, the previous reply didn't make it to lkml :-/

Re: [GIT PULL] perf tools fixes for v7.0: 2nd batch

[Ian Rogers]

On Tue, Mar 24, 2026 at 9:32 AM Arnaldo Melo <arnaldo.melo@gmail.com> wrote:
>
>
>
> On March 24, 2026 1:17:18 PM GMT-03:00, Arnaldo Melo <arnaldo.melo@gmail.com> wrote:
> >
> >
> >On March 24, 2026 1:12:08 PM GMT-03:00, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >>On Mon, 23 Mar 2026 at 03:57, Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> >>>
> >>>       tools arch x86: Sync the msr-index.h copy with the kernel sources
> >>>       tools headers UAPI: Sync linux/kvm.h with the kernel sources
> >>>       tools headers UAPI: Sync x86's asm/kvm.h with the kernel sources
> >>>       tools headers: Synchronize linux/build_bug.h with the kernel sources
> >>
> >>So I think we need to come up with some solution to *not* do this all,
> >>because honestly, it's getting hugely annoying.
> >>
> >>And it's not annoying due to the unnecessary diffs per se, but because
> >>this tool header sync then causes 'objtool' - which also uses some of
> >>those headers - to be rebuilt, and then that causes *everything* to be
> >>rebuilt.
> >>
> >>Just because the perf tree decided it needed to sync headers for
> >>unexplained reasons.
> >>
> >>The docs say "this works surprisingly well". That *used* to be the
> >>case. But with objtool also being affected, it really does *not* work
> >>well at all.
> >>
> >>And no, the tools cannot use the kernel headers directly. That
> >>*really* didn't work well, and required synchronizing kernel changes
> >>with tooling changes, and was just a pain.
> >>
> >>So the "header copies" solved a real problem, but we need to figure
> >>out something better.
> >>
> >>And honestly, the "something better" may be to just remove the
> >>mindless check for "headers aren't 100% sync".
> >>
> >>Because 99% of the time nobody cares. This time, for example, the
> >>header changes in question were comments and stuff that was inside a
> >>__KERNEL__ guard.
> >>
> >>So how about just at least as a first step trying to remove the
> >>warning that is actively detrimental, and only do header syncs when
> >>there is a *real* reason for them?
> >
> >Yeah, I agree, annoying, I'll work on making this opt-in, i.e. no warnings by default, a new target to check if drift happened.
>
> Also maybe this is something for Sashiko or some other AI agent, to automate/suggest/do the sync when it makes sense and not just out of making it is in sync no matter what.

Progress was made as the beauty files moved from tools/include into
tools/perf/trace/beauty. The recompilation should only really happen
if objtool uses a header via tools/include and the entire process
being out-of-sync and needing to rebuild seems to be working as
intended. The sashiko reviews tend to be more demanding in this
regard.

I'd like to see tools/include removed, especially as tools projects
tend to put " -I$(top_srcdir)/tools/include
-I$(top_srcdir)/tools/uapi/include" which prioritizes the kernel over
the UAPI headers. I think this is the opposite of what is expected in
user space. My ideal would be to have things like linux/list.h become
library projects in tools and you "make install_headers" on them, then
have the -I pick up the installed headers path like we do for libbpf,
etc.;
https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/Makefile.perf?h=perf-tools-next&id=c5a244bf17caf2de22f9e100832b75f72b31d3e6#n363
I think this would be cleaner but wouldn't remove the need to keep
things in sync and rebuilding.

Thanks,
Ian

> - Arnaldo
>
> Sry, the previous reply didn't make it to lkml :-/
>

Re: [GIT PULL] perf tools fixes for v7.0: 2nd batch

[Namhyung Kim]

On Tue, Mar 24, 2026 at 11:00:33AM -0700, Ian Rogers wrote:
> On Tue, Mar 24, 2026 at 9:32 AM Arnaldo Melo <arnaldo.melo@gmail.com> wrote:
> >
> >
> >
> > On March 24, 2026 1:17:18 PM GMT-03:00, Arnaldo Melo <arnaldo.melo@gmail.com> wrote:
> > >
> > >
> > >On March 24, 2026 1:12:08 PM GMT-03:00, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > >>On Mon, 23 Mar 2026 at 03:57, Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > >>>
> > >>>       tools arch x86: Sync the msr-index.h copy with the kernel sources
> > >>>       tools headers UAPI: Sync linux/kvm.h with the kernel sources
> > >>>       tools headers UAPI: Sync x86's asm/kvm.h with the kernel sources
> > >>>       tools headers: Synchronize linux/build_bug.h with the kernel sources
> > >>
> > >>So I think we need to come up with some solution to *not* do this all,
> > >>because honestly, it's getting hugely annoying.
> > >>
> > >>And it's not annoying due to the unnecessary diffs per se, but because
> > >>this tool header sync then causes 'objtool' - which also uses some of
> > >>those headers - to be rebuilt, and then that causes *everything* to be
> > >>rebuilt.
> > >>
> > >>Just because the perf tree decided it needed to sync headers for
> > >>unexplained reasons.
> > >>
> > >>The docs say "this works surprisingly well". That *used* to be the
> > >>case. But with objtool also being affected, it really does *not* work
> > >>well at all.
> > >>
> > >>And no, the tools cannot use the kernel headers directly. That
> > >>*really* didn't work well, and required synchronizing kernel changes
> > >>with tooling changes, and was just a pain.
> > >>
> > >>So the "header copies" solved a real problem, but we need to figure
> > >>out something better.
> > >>
> > >>And honestly, the "something better" may be to just remove the
> > >>mindless check for "headers aren't 100% sync".
> > >>
> > >>Because 99% of the time nobody cares. This time, for example, the
> > >>header changes in question were comments and stuff that was inside a
> > >>__KERNEL__ guard.
> > >>
> > >>So how about just at least as a first step trying to remove the
> > >>warning that is actively detrimental, and only do header syncs when
> > >>there is a *real* reason for them?
> > >
> > >Yeah, I agree, annoying, I'll work on making this opt-in, i.e. no warnings by default, a new target to check if drift happened.
> >
> > Also maybe this is something for Sashiko or some other AI agent, to automate/suggest/do the sync when it makes sense and not just out of making it is in sync no matter what.
> 
> Progress was made as the beauty files moved from tools/include into
> tools/perf/trace/beauty. The recompilation should only really happen
> if objtool uses a header via tools/include and the entire process
> being out-of-sync and needing to rebuild seems to be working as
> intended. The sashiko reviews tend to be more demanding in this
> regard.

Agreed.  Maybe we can limit the checker script to look up the beauty
directory only then.

> 
> I'd like to see tools/include removed, especially as tools projects
> tend to put " -I$(top_srcdir)/tools/include
> -I$(top_srcdir)/tools/uapi/include" which prioritizes the kernel over
> the UAPI headers. I think this is the opposite of what is expected in
> user space. My ideal would be to have things like linux/list.h become
> library projects in tools and you "make install_headers" on them, then
> have the -I pick up the installed headers path like we do for libbpf,
> etc.;
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/Makefile.perf?h=perf-tools-next&id=c5a244bf17caf2de22f9e100832b75f72b31d3e6#n363
> I think this would be cleaner but wouldn't remove the need to keep
> things in sync and rebuilding.

Interesting.  It'd be great if we could get rid of any duplication.

Thanks,
Namhyung