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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 451E0C43331 for ; Sat, 28 Mar 2020 02:16:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1DAB52073B for ; Sat, 28 Mar 2020 02:16:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726937AbgC1CQM (ORCPT ); Fri, 27 Mar 2020 22:16:12 -0400 Received: from www62.your-server.de ([213.133.104.62]:60710 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726225AbgC1CQM (ORCPT ); Fri, 27 Mar 2020 22:16:12 -0400 Received: from sslproxy03.your-server.de ([88.198.220.132]) by www62.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1jI115-0005hi-6Y; Sat, 28 Mar 2020 03:16:07 +0100 Received: from [178.195.186.98] (helo=pc-9.home) by sslproxy03.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jI114-00095U-V0; Sat, 28 Mar 2020 03:16:06 +0100 Subject: Re: [PATCH bpf-next 3/7] bpf: add netns cookie and enable it for bpf cgroup hooks To: Alexei Starovoitov Cc: m@lambda.lt, joe@wand.net.nz, bpf@vger.kernel.org, netdev@vger.kernel.org References: <20200328014844.xz5s67j2cyvnf7lp@ast-mbp> From: Daniel Borkmann Message-ID: <99b27ef9-d8c5-c00b-2562-1b385ac205d0@iogearbox.net> Date: Sat, 28 Mar 2020 03:16:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20200328014844.xz5s67j2cyvnf7lp@ast-mbp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.102.2/25764/Fri Mar 27 14:11:26 2020) Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On 3/28/20 2:48 AM, Alexei Starovoitov wrote: > On Fri, Mar 27, 2020 at 04:58:52PM +0100, Daniel Borkmann wrote: >> + * >> + * u64 bpf_get_netns_cookie(void *ctx) >> + * Description >> + * Retrieve the cookie (generated by the kernel) of the network >> + * namespace the input *ctx* is associated with. The network >> + * namespace cookie remains stable for its lifetime and provides >> + * a global identifier that can be assumed unique. If *ctx* is >> + * NULL, then the helper returns the cookie for the initial >> + * network namespace. The cookie itself is very similar to that >> + * of bpf_get_socket_cookie() helper, but for network namespaces >> + * instead of sockets. > > All new helpers in this patch and few others are missing 'flags' argument. > Yes. It's kinda hard right now to come up with a use case for the flags, > since all helpers look kinda trivial, simple, and single purpose. > But the same thing happened with bpf_send_signal(). It felt that there is no > way to extend it. Yet later we had to add bpf_send_signal_thread() which could > have been handled with flags if they were there. So please add flags to all new > helpers though it might seem redundant. We have very similar helpers for almost 2yrs now, that is, bpf_get_socket_cookie() and bpf_skb_ancestor_cgroup_id(). Both no extra 'unused flags' arg and they are simple enough to do exactly what we expect them to do, I also haven't seen any reason to extend them further so far (otherwise we have have new ones by now). The two added here are very much analogue to this, so breaking this consistency is super ugly just to add empty flags now. :/ Given the timeframe we have these by now and given they do one simple thing, what is the harm to add a new helper in future iff really needed rather than uglifying with flags now (I would understand it for complex helpers though where we use this practice)? Just recently we added bpf_jiffies64() (5576b991e9c1 ("bpf: Add BPF_FUNC_jiffies64")); no flag either and it has similar simplicity. Thanks, Daniel