Re: [PATCH 00/19] perf: Make perf_pmu_unregister() usable

[Ingo Molnar <mingo@kernel.org>]

* Peter Zijlstra <peterz@infradead.org> wrote:

> Hi,
> 
> Lucas convinced me that perf_pmu_unregister() is a trainwreck; after
> considering a few options I was like, how hard could it be..
> 
> So find here a few patches that clean things up in preparation and then a final
> patch that makes unregistering a PMU work by introducing a new event state
> (REVOKED) and ensuring that any event in such a state will never get to using
> it's PMU methods ever again.

So it looks like this series first got lost in the usual end-of-year 
fog of holidays, then it has become somewhat bitrotten due to other 
perf changes interacting and creating conflicts. I cannot find these 
patches in queue.git anymore, other than the somewhat stale 4+ months 
old perf/pmu-unregister branch from October 2024.

Which I found a bit sad, because these cleanups to the control flow and 
error handling of these key perf primitives was a substantial reduction 
of our years long technical debt in this area.

So to move things forward I dusted off most of these patches, reviewed 
the logic, resolved the conflicts, folded in the fix to pmu_dev_alloc() 
that Ravi found (and upgraded his 'looks OK' reply into Acked-by tags), 
added/extended changelogs, did some testing due diligence and sorted 
them into their appropriate -next branches:

  #
  # tip:[locking/core]
  #
  # After 10 years of this lockdep debug check hidden behind 
  # CONFIG_DEBUG_ATOMIC_SLEEP=y I definitely wasn't brave enough to stick 
  # this into an urgent branch. Sue me.
  #
  a1b65f3f7c6f ("lockdep/mm: Fix might_fault() lockdep check of current->mm->mmap_lock")

  #
  # tip:[perf/urgent]
  #
  # These look like obvious fixes that can be accelerated to -rc6
  #
  003659fec9f6 ("perf/core: Fix perf_pmu_register() vs. perf_init_event()")
  2565e42539b1 ("perf/core: Fix pmus_lock vs. pmus_srcu ordering")

  #
  # tip:[perf/core]
  #
  # These are most of the remaining patches from this series, except for 15/19
  # which I was unsure about and 19/19 which is still under discussion:
  #
  02be310c2d24 ("perf/core: Simplify the perf_event_alloc() error path
  e6b17cfd528d ("perf/core: Simplify the perf_pmu_register() error path")
  742d5df92842 ("perf/core: Simplify perf_pmu_register()")
  9954ea69de5c ("perf/core: Simplify perf_init_event()")
  ebfe83832e39 ("perf/core: Simplify perf_event_alloc()")
  46cc0835d258 ("perf/core: Merge struct pmu::pmu_disable_count into struct perf_cpu_pmu_context::pmu_disable_count")
  a57411b14ea0 ("perf/core: Add this_cpc() helper")
  8e140c656746 ("perf/core: Introduce perf_free_addr_filters()")
  26700b1359a1 ("perf/bpf: Robustify perf_event_free_bpf_prog()")
  7503c90c0df8 ("perf/core: Simplify the perf_mmap() control flow")
  8c7446add31e ("perf/core: Further simplify perf_mmap()")
  6cbfc06a8590 ("perf/core: Remove retry loop from perf_mmap()")
  244b28f87ba4 ("perf/core: Lift event->mmap_mutex in perf_mmap()")

As to 'testing due diligence', that's overselling it really, it was 
mostly just some quick build/boot and functionality test combined
with perf test runs, ie. very light testing. Caveat emptor, but of
course the end result is perfect if we disregard any new bugs.

Thanks,

	Ingo