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=-0.7 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 70D3CC432C0 for ; Mon, 18 Nov 2019 10:04:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 46AF420748 for ; Mon, 18 Nov 2019 10:04:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="A6oNDUKA" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726705AbfKRKEG (ORCPT ); Mon, 18 Nov 2019 05:04:06 -0500 Received: from mail-qk1-f194.google.com ([209.85.222.194]:36887 "EHLO mail-qk1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726631AbfKRKEG (ORCPT ); Mon, 18 Nov 2019 05:04:06 -0500 Received: by mail-qk1-f194.google.com with SMTP id e187so13858800qkf.4; Mon, 18 Nov 2019 02:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NtQxqImxwG5Gkl+gjb24/9kDbX1IEiB4sD+MZB0qlbE=; b=A6oNDUKAaZvb7J2KaX5xkUzbp8hi+5ElRFsjcJcbpIPei8N2XDDstF1hlxOlEKIop7 MVXfBa6wBhVlEdojLdFLEecNfgeVReA0LUFAYd9OCKTkwHjOVjOkzamI6djwnNO67EnW xMS4LGASwj3ufpjtssoJSfv9DWmV3b8kKjjE91MRGOloo8/hFMRoRdnd81WpGTcODA83 y3NWugqBxmLA0U4CnYXelWloDci0o0v83l4IrgXHyHlqq1qX0iEf3op5ZmtQ/FW0kqMN IzGbLtvY7VFfb+ujAQq4VVhCBgSc1RI+snrq03QpZWNxpmum9Cvs6/Q5OYbLOMpD9nsG udWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NtQxqImxwG5Gkl+gjb24/9kDbX1IEiB4sD+MZB0qlbE=; b=YhXZSjI8R121nQ58mWvxcmIzrIgF4gjiZkAlhfuo3m4OJQHO2Nns2Z5fm8VRPOYvPL SDBHQPOLLoSxP8HXx9Phoiucaus+FFk5Y17kj1JgFhifTfZFJREhsPvzoUnD0qcxI9Wj NIrxJQItVqR4e8N0EB36wGy6ZzEapDsFp+yTFreuh72lynsjpPRVqzibIaR4f/cRmTOP 7cEtuxAdbSRe/TrP7DxXktvFRN0dzFZgT1jq1/0UxQ4HORRphifxCfpqVUDhSqQgnpmc DcQLekdHO1Mt3GGnNOaX4U807zYr0l4NnQLFB89Csosj0EvfZDaSbKVKplm5yKI0RIKs gp8A== X-Gm-Message-State: APjAAAXC1naAEzrzS66PXB/N5tA602fo8oqj+ogQ7a99PGyTYAw4lT1a we9dwBQypBp0yeKCqS+J/tXa07sFHQbp1hRC55U= X-Google-Smtp-Source: APXvYqyCRqNj9Wg2A7hGA2r+8YzHH97iI4ICE5MVxqlFb0NQjBUMcZsIsIVKxFwPAeszu6yUWctrv0UEPvM7hYyZOcY= X-Received: by 2002:a37:c44c:: with SMTP id h12mr23379421qkm.218.1574071444584; Mon, 18 Nov 2019 02:04:04 -0800 (PST) MIME-Version: 1.0 References: <20191113204737.31623-1-bjorn.topel@gmail.com> <20191113204737.31623-3-bjorn.topel@gmail.com> <20191115003024.h7eg2kbve23jmzqn@ast-mbp.dhcp.thefacebook.com> <20191115215832.6d3npfegpp5vhq6u@ast-mbp.dhcp.thefacebook.com> In-Reply-To: <20191115215832.6d3npfegpp5vhq6u@ast-mbp.dhcp.thefacebook.com> From: =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= Date: Mon, 18 Nov 2019 11:03:53 +0100 Message-ID: Subject: Re: [RFC PATCH bpf-next 2/4] bpf: introduce BPF dispatcher To: Alexei Starovoitov Cc: Netdev , Alexei Starovoitov , Daniel Borkmann , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , bpf , Magnus Karlsson , "Karlsson, Magnus" , Jonathan Lemon , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Edward Cree Content-Type: text/plain; charset="UTF-8" Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Fri, 15 Nov 2019 at 22:58, Alexei Starovoitov wrote: > [...] > > Another thought; I'm using the fentry nop as patch point, so it wont > > play nice with other users of fentry atm -- but the plan is to move to > > Steve's *_ftrace_direct work at some point, correct? > > Yes. I'll start playing with reg/mod/unreg_ftrace_direct on Monday. > Steven has a bunch more in his tree for merging, so I cannot just pull > all of ftrace api features into bpf-next. So "be nice to other fentry users" > would have to be done during merge window or shortly after in bpf-next tree > after window closes. I think it's fine. Yup, I agree. > In bpf dispatch case it's really > one dummy function we're talking about. If it was marked 'notrace' > from get go no one would blink. It's a dummy function not interesting > for ftrac-ing and not interesting from live patching pov. > ...but marking it with 'notrace' would remove the __fentry__ nop. Anyways, the "be nice" approach is OK.