[PATCH v7 0/3] perf tools: port UI from GTK2 to GTK4

Matt Turner posted 3 patches 2 weeks, 5 days ago
There is a newer version of this series
tools/build/Makefile.feature                     |  4 +-
tools/build/feature/Makefile                     | 10 +--
tools/build/feature/test-gtk2-infobar.c          | 12 ---
tools/build/feature/{test-gtk2.c => test-gtk4.c} |  4 +-
tools/perf/Documentation/perf-report.txt         |  2 +-
tools/perf/Makefile                              |  2 +-
tools/perf/Makefile.config                       | 27 +++----
tools/perf/Makefile.perf                         |  6 +-
tools/perf/builtin-annotate.c                    |  8 +-
tools/perf/builtin-report.c                      |  8 +-
tools/perf/scripts/install-build-deps.sh         |  4 +-
tools/perf/tests/make                            |  4 +-
tools/perf/ui/gtk/annotate.c                     | 36 ++++-----
tools/perf/ui/gtk/browser.c                      | 96 ++++++++++++++++++-----
tools/perf/ui/gtk/gtk.h                          | 16 ++--
tools/perf/ui/gtk/hists.c                        | 66 ++++++++--------
tools/perf/ui/gtk/progress.c                     | 40 +++++++---
tools/perf/ui/gtk/setup.c                        |  5 +-
tools/perf/ui/gtk/util.c                         | 97 ++++++++++++++----------
tools/perf/ui/setup.c                            |  2 +-
tools/perf/util/annotate.c                       | 11 +++
tools/perf/util/annotate.h                       | 12 +--
22 files changed, 275 insertions(+), 197 deletions(-)
[PATCH v7 0/3] perf tools: port UI from GTK2 to GTK4
Posted by Matt Turner 2 weeks, 5 days ago
GTK2 is long dead upstream and increasingly hard to keep building on
current distros. This series ports perf's GTK-based report browser to
GTK4 and fixes it up so it's actually loadable at runtime after the
port.

Patch 1 does the mechanical port (build system, widget API changes),
including the leftover-GTK2-call and signal-handling fixes that were a
separate patch 3 in v4. Patch 2 fixes a runtime issue found after the
port that prevented the browser from loading. Patch 3 fixes two stack
buffer overflows in the hierarchy view that predate the port.

Signed-off-by: Matt Turner <mattst88@gmail.com>
---
Changes in v7:
- Add patch 3: fix two stack buffer overflows in the hierarchy view
  (perf_gtk__show_hierarchy()'s unbounded strcat() into a 512-byte
  buffer, and an advance_hpp() size_t underflow in
  perf_gtk__add_hierarchy_entries()). Both predate the GTK4 port
- Link to v6: https://lore.kernel.org/r/20260906-perf-gtk2-v6-0-695d1c01aaa1@gmail.com

Changes in v6:
- Explicitly include <string.h> in annotate.c (strcpy()) and
  <stdarg.h>/<stdio.h> in hists.c (va_list, snprintf()) instead of
  relying on transitive includes, which isn't guaranteed on musl
- Link to v5: https://lore.kernel.org/r/20260906-perf-gtk2-v5-0-e8747a65c240@gmail.com

Changes in v5:
- Fold v4's patch 3 into patch 1, since sigprocmask() only blocks
  delivery to the calling thread: it did nothing to stop the signal
  handler from running concurrently on another thread and doesn't make
  the handler's GSList calls async-signal-safe either
- Defer perf_gtk__exit() on SIGINT/SIGQUIT/SIGTERM to a GLib source via
  g_unix_signal_add() instead of running it straight out of a real
  signal handler, so it always runs on the main-loop thread, serialized
  with perf_gtk__error()'s updates to perf_gtk__error_loops, instead of
  racing them from arbitrary signal-handler context
- Keep a real handler for SIGSEGV/SIGFPE, since those are synchronous
  faults with no "later" to defer to, but pare it down to reporting and
  reraising the default disposition: there's no safe way to run
  GTK/GLib code from the faulting context itself
- Link to v4: https://lore.kernel.org/r/20260906-perf-gtk2-v4-0-97e92ee07214@gmail.com

