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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7797AC432BE for ; Thu, 2 Sep 2021 14:54:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4FE8A610CF for ; Thu, 2 Sep 2021 14:54:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231269AbhIBOzT (ORCPT ); Thu, 2 Sep 2021 10:55:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:45850 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229941AbhIBOzT (ORCPT ); Thu, 2 Sep 2021 10:55:19 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EE9EB6108B; Thu, 2 Sep 2021 14:54:19 +0000 (UTC) Date: Thu, 2 Sep 2021 10:54:13 -0400 From: Steven Rostedt To: Jiri Olsa Cc: Alexei Starovoitov , bpf , LKML , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Linus Torvalds Subject: Re: [PATCH 0/8] x86/ftrace: Add direct batch interface Message-ID: <20210902105158.3816e193@oasis.local.home> In-Reply-To: References: <20210831095017.412311-1-jolsa@kernel.org> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Wed, 1 Sep 2021 21:06:45 +0200 Jiri Olsa wrote: > On Wed, Sep 01, 2021 at 08:23:38AM -0700, Alexei Starovoitov wrote: > > Steven, > > > > Could you review and merge this set for this merge window, > > so we can process related bpf bits for the next cycle? > > actually I might have sent it out too early, there's still > bpf part review discussion that might end up in interface > change Regardless, it is way too late to apply this to the current merge window. I don't think Linus would appreciate me pulling in a complex patch set 4 days into the merge window, review it, and then push it to him without much faith that this wont cause any major issues in use cases we did not think about. Not to mention, I would have to drop everything I am responsible for to do that. I would never ask another maintainer to do such an irresponsible act. > > review would be great, but please hold on with the merge I just got back from an 8 day vacation, and my inbox is way out of hand, and I still need to put together the changes that have been in linux-next for some time, and get that to Linus. Hopefully I'll get to looking at this sometime next week. -- Steve