From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 944D4EE01F1 for ; Wed, 11 Sep 2024 00:28:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References: MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=B3G46MS/GN1BRk1GDqS+0a3Dqj+XZN03OuynBKhipNo=; b=eDKPC7vQ1a58k2XUeKRxBm9YZ+ GE3kqrbz5ioUOwPsLg/6Fid3ZUDf+E5702kGperuXKksFXMyEtNDMDj4HvpvXtGwZ+f/usbzYSf30 /YQA+59HOChRacP/k2FqfTv+GNdLBPpgU5JzFrmzqP2NWjTAvBoXn/IVWY+erkpcpLsWcmPxdJDDy /mNHcQoOZdZpM67k7faGgrJ90qZ3FvAzkJTQvp83ShaRdHHxROQUyCUKFl/MIU0yAd+rCmEAlDLz/ ZtkyZVHVuUOVVQVPpVMvGysnHquidkXNRGZLQ+aRQOmGIIX9pJzwARHpuF7a74IzGQJtStM7rAyWV rIMgKHuw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1soBDd-00000007aEV-1oOb; Wed, 11 Sep 2024 00:28:25 +0000 Received: from mail-pj1-x102a.google.com ([2607:f8b0:4864:20::102a]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1soBCb-00000007a8T-20AR for linux-arm-kernel@lists.infradead.org; Wed, 11 Sep 2024 00:27:23 +0000 Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-2db85775c43so169852a91.0 for ; Tue, 10 Sep 2024 17:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726014440; x=1726619240; darn=lists.infradead.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=B3G46MS/GN1BRk1GDqS+0a3Dqj+XZN03OuynBKhipNo=; b=FDfZGQiEfRLXTe/sUqK1pvyqFEqLkZy6BqEct6yLm1b+sTPFV2a8Q6HSJYgz2Dy37t Ezo6MopgslOQUlLR0hRCt1LwcosoBo5VMn/73EwelF/l3PkBbg80UlqENq5bQrcEcm1K fvw4rYC7T02uHa38p69LNCFAWISBluFabgJpcSVuI6GLIOO2q1hzfg+hPvG4+1waZSLr xz2FkOB2HhXaFsXVozHX3DkKUS4XXa15bVUXEOaXPgLbqaBjczFiPdfSzs3IowEhq4rb VF3VkmTcC8rzBqA4A+ibNnLOVgqzTMbczfgj9hGbIDHKPctEpq2zGT+5mfgWtRYw4r9d ykdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726014440; x=1726619240; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=B3G46MS/GN1BRk1GDqS+0a3Dqj+XZN03OuynBKhipNo=; b=tV/nD8/FgyWGLN59tHEKwwJV+hAT6tonbQIU6f46yBSOl2YnCXAOWqT88iYaLu5EbN 6A27FzEYEQY3SIMRvQiqc4Q2TVUVmG4RJ06nQ/zW7pu90PNWLOCLemoKJCgLXK4XhoQ5 5DTDg+HsMRxP1fGS/jgWZbGRiZ/yBK/QkCN/YCwKLy57kksTHKGedPAOa+5TDVBZcBHR L2KjIbDPkiSJknW513KH3kkJMhDw/+PX78LkLFxhpTLNdyDoQUFA9eRppP314FvaLoaU MPIsFyPLj9ihYLT6iL5C/OGPeCt8LQZeqfrIt8Yxm2sWIO2hqwG7WkhI0+MAHBmEybcP pQHQ== X-Forwarded-Encrypted: i=1; AJvYcCUkFrBRa1lEWdHeHFGA0nB3RLYOVpnYxZzTMVhxrA6OqhwTQJs5cbUR+J1fsDsALs6X3phur2zOpuf1dMBTeQJA@lists.infradead.org X-Gm-Message-State: AOJu0YzhpyABrz4GWyS8qQ+H/tQWWNUJTGBuKlnbwqeapuT+6Cj7Tdi1 vhN0Ea15TeT4lDx9iu06NSo3lGscOZQjLQeWJcyhbgbwYp2mMsMVPypvXEshhsWOwvozKg/SEwv IqanDCm8uabjiUBSiLak3Q96pwBqAdFsW X-Google-Smtp-Source: AGHT+IGh1U+VrPkE+xUyC1wGNgrtRAwe6Jw7TUurE36BNPnKB7qGowjg+hLoplVIH7fmY3hj+wATDFppB4Z9CqlWgps= X-Received: by 2002:a17:90a:ba96:b0:2c9:36bf:ba6f with SMTP id 98e67ed59e1d1-2db67181b2cmr6966104a91.3.1726014440425; Tue, 10 Sep 2024 17:27:20 -0700 (PDT) MIME-Version: 1.0 References: <20240910145431.20e9d2e5@gandalf.local.home> <20240910182209.65ab3452@gandalf.local.home> In-Reply-To: <20240910182209.65ab3452@gandalf.local.home> From: Andrii Nakryiko Date: Tue, 10 Sep 2024 17:27:06 -0700 Message-ID: Subject: Re: Unsupported CONFIG_FPROBE and CONFIG_RETHOOK on ARM64 To: Steven Rostedt Cc: Masami Hiramatsu , bpf , Linux trace kernel , adubey@linux.ibm.com, "Naveen N. Rao" , KP Singh , linux-arm-kernel , Mark Rutland , Will Deacon , Alexei Starovoitov , Catalin Marinas , Florent Revest , Puranjay Mohan Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240910_172721_551156_5CB85E2D X-CRM114-Status: GOOD ( 50.96 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Sep 10, 2024 at 3:22=E2=80=AFPM Steven Rostedt wrote: > > On Tue, 10 Sep 2024 13:29:57 -0700 > Andrii Nakryiko wrote: > > > On Tue, Sep 10, 2024 at 11:54=E2=80=AFAM Steven Rostedt wrote: > > > > > > On Tue, 10 Sep 2024 11:23:29 -0700 > > > Andrii Nakryiko wrote: > > > > > > > Does Linus have to be in CC to get any reply here? Come on, it's be= en > > > > almost a full week. > > > > > > Just FYI, an email like this does piss people off. You are getting up= set > > > 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 a= s > 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 (maintainer:ARM64 PORT (AARCH64= ARCHITECTURE),commit_signer:2/6=3D33%) > Will Deacon (maintainer:ARM64 PORT (AARCH64 ARCHITECTUR= E),commit_signer:5/6=3D83%) > Puranjay Mohan (commit_signer:5/6=3D83%,authored:3/= 6=3D50%,added_lines:30/255=3D12%) > Mark Rutland (commit_signer:4/6=3D67%,authored:2/6= =3D33%,added_lines:105/255=3D41%,removed_lines:47/49=3D96%) > "Madhavan T. Venkataraman" (commit_signer:= 2/6=3D33%) > chenqiwu (authored:1/6=3D17%,added_lines:120/255= =3D47%) > linux-arm-kernel@lists.infradead.org (moderated list:ARM64 PORT (AARCH64 = ARCHITECTURE)) > linux-kernel@vger.kernel.org (open list) > bpf@vger.kernel.org (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 Masami Hiramatsu , netdev@vger.kernel.org, Steven Rostedt , Signed-off-by: Masami Hiramatsu Furthermore, $ git grep 'config RETHOOK' kernel/trace/Kconfig:config RETHOOK $ scripts/get_maintainer.pl kernel/trace/Kconfig Steven Rostedt (maintainer:TRACING) Masami Hiramatsu (maintainer:TRACING) Mathieu Desnoyers (reviewer:TRACING) linux-kernel@vger.kernel.org (open list:TRACING) linux-trace-kernel@vger.kernel.org (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 pa= tches > > > 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 jumpin= g > immediately to "I'm going to tell on you to Linus", you may want to rethi= nk 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, unfortunat= ely. 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/CAEf4BzbbVRGROtRn8PM4h1493avHMggz1kSDDJca= NZ1USO_eVw@mail.gmail.com [1] https://lore.kernel.org/linux-trace-kernel/20240425000211.708557-1-an= drii@kernel.org/ > 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 email= s. 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.20= 50093948411376857.stgit@devnote2/ > > [1] https://lore.kernel.org/bpf/164338038439.2429999.1756484362540093= 1820.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 like= ly > not make this merge window. > > -- Steve