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=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 4CEB0C43381 for ; Fri, 22 Feb 2019 10:13:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 25AA720823 for ; Fri, 22 Feb 2019 10:13:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726757AbfBVKNx convert rfc822-to-8bit (ORCPT ); Fri, 22 Feb 2019 05:13:53 -0500 Received: from mail-ed1-f66.google.com ([209.85.208.66]:43276 "EHLO mail-ed1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726154AbfBVKNx (ORCPT ); Fri, 22 Feb 2019 05:13:53 -0500 Received: by mail-ed1-f66.google.com with SMTP id m35so1289227ede.10 for ; Fri, 22 Feb 2019 02:13:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=HK/w8KbsLQuqJc1ej5SdCl7fRAxy6XqzxzhpjYpPLGw=; b=OCCFk6OQD3N155UQdSfwKgeQUGbWEA9CfFEb4mT2hIkI44Fk11q4PqA5zZG63qzzty A4QbHtpmhYonLvzggluVQI3E7JdYK87M8EizSV1YkPvlwm15S5A8IE09KaHJMGxfdheV keBJRov9MPbKl3e1Yb/eU2CF3mhtUPrqNhh8mlrKuaz+T+fL5eKessh+CasaXLSaPb9/ pLZyOL0BeFv03qWwvvRw5iGs8ErqFgIPl85QMfBcbRvFXJ3nKpjJx9XRwOjidnk8/sRy utSe3LLI7ly0bEy1gb6tTdUOV8y11P1pIpHx3f7n9ajCLu49m0yIig/+jg/Xg1KbqG99 QBvw== X-Gm-Message-State: AHQUAuaa1VCyiEw9eCeoBOi0s4QvpJ/04ZeSJipcnrm26jqditblSKpH by2Mlaoo5EbtEOekGZ9A+moOSw== X-Google-Smtp-Source: AHgI3IaroWmNUl2mFNxH44/nsOFmUpIA0pirRymUAVlgnk4v3bqTndMy5SJEvkVgyelBBEzcKzqtBQ== X-Received: by 2002:a17:906:f102:: with SMTP id gv2mr2328939ejb.87.1550830431398; Fri, 22 Feb 2019 02:13:51 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id i46sm280565ede.62.2019.02.22.02.13.50 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 22 Feb 2019 02:13:50 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 3788D1803B8; Fri, 22 Feb 2019 11:13:50 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Jakub Kicinski Cc: David Miller , netdev@vger.kernel.org, Jesper Dangaard Brouer , Daniel Borkmann , Alexei Starovoitov Subject: Re: [PATCH net-next 1/2] xdp: Always use a devmap for XDP_REDIRECT to a device In-Reply-To: <20190221163627.7b8aa2ce@cakuba.netronome.com> References: <155075021399.13610.12521373406832889226.stgit@alrua-x1> <20190221163627.7b8aa2ce@cakuba.netronome.com> X-Clacks-Overhead: GNU Terry Pratchett Date: Fri, 22 Feb 2019 11:13:50 +0100 Message-ID: <87va1cgmg1.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Jakub Kicinski writes: > On Thu, 21 Feb 2019 12:56:54 +0100, Toke Høiland-Jørgensen wrote: >> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c >> index b63bc77af2d1..629661db36ee 100644 >> --- a/kernel/bpf/verifier.c >> +++ b/kernel/bpf/verifier.c >> @@ -7527,6 +7527,12 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env) >> prog->dst_needed = 1; >> if (insn->imm == BPF_FUNC_get_prandom_u32) >> bpf_user_rnd_init_once(); >> + if (insn->imm == BPF_FUNC_redirect) { >> + int err = dev_map_alloc_default_map(); >> + >> + if (err) >> + return err; >> + } >> if (insn->imm == BPF_FUNC_override_return) >> prog->kprobe_override = 1; >> if (insn->imm == BPF_FUNC_tail_call) { > >> +int dev_map_alloc_default_map(void) >> +{ >> + struct net *net = current->nsproxy->net_ns; >> + struct bpf_dtab *dtab, *old_dtab; >> + struct net_device *netdev; >> + union bpf_attr attr = {}; >> + u32 idx; >> + int err; > > BPF programs don't obey by netns boundaries. The fact the program is > verified in one ns doesn't mean this is the only ns it will be used in :( > Meaning if any program is using the redirect map you may need a secret > map in every ns.. no? Ah, yes, good point. Totally didn't think about the fact that load and attach are decoupled. Hmm, guess I'll just have to move the call to alloc_default_map() to the point where the program is attached to an interface, then... I trust it's safe to skip the allocation in case the program is offloaded to hardware, right? I.e., an offloaded program will never need to fall back to the kernel helper? -Toke