On Tue, Sep 10, 2024 at 3:22 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > On Tue, 10 Sep 2024 13:29:57 -0700 > Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > > On Tue, Sep 10, 2024 at 11:54 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > > > > > On Tue, 10 Sep 2024 11:23:29 -0700 > > > Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > > > > > > Does Linus have to be in CC to get any reply here? Come on, it's been > > > > almost a full week. > > > > > > Just FYI, an email like this does piss people off. You are getting upset > > > for waiting "almost a full week"? A full week is what we tell people to > > > > A full week to get a response to a question? Yes, I find it way too > > long. I didn't ask for some complicated code review, did I? I don't > > know who "we" are and where "we" tell people, but I disagree that one > > week is acceptable latency to coordinate stuff like this across > > multiple subsystems. > > Why do I have to answer to you? Once I saw the "ARM64" in the subject, it > immediately went down in priority and honesty, I didn't even read it as I'm > not the ARM64 maintainer. I did skim it to see if my name was mentioned as > I usually try to do with emails, but when it wasn't I ignored it. So, in the end, it wasn't "And we are busy getting ready for Plumbers.", but rather you didn't find the right keywords in my email, right? "Masami" and "Steven" would be the right keywords, but "CONFIG_FPROBE" and "CONFIG_RETHOOK" aren't. Good to know. > > > > > "pointing out"? You and Masami are maintainers of linux-trace tree, > > and rethook is part of that. Masami's original code was the one in > > Yes, but I don't touch arm code. Masami sometimes does (as is the case > here), but it is when we work with the arm maintainers. And? Did I ask you to write that code? Or review that code? Or did I ask the context on why a portion of the patch set didn't end up upstream, while the rest did. The patch set submitted by Masami and signed off by and tested by you. Was it too much to expect that either you or Masami will have a quick answer? I'm sorry, I didn't know you don't really read emails addressed *directly* to you in email's To:, my bad assuming as much. > > > question and I did expect a rather quick reply from him. If not > > Masami, then you would have a context as well. Who else should I be > > asking? > > The arm64 maintainers as they are the ones that maintain that code. Even if I misrouted the question (which I still don't believe I did), is it above you to point it out and CC the right people? > > > > > If ARM64 folks somehow have more context, it wouldn't be that hard to > > mention and redirect, instead of ghosting my email. > > You should know they have more context because they are the actual > maintainers. I shouldn't have to point that out to you. Maybe they do, maybe they don't. I'm relying and using kprobes/kretprobes, and I still don't have a clear understanding of all the nuances and differences of k[ret]probes, rethook, fprobe, and ftrace, and what works with what. Call me dumb. I don't expect ARM64 maintainers to know these nuances. They are experts in ARM64-specifics, not in a tracing layer, I presume. > > $ wget -O /tmp/t.patch https://lore.kernel.org/bpf/164338038439.2429999.17564843625400931820.stgit@devnote2/raw > $ ./scripts/get_maintainer.pl t.patch > Catalin Marinas <catalin.marinas@xxxxxxx> (maintainer:ARM64 PORT (AARCH64 ARCHITECTURE),commit_signer:2/6=33%) > Will Deacon <will@xxxxxxxxxx> (maintainer:ARM64 PORT (AARCH64 ARCHITECTURE),commit_signer:5/6=83%) > Puranjay Mohan <puranjay@xxxxxxxxxx> (commit_signer:5/6=83%,authored:3/6=50%,added_lines:30/255=12%) > Mark Rutland <mark.rutland@xxxxxxx> (commit_signer:4/6=67%,authored:2/6=33%,added_lines:105/255=41%,removed_lines:47/49=96%) > "Madhavan T. Venkataraman" <madvenka@xxxxxxxxxxxxxxxxxxx> (commit_signer:2/6=33%) > chenqiwu <qiwuchen55@xxxxxxxxx> (authored:1/6=17%,added_lines:120/255=47%) > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx (moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)) > linux-kernel@xxxxxxxxxxxxxxx (open list) > bpf@xxxxxxxxxxxxxxx (open list:BPF [MISC]:Keyword:(?:\b|_)bpf(?:\b|_)) > > Neither my name nor Masami's shows up. $ vim wget -O /tmp/t.patch https://lore.kernel.org/bpf/164338038439.2429999.17564843625400931820.stgit@devnote2/raw $ grep -E 'Masami|Steven' /tmp/t.patch From: Masami Hiramatsu <mhiramat@xxxxxxxxxx> Masami Hiramatsu <mhiramat@xxxxxxxxxx>, netdev@xxxxxxxxxxxxxxx, Steven Rostedt <rostedt@xxxxxxxxxxx>, Signed-off-by: Masami Hiramatsu <mhiramat@xxxxxxxxxx> Furthermore, $ git grep 'config RETHOOK' kernel/trace/Kconfig:config RETHOOK $ scripts/get_maintainer.pl kernel/trace/Kconfig Steven Rostedt <rostedt@xxxxxxxxxxx> (maintainer:TRACING) Masami Hiramatsu <mhiramat@xxxxxxxxxx> (maintainer:TRACING) Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> (reviewer:TRACING) linux-kernel@xxxxxxxxxxxxxxx (open list:TRACING) linux-trace-kernel@xxxxxxxxxxxxxxx (open list:TRACING) You can define your responsibilities as narrow as you'd like. I was asking a question about the RETHOOK patchset/feature overall and why a portion of the original patch set is missing, in particular. > > > > > > > > > Funny part is, I was just about to start reviewing Masami's fprobe patches > > > when I read this. Now I feel reluctant to. I'll do it anyway because they > > > are Masami's patches, but if they were yours, I would have pushed it off a > > > week or two with that attitude. > > > > (I'll ignore all the personal stuff) > > Maybe you shouldn't ignore it. If you think you can get answers by jumping > immediately to "I'm going to tell on you to Linus", you may want to rethink No I don't, and I'd hate to have to do that. Which is why I didn't CC Linus. And I get that stuff slips through sometimes, as I said. But I don't get your absolutely overblown reaction to a question born out of frustration of being ignored. > your approach. A simple "Hey Steve and Masami, what's going on?" would be > the "human" thing to do. Especially since you appear to be mad at us for Don't project, Steven. I'm not mad, though definitely frustrated by a very unresponsive ML and its maintainers. I tried a "hey Masami" approach in [0], and it didn't help much, unfortunately. And it's not the first time I'm ghosted on this mailing list. Would you say 4.5 months not getting any reply to [1] is long enough? Though, let me guess, it's x86-specific and you don't have anything to do with this, right? Going forward I'll consult get_maintainer.pl every time to check if you are *NOT* responsible for something, my bad. I didn't live by get_maintainer.pl up until now. [0] https://lore.kernel.org/bpf/CAEf4BzbbVRGROtRn8PM4h1493avHMggz1kSDDJcaNZ1USO_eVw@xxxxxxxxxxxxxx [1] https://lore.kernel.org/linux-trace-kernel/20240425000211.708557-1-andrii@xxxxxxxxxx/ > not replying to an email about code we do not maintain. > > Sorry, but you're not my boss, I don't have to reply to any of your emails. I didn't say I am, not sure where you got that from. But I did expect a bit more ownership from you as a linux-trace tree maintainer. I'm sorry. > > > > > You are probably talking about [0]. But I was asking about [1], i.e., > > adding HAVE_RETHOOK support to ARM64. Despite all your emotions above, > > can I still get a meaningful answer as for why that wasn't landed and > > what prevents it from landing right now before Masami's 20-patch > > series lands? > > > > [0] https://lore.kernel.org/linux-trace-kernel/172398527264.293426.2050093948411376857.stgit@devnote2/ > > [1] https://lore.kernel.org/bpf/164338038439.2429999.17564843625400931820.stgit@devnote2/ > > > > > > > > Again, just letting you know. > > Because [1] isn't something I maintain. So I ignored it. Yes, you are doing a great job at ignoring stuff. That I understood very well, thank you. > > arch/arm64/Kconfig | 1 > arch/arm64/include/asm/stacktrace.h | 2 - > arch/arm64/kernel/probes/Makefile | 1 > arch/arm64/kernel/probes/rethook.c | 25 +++++++ > arch/arm64/kernel/probes/rethook_trampoline.S | 87 +++++++++++++++++++++++++ > arch/arm64/kernel/stacktrace.c | 7 ++ > > None of that would go through my tree unless an arm64 maintainer asked. > > In fact, I need a bunch of acks from all maintainers of the architectures > that are touched by [0] before I can pull it in. Which means it will likely > not make this merge window. > > -- Steve
