Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3810222ybt; Tue, 30 Jun 2020 11:40:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzSZf3813ad46KNUQaiSHePYjLFsz93//qBaMahdQ4sbjzjT923+V4EQzhRQDNuRcMLYqVx X-Received: by 2002:aa7:c80f:: with SMTP id a15mr23830402edt.299.1593542032555; Tue, 30 Jun 2020 11:33:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593542032; cv=none; d=google.com; s=arc-20160816; b=yWBt+7TDTFjoOSJlKqSvMtDASEFR3qIocLbIr5AOnrfnkvQArGAwJG1l4AFQdbdbDL YAN2UjHp9rFlpM53pWbVziFeUuVUQxtv+I1bBQdFyIsbn+1p+B4SIBQkXiZDU2F6Fgj3 E7Jn7yJu+7Dmt5C8djZGAYZENbX81uF7Pqo4njgGkfv6nt5YtM1ihSmPGYzGp8togQwT 5kKBDau82mRQgsCWQ9t2kLNyIivcdiuJXZgS+cMxVdHG53nDgYotKVx7tkNYpUbg2jgV V9+wfmWlSoR5Y6y9XdbtyC9PDXM8idSzW8uuCMQHRsBLrJfikP4QEa5F25+voSiwWGhT UYQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=YjTGvZoFn9Gr5f+ufVSqWbKLtKiqYnTgMSui3Jl24dg=; b=aFg32r65vCEuLrgrS+Am+4GDaYO+XvjzGgsk6ANWv9D1jgYCcQQlkCb4isgjfZFsa5 22dEWLwKA9o0/x0sOnVmX5HvyAlX1UTvNDWJ79W/WnmqQuUx57d+YvCJlGyeBYfVkBdh L8NlKIbX1ooPIsa0s+HLEghn2KotxkNtum9Nl0iPfcqcFwbmGOUpmY0hGQ/a9nfGbylh C5Z82h+U91qky0GZFCU8/VIgY5Q4v3zYZoZzSPtBh025lkorg++KETq1cB4mtqPtaMC2 JST5UiZIwMh8L09dypeQPPxEeSJwBXytX7PsQ7V0uavZmJMWIqSAlOk2wQNM9dojJU1H wfrA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=AbhmhW0F; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p7si2115971ejo.392.2020.06.30.11.33.29; Tue, 30 Jun 2020 11:33:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=AbhmhW0F; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388320AbgF3QrO (ORCPT + 99 others); Tue, 30 Jun 2020 12:47:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46670 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728022AbgF3QrN (ORCPT ); Tue, 30 Jun 2020 12:47:13 -0400 Received: from mail-pj1-x1043.google.com (mail-pj1-x1043.google.com [IPv6:2607:f8b0:4864:20::1043]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6BD14C061755; Tue, 30 Jun 2020 09:47:13 -0700 (PDT) Received: by mail-pj1-x1043.google.com with SMTP id gc9so3216489pjb.2; Tue, 30 Jun 2020 09:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=YjTGvZoFn9Gr5f+ufVSqWbKLtKiqYnTgMSui3Jl24dg=; b=AbhmhW0FcojEGsKBYgxR7fSDLdEmZIHxD1D6PsAJ6ezhxe6haZFOGdqcwtTOYqYnu8 csrp77Uvqm6t4IumS+BuU61yWOx70HoJ41gDFDYF8E+Zmw0AAoyfuQhgU/t+mqkKZsIC vVhikQmUhVtik11wConsSXBOGyvUYPNOP/lzTbpybyPyry4tdraGAavYhELPywTAotso bAuWqD0/PD0M7VqkuCWpV0b6jIHGoC8ycoC/G88LPswm8vS5xGaKsp6YW6Fv4PTcmLBe WgbbqA+Jb55/agSHibk0rBoYDaCC4wiEvlOCFxzERjIl3GcYz/WxmmMIO3ieSKgJnCvp Nx1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=YjTGvZoFn9Gr5f+ufVSqWbKLtKiqYnTgMSui3Jl24dg=; b=VYDyI/iOlySC8nb/Ebs0kCsCO3BI/4HOruzI/dB2IOQShqLeFJFimXHTMVNzYByP8a OjzbWOPaDVXdSAnEa+kM4BJ7fRtN1QoW3kFEYxX/iXOHB6H0nYuwVvgmkdgeSzq/0WaP ErhzFCSAfk6yYoMKeEKpVu57Z6HrPC7J3l8lE3rcUINKRGFSCPPk1urA2glYI1mbCeOW iX0h4dsfw9D5W+SM6AcLle3mp0wHrr4rw4a+Iov2l6IAUTakldGotMBKJaka+KfanRyV gtUiNNS0A/5emmkAzMSrLa5m9uqzZCbCiTO5457vmTz/NcClBHDNSHTU5HVdW6cgnKgq zziQ== X-Gm-Message-State: AOAM530RbEKR99D6xLB4HG2uvO+ZwwsbgrD8cTmNoSyn8pI7+unO7cYy Y29lsKTFN3MBH8POF0UCjmY= X-Received: by 2002:a17:90a:cc18:: with SMTP id b24mr23349815pju.89.1593535632810; Tue, 30 Jun 2020 09:47:12 -0700 (PDT) Received: from ast-mbp.dhcp.thefacebook.com ([2620:10d:c090:400::5:e083]) by smtp.gmail.com with ESMTPSA id c188sm3203756pfc.143.2020.06.30.09.47.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jun 2020 09:47:11 -0700 (PDT) Date: Tue, 30 Jun 2020 09:47:08 -0700 From: Alexei Starovoitov To: Masahiro Yamada Cc: Michal Kubecek , Alexei Starovoitov , Linux Kbuild mailing list , bpf , Sam Ravnborg , Andrii Nakryiko , Daniel Borkmann , "David S. Miller" , Jakub Kicinski , John Fastabend , KP Singh , Martin KaFai Lau , Song Liu , Yonghong Song , Linux Kernel Mailing List , Networking Subject: Re: [PATCH 04/16] net: bpfilter: use 'userprogs' syntax to build bpfilter_umh Message-ID: <20200630164708.aeuoq4ruhivu5o2d@ast-mbp.dhcp.thefacebook.com> References: <20200423073929.127521-1-masahiroy@kernel.org> <20200423073929.127521-5-masahiroy@kernel.org> <20200608115628.osizkpo76cgn2ci7@lion.mk-sys.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 30, 2020 at 03:30:04PM +0900, Masahiro Yamada wrote: > Hi Michal, Alexei, > > On Mon, Jun 8, 2020 at 8:56 PM Michal Kubecek wrote: > > > > On Thu, Apr 23, 2020 at 04:39:17PM +0900, Masahiro Yamada wrote: > > > The user mode helper should be compiled for the same architecture as > > > the kernel. > > > > > > This Makefile reuses the 'hostprogs' syntax by overriding HOSTCC with CC. > > > > > > Now that Kbuild provides the syntax 'userprogs', use it to fix the > > > Makefile mess. > > > > > > Signed-off-by: Masahiro Yamada > > > Reported-by: kbuild test robot > > > --- > > > > > > net/bpfilter/Makefile | 11 ++++------- > > > 1 file changed, 4 insertions(+), 7 deletions(-) > > > > > > diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile > > > index 36580301da70..6ee650c6badb 100644 > > > --- a/net/bpfilter/Makefile > > > +++ b/net/bpfilter/Makefile > > > @@ -3,17 +3,14 @@ > > > # Makefile for the Linux BPFILTER layer. > > > # > > > > > > -hostprogs := bpfilter_umh > > > +userprogs := bpfilter_umh > > > bpfilter_umh-objs := main.o > > > -KBUILD_HOSTCFLAGS += -I $(srctree)/tools/include/ -I $(srctree)/tools/include/uapi > > > -HOSTCC := $(CC) > > > +user-ccflags += -I $(srctree)/tools/include/ -I $(srctree)/tools/include/uapi > > > > > > -ifeq ($(CONFIG_BPFILTER_UMH), y) > > > -# builtin bpfilter_umh should be compiled with -static > > > +# builtin bpfilter_umh should be linked with -static > > > # since rootfs isn't mounted at the time of __init > > > # function is called and do_execv won't find elf interpreter > > > -KBUILD_HOSTLDFLAGS += -static > > > -endif > > > +bpfilter_umh-ldflags += -static > > > > > > $(obj)/bpfilter_umh_blob.o: $(obj)/bpfilter_umh > > > > Hello, > > > > I just noticed that this patch (now in mainline as commit 8a2cc0505cc4) > > drops the test if CONFIG_BPFILTER_UMH is "y" so that -static is now > > passed to the linker even if bpfilter_umh is built as a module which > > wasn't the case in v5.7. > > > > This is not mentioned in the commit message and the comment still says > > "*builtin* bpfilter_umh should be linked with -static" so this change > > doesn't seem to be intentional. Did I miss something? > > > > Michal Kubecek > > I was away for a while from this because I saw long discussion in > "net/bpfilter: Remove this broken and apparently unmaintained" > > > Please let me resume this topic now. > > > The original behavior of linking umh was like this: > - If CONFIG_BPFILTER_UMH=y, bpfilter_umh was linked with -static > - If CONFIG_BPFILTER_UMH=m, bpfilter_umh was linked without -static That was done to make sure both static and dynamic linking work. For production -static is necessary. For debugging of usermode blob dynamic is beneficial. > Restoring the original behavior will add more complexity because > now we have CONFIG_CC_CAN_LINK and CONFIG_CC_CAN_LINK_STATIC > since commit b1183b6dca3e0d5 > > If CONFIG_BPFILTER_UMH=y, we need to check CONFIG_CC_CAN_LINK_STATIC. > If CONFIG_BPFILTER_UMH=m, we need to check CONFIG_CC_CAN_LINK. > This would make the Kconfig dependency logic too complicated. Currently I'm working on adding bpf_iter to use 'user mode driver' (old user mode blob) facility on top of Eric's patches. So there will be quite a bit more complexity to build system. Folks who don't want to deal with -static requirement should just disable the feature. > To make it simpler, I'd like to suggest two options. > > > > Idea 1: > > Always use -static irrespective of whether > CONFIG_BPFILTER_UMH is y or m. I don't think it's making it much simpler. It's a tiny change to makefile. I could be missing something. Requiring -static for =y and =m is fine. > Add two more lines to clarify this > in the comment in net/bpfilter/Makefile: > > # builtin bpfilter_umh should be linked with -static > # since rootfs isn't mounted at the time of __init > # function is called and do_execv won't find elf interpreter. > # Static linking is not required when bpfilter is modular, but > # we always pass -static to keep the 'depends on' in Kconfig simple. > > > > Idea 2: > > Allow umh to become only modular, > and drop -static flag entirely. absolutely not. Both =y and =m are mandatory. > > If you look at net/bpfilter/Kconfig, > BPFILTER_UMH already has 'default m'. > So, I assume the most expected use-case > is modular. The default for BPFILTER is =N. Distros should NOT be turning that to =y Same thing with upcoming bpf_iter. It will default to =n.