On Thu, 11 Jul 2024 10:51:18 +0200 Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > On Wed, Jul 10, 2024 at 11:40:17AM -0700, Andrii Nakryiko wrote: > > On Wed, Jul 10, 2024 at 7:56 AM Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote: > > > > > > On Wed, 10 Jul 2024 12:10:03 +0200 > > > Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > > > > > On Wed, Jul 10, 2024 at 07:10:46AM +0900, Masami Hiramatsu wrote: > > > > > > > > > > FFS :-/ That touches all sorts and doesn't have any perf ack on. Masami > > > > > > what gives? > > > > > > > > > > This is managing *probes and related dynamic trace-events. Those has been > > > > > moved from tip. Could you also add linux-trace-kernel@vger ML to CC? > > > > > > > > ./scripts/get_maintainer.pl -f kernel/events/uprobes.c > > > > > > > > disagrees with that, also things like: > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git/commit/?h=probes/for-next&id=4a365eb8a6d9940e838739935f1ce21f1ec8e33f > > > > > > > > touch common perf stuff, and very much would require at least an ack > > > > from the perf folks. > > > > > > Hmm, indeed. I'm OK to pass those patches (except for trace_uprobe things) > > > to -tip if you can. > > > > > > > > > > > Not cool. > > > > > > > You were aware of this patch and cc'ed personally (just like > > linux-perf-users@xxxxxxxxxxxxxxx) on all revisions of it. I addressed > > your concerns in [0], you went silent after that and patches were > > sitting idle for more than a month. > > Yeah, I remember seeing it. But I was surprised it got applied. If I'm > tardy -- this can happen, more so of late since I'm still recovering > from injury and I get far more email than I could hope to process in a > work day -- please ping. I also forgot to ping you. I'll ask you next time. > > (also, being 'forced' into using a split keyboard means I'm also > re-learning how to type, further slowing me down -- training muscle > memory takes a while) > > Taking patches that touch other trees is fairly common, but in all those > cases an ACK is 'required'. OK, should I wait for your Ack for other patches on probes/for-next? > > (also also, I'm not the only maintainer there) > > > But regardless, if you'd like me to do any adjustments, please let me know. > > > > [0] https://lore.kernel.org/all/CAEf4Bzazi7YMz9n0V46BU7xthQjNdQL_zma5vzgCm_7C-_CvmQ@xxxxxxxxxxxxxx/ > > > > I'll check, it might be fine, its just the surprise of having it show up > in some random tree that set me off. > > > > Yeah, the probe things are boundary. > > > BTW, IMHO, there could be dependency issues on *probes. Those are usually used > > > by ftrace/perf/bpf, which are managed by different trees. This means a series > > > can span multiple trees. Mutually reviewing is the solution? > > > > > > > I agree, there is no one best tree for stuff like this. So as long as > > relevant people and mailing lists are CC'ed we hopefully should be > > fine? > > Typically, yeah, that should work just fine. > > But if Masami wants to do uprobes, then it might be prudent to add a > MAINTAINERS entry for it. > > A solution might be to add a UPROBES entry and add masami, oleg (if he > wants) and myself as maintainers -- did I forget anyone? Git seems to > suggest it's mostly been Oleg carrying this thing. That sounds good for me. Like this?