Changes in v4:
- Fix gtk_widget_show()/gtk_widget_hide() calls left over from the GTK2
  port: both were removed in GTK 4. Replace with gtk_widget_set_visible(),
  adding a small wrapper for the info-bar "response" signal callback
- Block SIGSEGV/SIGFPE/SIGINT/SIGQUIT/SIGTERM around the
  perf_gtk__error_loops list updates in perf_gtk__error(): the signal
  handler (perf_gtk__signal() -> perf_gtk__exit() ->
  perf_gtk__quit_error_dialog()) walks that same list and could fire
  mid-update, corrupting it
- Link to v3: https://lore.kernel.org/r/20260906-perf-gtk2-v3-0-e1f2086214a0@gmail.com

Changes in v3:
- Fix GMainLoop leak if perf_gtk__error() is called re-entrantly: track
  active loops in a list instead of a single global pointer
- Add explicit <stdarg.h>/<stdio.h> includes instead of relying on
  transitive inclusion, which musl doesn't guarantee
- Drop the gtk4-infobar feature check and HAVE_GTK_INFO_BAR_SUPPORT:
  GtkInfoBar has been unconditionally available since well before GTK 4,
  and the check was failing outright due to its deprecation warning
- Link to v2: https://lore.kernel.org/r/20260906-perf-gtk2-v2-0-3eccff053cd1@gmail.com

Changes in v2:
- Fix error dialog's nested GMainLoop hanging if the parent window
  closes or a signal arrives while the dialog is open (quit from
  "destroy", not just "response")
- Fix build with GTK_INFO_BAR_SUPPORT: gtk_info_bar_get_content_area()
  is gone in GTK 4, use gtk_info_bar_add_child() instead
- Fix use-after-free in the progress dialog on manual close
- Fix reuse of an exhausted va_list in the vasprintf() failure path
- Link to v1: https://lore.kernel.org/r/20260906-perf-gtk2-v1-0-7564bf8523a9@gmail.com

---
Matt Turner (3):
      tools: port perf ui from GTK 2 to GTK 4
      perf tools: make the GTK4 report browser actually loadable at runtime
      perf tools gtk: fix two hierarchy-view stack buffer overflows

 tools/build/Makefile.feature                     |  4 +-
 tools/build/feature/Makefile                     | 10 +--
 tools/build/feature/test-gtk2-infobar.c          | 12 ---
 tools/build/feature/{test-gtk2.c => test-gtk4.c} |  4 +-
 tools/perf/Documentation/perf-report.txt         |  2 +-
 tools/perf/Makefile                              |  2 +-
 tools/perf/Makefile.config                       | 27 +++----
 tools/perf/Makefile.perf                         |  6 +-
 tools/perf/builtin-annotate.c                    |  8 +-
 tools/perf/builtin-report.c                      |  8 +-
 tools/perf/scripts/install-build-deps.sh         |  4 +-
 tools/perf/tests/make                            |  4 +-
 tools/perf/ui/gtk/annotate.c                     | 36 ++++-----
 tools/perf/ui/gtk/browser.c                      | 96 ++++++++++++++++++-----
 tools/perf/ui/gtk/gtk.h                          | 16 ++--
 tools/perf/ui/gtk/hists.c                        | 66 ++++++++--------
 tools/perf/ui/gtk/progress.c                     | 40 +++++++---
 tools/perf/ui/gtk/setup.c                        |  5 +-
 tools/perf/ui/gtk/util.c                         | 97 ++++++++++++++----------
 tools/perf/ui/setup.c                            |  2 +-
 tools/perf/util/annotate.c                       | 11 +++
 tools/perf/util/annotate.h                       | 12 +--
 22 files changed, 275 insertions(+), 197 deletions(-)
---
base-commit: 9f0346dcbea363787186c94ef94dd01aaa215afa
change-id: 20260906-perf-gtk2-555ca04bb652

