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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4CBA3C001E0 for ; Tue, 1 Aug 2023 15:18:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232454AbjHAPSh (ORCPT ); Tue, 1 Aug 2023 11:18:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42568 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229819AbjHAPSd (ORCPT ); Tue, 1 Aug 2023 11:18:33 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E6CD82116; Tue, 1 Aug 2023 08:18:30 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4693E615E6; Tue, 1 Aug 2023 15:18:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3111EC433C7; Tue, 1 Aug 2023 15:18:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690903109; bh=9zE3B/GzLbe9RK3XK4iNIjOkmj6TzTD5UskW9ugQeFc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=tcNCDq0gVabvvlUcl27p35Ui7WkL+VQMdfoqPGtPSX4GjohIEg0bcMkuETnOzffpB P/VEmk1oGKPtb5gVYqZlWgwsIPOtUdKcyaO4HijEewZRkxc2fpuwGoVP32nqBxfbRS ijRFKRPDh7AfM8s8FFhPjlgZKd/wOchK3PA5pgqERNLOFGSJr3sXdooJjT2iVClsFt QftIonj9c0c+0lrYZO49aDSj6JKglZdN9unSfJEyTMBc/EkGEuRIhr5cHRhAM5rLQf 2kyuRGm1MvFXL/Ll+p05+pIMOAVYMKoEmuK/Qldgs9G1o3Mg6vPSwskew7EMjNtK/F uoUDOFoBhP93w== Date: Wed, 2 Aug 2023 00:18:24 +0900 From: Masami Hiramatsu (Google) To: Alexei Starovoitov Cc: Steven Rostedt , "Masami Hiramatsu (Google)" , linux-trace-kernel@vger.kernel.org, LKML , Martin KaFai Lau , bpf , Sven Schnelle , Alexei Starovoitov , Linus Torvalds Subject: Re: [PATCH v4 3/9] bpf/btf: Add a function to search a member of a struct/union Message-Id: <20230802001824.90819c7355283843178d9163@kernel.org> In-Reply-To: References: <169078860386.173706.3091034523220945605.stgit@devnote2> <169078863449.173706.2322042687021909241.stgit@devnote2> <20230731211527.3bde484d@gandalf.local.home> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-trace-kernel@vger.kernel.org On Mon, 31 Jul 2023 19:24:25 -0700 Alexei Starovoitov wrote: > On Mon, Jul 31, 2023 at 6:15 PM Steven Rostedt wrote: > > > > On Mon, 31 Jul 2023 14:59:47 -0700 > > Alexei Starovoitov wrote: > > > > > Assuming that is addressed. How do we merge the series? > > > The first 3 patches have serious conflicts with bpf trees. > > > > > > Maybe send the first 3 with extra selftest for above recursion > > > targeting bpf-next then we can have a merge commit that Steven can pull > > > into tracing? > > > > Would it be possible to do this by basing it off of one of Linus's tags, > > and doing the merge and conflict resolution in your tree before it gets to > > Linus? > > > > That way we can pull in that clean branch without having to pull in > > anything else from BPF. I believe Linus prefers this over having tracing > > having extra changes from BPF that are not yet in his tree. We only need > > these particular changes, we shouldn't be pulling in anything specific for > > BPF, as I believe that will cause issues on Linus's side. > > We can try, but I suspect git tricks won't do it. > Masami's changes depend on patches for kernel/bpf/btf.c that > are already in bpf-next, so git would have to follow all commits > that touch this file. This point is strange. I'm working on probe/fixes which is based on v6.5-rc3, so any bpf-next change should not be involved. Can you recheck this point? > I don't think git is smart enough to > thread the needle and split the commit into files. If one commit touches > btf.c and something else that whole commit becomes a dependency > that pulls another commit with all files touched by > the previous commit and so on. As far as I understand Steve's method, we will have an intermediate branch on bpf or probe tree, like linus(some common commit) ---- probes/btf-find-api and merge it to both bpf-next and probes/for-next branch +----------------------bpf-next --- (merge bpf patches) / / merge common -/\ probes/btf-find-api -/-\ \ \ merge +----------------------probes/for-next --- (merge probe patches) Thus, we can merge both for-next branches at next merge window without any issue. (But, yes, this is not simple, and needs maxium care) Thank you, > tbh for this set, the easiest for everyone, is to land the whole thing > through bpf-next, since there are no conflicts on fprobe side. -- Masami Hiramatsu (Google)