Best regards,
-- 
Matt Turner <mattst88@gmail.com>
Re: [PATCH v7 0/3] perf tools: port UI from GTK2 to GTK4
Posted by Alexei Starovoitov 2 weeks, 5 days ago
On Sun, Sep 6, 2026 at 1:13 PM Matt Turner <mattst88@gmail.com> wrote:
>
> GTK2 is long dead upstream and increasingly hard to keep building on
> current distros. This series ports perf's GTK-based report browser to
> GTK4 and fixes it up so it's actually loadable at runtime after the
> port.
>
> Patch 1 does the mechanical port (build system, widget API changes),
> including the leftover-GTK2-call and signal-handling fixes that were a
> separate patch 3 in v4. Patch 2 fixes a runtime issue found after the
> port that prevented the browser from loading. Patch 3 fixes two stack
> buffer overflows in the hierarchy view that predate the port.
>
> Signed-off-by: Matt Turner <mattst88@gmail.com>
> ---
> Changes in v7:

Matt, please stop the spam.
Wait for humans to reply before respinning.
7 revisions in one day is way too much.
Re: [PATCH v7 0/3] perf tools: port UI from GTK2 to GTK4
Posted by Matt Turner 2 weeks, 5 days ago
On Sun, Sep 6, 2026 at 4:59 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Sun, Sep 6, 2026 at 1:13 PM Matt Turner <mattst88@gmail.com> wrote:
> >
> > GTK2 is long dead upstream and increasingly hard to keep building on
> > current distros. This series ports perf's GTK-based report browser to
> > GTK4 and fixes it up so it's actually loadable at runtime after the
> > port.
> >
> > Patch 1 does the mechanical port (build system, widget API changes),
> > including the leftover-GTK2-call and signal-handling fixes that were a
> > separate patch 3 in v4. Patch 2 fixes a runtime issue found after the
> > port that prevented the browser from loading. Patch 3 fixes two stack
> > buffer overflows in the hierarchy view that predate the port.
> >
> > Signed-off-by: Matt Turner <mattst88@gmail.com>
> > ---
> > Changes in v7:
>
> Matt, please stop the spam.
> Wait for humans to reply before respinning.
> 7 revisions in one day is way too much.

My apologies. I figured it would actually save humans time if I went
ahead and addressed all the sashiko-generated feedback. Dunno.

Is there a way to get feedback from sashiko without mailing the public list?
Re: [PATCH v7 0/3] perf tools: port UI from GTK2 to GTK4
Posted by Ian Rogers 2 weeks, 3 days ago
On Sun, Sep 6, 2026 at 2:05 PM Matt Turner <mattst88@gmail.com> wrote:
>
> On Sun, Sep 6, 2026 at 4:59 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Sun, Sep 6, 2026 at 1:13 PM Matt Turner <mattst88@gmail.com> wrote:
> > >
> > > GTK2 is long dead upstream and increasingly hard to keep building on
> > > current distros. This series ports perf's GTK-based report browser to
> > > GTK4 and fixes it up so it's actually loadable at runtime after the
> > > port.
> > >
> > > Patch 1 does the mechanical port (build system, widget API changes),
> > > including the leftover-GTK2-call and signal-handling fixes that were a
> > > separate patch 3 in v4. Patch 2 fixes a runtime issue found after the
> > > port that prevented the browser from loading. Patch 3 fixes two stack
> > > buffer overflows in the hierarchy view that predate the port.
> > >
> > > Signed-off-by: Matt Turner <mattst88@gmail.com>
> > > ---
> > > Changes in v7:
> >
> > Matt, please stop the spam.
> > Wait for humans to reply before respinning.
> > 7 revisions in one day is way too much.
>
> My apologies. I figured it would actually save humans time if I went
> ahead and addressed all the sashiko-generated feedback. Dunno.
>
> Is there a way to get feedback from sashiko without mailing the public list?

TL;DR: drop bpf from the to/cc list when sending patches. This work is
most interesting to linux-perf-users where multiple versions of a
patch series within a short period of time are common.

I appreciate having the latest patches to review. If Sashiko provides
feedback, the change goes on my 'to be reviewed later' pile, which
hinders getting code/fixes landed.
It is possible to configure Sashiko to 'embargo' its feedback for a
set number of hours. Networking does this, and it can be frustrating
when you must wait for a patch to receive review before landing it. It
also slows down developers.

Sashiko isn't adopted on all mailing lists, and while it is a widely
praised, others don't want the email churn. In a year or so, when the
models are better, I imagine the churn will decrease as:
1) If AI is used to create the code then it should be better able to
predict Sashiko-like issues,
2) Sashiko itself can report all problems, suggest changes, etc.
rather than its current drip drip of issues.

Thanks for the contribution!
Ian