Message ID | 20230914083716.57443-1-larysa.zaremba@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp449444vqi; Thu, 14 Sep 2023 08:59:15 -0700 (PDT) X-Google-Smtp-Source: AGHT+IETmKs8juUIR5IHluVYuisgBxzpnxbmM15zuRmsR3j+gEUdOQZhHE48YGMy/TbDm6Z6SzTa X-Received: by 2002:a05:6a21:18a:b0:13d:fff1:c672 with SMTP id le10-20020a056a21018a00b0013dfff1c672mr6913126pzb.4.1694707155107; Thu, 14 Sep 2023 08:59:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694707155; cv=none; d=google.com; s=arc-20160816; b=JeayFm2dnOgGgWJp6w0OWB5PFqYuWCjkurTou5L180NsJxkqeRUFFP3HyyaYMNKYMu pZ9c9iEKNhG8oAld1klseopS0L11VGlTY2edhcuBPL7tgMhGslwgAzprb6FSqbr4aM3I 1TxcD2cb9qlo6DnPcnRQG3ft12X4B/Hv3JKzQlS27nbI6bKatGDoj+ywC6nqMqUGBJWF O+n8R4PGsh7z8WG1KjGsal85fPCjr1GyZXoQ2BhvnLmmHwi6CRgkDLSJeOW4f7Znej7t ekYbSavP3SSXmk7wow+hKPRyFLAJROXxUYQ+Dl47NLatB3rE8rMDoWgN6NHEJpOlZY4X HrKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=7dOs4x4ZCznS6991OCiVYtuAhkMaC4adhUCLsqVzziI=; fh=UjUYFiAUMpLohWQrbqvO1sVPoyZ8ymlqCxG9NonrNNs=; b=oj9V3kiqjo0/z+0UluDXGR1XNHcChVNUln4n1HzYR9qa3GML5mjNixBf7VUIXTHYYU QLUE2gKHTX76Rvk4VB+VFCrKNLIPH8o4dsk2HGNtvU6LhmrwMUVeiBRkYJPPVNgefzu3 xXpIhbwG6hZl9sBPIBG3fJEVPdIws9uHOKKW47dXNknO6aDSyL1JuavtaHfmuOjvHyeV 26+TKlbtwzHojOMx94v7nppO+Awl/06G04fJCppKpOEofvc/zqlJL22LNz7FkZorMHDG CwdFtxqzqHM9Ms3QPLXgZsrC4fidJSIaj3oC463S4k4+b7FKT9pe0QWieBJInbi6Dtip alYA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=PxogW5Hc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id u20-20020a056a00125400b006901504b6a3si1888900pfi.153.2023.09.14.08.59.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Sep 2023 08:59:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=PxogW5Hc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 4918D827AFA3; Thu, 14 Sep 2023 01:43:51 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236483AbjINInn (ORCPT <rfc822;chrisfriedt@gmail.com> + 35 others); Thu, 14 Sep 2023 04:43:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41870 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236533AbjINIni (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 14 Sep 2023 04:43:38 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9AD4E1FD9; Thu, 14 Sep 2023 01:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694681010; x=1726217010; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=iYC62UtRoejh4gTBR8ZARtuwUYWBWuvoadPJmKvqBHc=; b=PxogW5Hcv9SkjIlLqT2+a8iVdqLSOenOA8AiHhTbVSxdzsc4nNnCnkM1 K3VFWCMxXkrn1JOYZDeWXkY3WajTwphvTAQ3p6qaRXgfbYR4Rl1w/ATvA 2u+4Br/PcsJK7UTVMxiuGAi3oZOq7qXG5N066/ioYgYDjXWjDn9oTP/kW YHy1peoC5GhdiXQWnYC0bpC2yfcJAkfwiVyErkd1qHptE8F+g+uxZLoP8 5wUiRGAEVMeI+isWkrJEcXIt4jf//ETsXZE8mOWQ+NV4OouslDGq0zK42 0Rb/8iROurR5Y3Ew1oImn4n364LCCAVJ95IGkIdioZLk9x3mtuovNMDYR Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="378815020" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="378815020" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Sep 2023 01:43:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="991315995" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="991315995" Received: from irvmail002.ir.intel.com ([10.43.11.120]) by fmsmga006.fm.intel.com with ESMTP; 14 Sep 2023 01:43:25 -0700 Received: from lincoln.igk.intel.com (lincoln.igk.intel.com [10.102.21.235]) by irvmail002.ir.intel.com (Postfix) with ESMTP id 83FA332CB0; Thu, 14 Sep 2023 09:43:24 +0100 (IST) From: Larysa Zaremba <larysa.zaremba@intel.com> To: bpf@vger.kernel.org Cc: Larysa Zaremba <larysa.zaremba@intel.com>, Alexei Starovoitov <ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>, Martin KaFai Lau <martin.lau@linux.dev>, Song Liu <song@kernel.org>, Yonghong Song <yonghong.song@linux.dev>, John Fastabend <john.fastabend@gmail.com>, KP Singh <kpsingh@kernel.org>, Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>, Jiri Olsa <jolsa@kernel.org>, linux-kernel@vger.kernel.org Subject: [PATCH bpf-next] bpf: Allow to use kfunc XDP hints and frags together Date: Thu, 14 Sep 2023 10:37:11 +0200 Message-ID: <20230914083716.57443-1-larysa.zaremba@intel.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Thu, 14 Sep 2023 01:43:51 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777029249807710412 X-GMAIL-MSGID: 1777029249807710412 |
Series |
[bpf-next] bpf: Allow to use kfunc XDP hints and frags together
|
|
Commit Message
Larysa Zaremba
Sept. 14, 2023, 8:37 a.m. UTC
There is no fundamental reason, why multi-buffer XDP and XDP kfunc RX hints
cannot coexist in a single program.
Allow those features to be used together by modifying the flags conditions.
Suggested-by: Stanislav Fomichev <sdf@google.com>
Link: https://lore.kernel.org/bpf/CAKH8qBuzgtJj=OKMdsxEkyML36VsAuZpcrsXcyqjdKXSJCBq=Q@mail.gmail.com/
Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
---
kernel/bpf/offload.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
Comments
On 09/14, Larysa Zaremba wrote: > There is no fundamental reason, why multi-buffer XDP and XDP kfunc RX hints > cannot coexist in a single program. > > Allow those features to be used together by modifying the flags conditions. > > Suggested-by: Stanislav Fomichev <sdf@google.com> > Link: https://lore.kernel.org/bpf/CAKH8qBuzgtJj=OKMdsxEkyML36VsAuZpcrsXcyqjdKXSJCBq=Q@mail.gmail.com/ > Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> > --- > kernel/bpf/offload.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/kernel/bpf/offload.c b/kernel/bpf/offload.c > index ee35f33a96d1..43aded96c79b 100644 > --- a/kernel/bpf/offload.c > +++ b/kernel/bpf/offload.c > @@ -232,7 +232,11 @@ int bpf_prog_dev_bound_init(struct bpf_prog *prog, union bpf_attr *attr) > attr->prog_type != BPF_PROG_TYPE_XDP) > return -EINVAL; > > - if (attr->prog_flags & ~BPF_F_XDP_DEV_BOUND_ONLY) > + if (attr->prog_flags & ~(BPF_F_XDP_DEV_BOUND_ONLY | BPF_F_XDP_HAS_FRAGS)) > + return -EINVAL; > + [..] > + if (attr->prog_flags & BPF_F_XDP_HAS_FRAGS && > + !(attr->prog_flags & BPF_F_XDP_DEV_BOUND_ONLY)) > return -EINVAL; Any reason we have 'attr->prog_flags & BPF_F_XDP_HAS_FRAGS' part here? Seems like doing '!(attr->prog_flags & BPF_F_XDP_DEV_BOUND_ONLY)' should be enough, right? We only want to bail out here when BPF_F_XDP_DEV_BOUND_ONLY is not set and we don't really care whether BPF_F_XDP_HAS_FRAGS is set or not at this point.
On Thu, Sep 14, 2023 at 10:37:11AM +0200, Larysa Zaremba wrote: > There is no fundamental reason, why multi-buffer XDP and XDP kfunc RX hints > cannot coexist in a single program. > > Allow those features to be used together by modifying the flags conditions. > > Suggested-by: Stanislav Fomichev <sdf@google.com> > Link: https://lore.kernel.org/bpf/CAKH8qBuzgtJj=OKMdsxEkyML36VsAuZpcrsXcyqjdKXSJCBq=Q@mail.gmail.com/ > Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Though it would be worth spelling out something in the commit msg about additional check you're adding (frags flag can't go without dev bound) > --- > kernel/bpf/offload.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/kernel/bpf/offload.c b/kernel/bpf/offload.c > index ee35f33a96d1..43aded96c79b 100644 > --- a/kernel/bpf/offload.c > +++ b/kernel/bpf/offload.c > @@ -232,7 +232,11 @@ int bpf_prog_dev_bound_init(struct bpf_prog *prog, union bpf_attr *attr) > attr->prog_type != BPF_PROG_TYPE_XDP) > return -EINVAL; > > - if (attr->prog_flags & ~BPF_F_XDP_DEV_BOUND_ONLY) > + if (attr->prog_flags & ~(BPF_F_XDP_DEV_BOUND_ONLY | BPF_F_XDP_HAS_FRAGS)) > + return -EINVAL; > + > + if (attr->prog_flags & BPF_F_XDP_HAS_FRAGS && > + !(attr->prog_flags & BPF_F_XDP_DEV_BOUND_ONLY)) > return -EINVAL; > > if (attr->prog_type == BPF_PROG_TYPE_SCHED_CLS && > -- > 2.41.0 > >
On Thu, Sep 14, 2023 at 09:29:57AM -0700, Stanislav Fomichev wrote: > On 09/14, Larysa Zaremba wrote: > > There is no fundamental reason, why multi-buffer XDP and XDP kfunc RX hints > > cannot coexist in a single program. > > > > Allow those features to be used together by modifying the flags conditions. > > > > Suggested-by: Stanislav Fomichev <sdf@google.com> > > Link: https://lore.kernel.org/bpf/CAKH8qBuzgtJj=OKMdsxEkyML36VsAuZpcrsXcyqjdKXSJCBq=Q@mail.gmail.com/ > > Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> > > --- > > kernel/bpf/offload.c | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/kernel/bpf/offload.c b/kernel/bpf/offload.c > > index ee35f33a96d1..43aded96c79b 100644 > > --- a/kernel/bpf/offload.c > > +++ b/kernel/bpf/offload.c > > @@ -232,7 +232,11 @@ int bpf_prog_dev_bound_init(struct bpf_prog *prog, union bpf_attr *attr) > > attr->prog_type != BPF_PROG_TYPE_XDP) > > return -EINVAL; > > > > - if (attr->prog_flags & ~BPF_F_XDP_DEV_BOUND_ONLY) > > + if (attr->prog_flags & ~(BPF_F_XDP_DEV_BOUND_ONLY | BPF_F_XDP_HAS_FRAGS)) > > + return -EINVAL; > > + > > [..] > > > + if (attr->prog_flags & BPF_F_XDP_HAS_FRAGS && > > + !(attr->prog_flags & BPF_F_XDP_DEV_BOUND_ONLY)) > > return -EINVAL; > > Any reason we have 'attr->prog_flags & BPF_F_XDP_HAS_FRAGS' part here? > Seems like doing '!(attr->prog_flags & BPF_F_XDP_DEV_BOUND_ONLY)' should > be enough, right? We only want to bail out here when BPF_F_XDP_DEV_BOUND_ONLY > is not set and we don't really care whether BPF_F_XDP_HAS_FRAGS is set > or not at this point. If !(attr->prog_flags & BPF_F_XDP_DEV_BOUND_ONLY) at this point, program could be requesting offload. Now I have thought about those conditions once more and they could be reduced to this: if (attr->prog_flags & ~(BPF_F_XDP_DEV_BOUND_ONLY) && attr->prog_flags != (BPF_F_XDP_DEV_BOUND_ONLY | BPF_F_XDP_HAS_FRAGS)) return -EINVAL; What do you think?
On Thu, Sep 14, 2023 at 06:38:15PM +0200, Maciej Fijalkowski wrote: > On Thu, Sep 14, 2023 at 10:37:11AM +0200, Larysa Zaremba wrote: > > There is no fundamental reason, why multi-buffer XDP and XDP kfunc RX hints > > cannot coexist in a single program. > > > > Allow those features to be used together by modifying the flags conditions. > > > > Suggested-by: Stanislav Fomichev <sdf@google.com> > > Link: https://lore.kernel.org/bpf/CAKH8qBuzgtJj=OKMdsxEkyML36VsAuZpcrsXcyqjdKXSJCBq=Q@mail.gmail.com/ > > Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> > > Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> > > Though it would be worth spelling out something in the commit msg about > additional check you're adding (frags flag can't go without dev bound) > Ok, I'll add to the commit message the below: Frags are allowed only if program is dev-bound-only, but not if it is requesting bpf offload. > > --- > > kernel/bpf/offload.c | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/kernel/bpf/offload.c b/kernel/bpf/offload.c > > index ee35f33a96d1..43aded96c79b 100644 > > --- a/kernel/bpf/offload.c > > +++ b/kernel/bpf/offload.c > > @@ -232,7 +232,11 @@ int bpf_prog_dev_bound_init(struct bpf_prog *prog, union bpf_attr *attr) > > attr->prog_type != BPF_PROG_TYPE_XDP) > > return -EINVAL; > > > > - if (attr->prog_flags & ~BPF_F_XDP_DEV_BOUND_ONLY) > > + if (attr->prog_flags & ~(BPF_F_XDP_DEV_BOUND_ONLY | BPF_F_XDP_HAS_FRAGS)) > > + return -EINVAL; > > + > > + if (attr->prog_flags & BPF_F_XDP_HAS_FRAGS && > > + !(attr->prog_flags & BPF_F_XDP_DEV_BOUND_ONLY)) > > return -EINVAL; > > > > if (attr->prog_type == BPF_PROG_TYPE_SCHED_CLS && > > -- > > 2.41.0 > > > >
On Thu, Sep 14, 2023 at 10:05:47AM -0700, Stanislav Fomichev wrote: > On Thu, Sep 14, 2023 at 9:55 AM Larysa Zaremba <larysa.zaremba@intel.com> wrote: > > > > On Thu, Sep 14, 2023 at 09:29:57AM -0700, Stanislav Fomichev wrote: > > > On 09/14, Larysa Zaremba wrote: > > > > There is no fundamental reason, why multi-buffer XDP and XDP kfunc RX hints > > > > cannot coexist in a single program. > > > > > > > > Allow those features to be used together by modifying the flags conditions. > > > > > > > > Suggested-by: Stanislav Fomichev <sdf@google.com> > > > > Link: https://lore.kernel.org/bpf/CAKH8qBuzgtJj=OKMdsxEkyML36VsAuZpcrsXcyqjdKXSJCBq=Q@mail.gmail.com/ > > > > Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> > > > > --- > > > > kernel/bpf/offload.c | 6 +++++- > > > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/kernel/bpf/offload.c b/kernel/bpf/offload.c > > > > index ee35f33a96d1..43aded96c79b 100644 > > > > --- a/kernel/bpf/offload.c > > > > +++ b/kernel/bpf/offload.c > > > > @@ -232,7 +232,11 @@ int bpf_prog_dev_bound_init(struct bpf_prog *prog, union bpf_attr *attr) > > > > attr->prog_type != BPF_PROG_TYPE_XDP) > > > > return -EINVAL; > > > > > > > > - if (attr->prog_flags & ~BPF_F_XDP_DEV_BOUND_ONLY) > > > > + if (attr->prog_flags & ~(BPF_F_XDP_DEV_BOUND_ONLY | BPF_F_XDP_HAS_FRAGS)) > > > > + return -EINVAL; > > > > + > > > > > > [..] > > > > > > > + if (attr->prog_flags & BPF_F_XDP_HAS_FRAGS && > > > > + !(attr->prog_flags & BPF_F_XDP_DEV_BOUND_ONLY)) > > > > return -EINVAL; > > > > > > Any reason we have 'attr->prog_flags & BPF_F_XDP_HAS_FRAGS' part here? > > > Seems like doing '!(attr->prog_flags & BPF_F_XDP_DEV_BOUND_ONLY)' should > > > be enough, right? We only want to bail out here when BPF_F_XDP_DEV_BOUND_ONLY > > > is not set and we don't really care whether BPF_F_XDP_HAS_FRAGS is set > > > or not at this point. > > > > If !(attr->prog_flags & BPF_F_XDP_DEV_BOUND_ONLY) at this point, program could > > be requesting offload. > > > > Now I have thought about those conditions once more and they could be reduced to > > this: > > > > if (attr->prog_flags & ~(BPF_F_XDP_DEV_BOUND_ONLY) && > > attr->prog_flags != (BPF_F_XDP_DEV_BOUND_ONLY | BPF_F_XDP_HAS_FRAGS)) > > return -EINVAL; > > > > What do you think? > > Ah, so this check is here to protect against the mbuf+offloaded > combination? (looking at that other thread with Maciej) > Let's keep your current way with two separate checks, but let's add > your "/* Frags are allowed only if program is dev-bound-only, but not > if it is requesting > bpf offload. */" as a comment to the second check? Ok, sound good to me.
On Thu, Sep 14, 2023 at 9:55 AM Larysa Zaremba <larysa.zaremba@intel.com> wrote: > > On Thu, Sep 14, 2023 at 09:29:57AM -0700, Stanislav Fomichev wrote: > > On 09/14, Larysa Zaremba wrote: > > > There is no fundamental reason, why multi-buffer XDP and XDP kfunc RX hints > > > cannot coexist in a single program. > > > > > > Allow those features to be used together by modifying the flags conditions. > > > > > > Suggested-by: Stanislav Fomichev <sdf@google.com> > > > Link: https://lore.kernel.org/bpf/CAKH8qBuzgtJj=OKMdsxEkyML36VsAuZpcrsXcyqjdKXSJCBq=Q@mail.gmail.com/ > > > Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> > > > --- > > > kernel/bpf/offload.c | 6 +++++- > > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > > > diff --git a/kernel/bpf/offload.c b/kernel/bpf/offload.c > > > index ee35f33a96d1..43aded96c79b 100644 > > > --- a/kernel/bpf/offload.c > > > +++ b/kernel/bpf/offload.c > > > @@ -232,7 +232,11 @@ int bpf_prog_dev_bound_init(struct bpf_prog *prog, union bpf_attr *attr) > > > attr->prog_type != BPF_PROG_TYPE_XDP) > > > return -EINVAL; > > > > > > - if (attr->prog_flags & ~BPF_F_XDP_DEV_BOUND_ONLY) > > > + if (attr->prog_flags & ~(BPF_F_XDP_DEV_BOUND_ONLY | BPF_F_XDP_HAS_FRAGS)) > > > + return -EINVAL; > > > + > > > > [..] > > > > > + if (attr->prog_flags & BPF_F_XDP_HAS_FRAGS && > > > + !(attr->prog_flags & BPF_F_XDP_DEV_BOUND_ONLY)) > > > return -EINVAL; > > > > Any reason we have 'attr->prog_flags & BPF_F_XDP_HAS_FRAGS' part here? > > Seems like doing '!(attr->prog_flags & BPF_F_XDP_DEV_BOUND_ONLY)' should > > be enough, right? We only want to bail out here when BPF_F_XDP_DEV_BOUND_ONLY > > is not set and we don't really care whether BPF_F_XDP_HAS_FRAGS is set > > or not at this point. > > If !(attr->prog_flags & BPF_F_XDP_DEV_BOUND_ONLY) at this point, program could > be requesting offload. > > Now I have thought about those conditions once more and they could be reduced to > this: > > if (attr->prog_flags & ~(BPF_F_XDP_DEV_BOUND_ONLY) && > attr->prog_flags != (BPF_F_XDP_DEV_BOUND_ONLY | BPF_F_XDP_HAS_FRAGS)) > return -EINVAL; > > What do you think? Ah, so this check is here to protect against the mbuf+offloaded combination? (looking at that other thread with Maciej) Let's keep your current way with two separate checks, but let's add your "/* Frags are allowed only if program is dev-bound-only, but not if it is requesting bpf offload. */" as a comment to the second check?
diff --git a/kernel/bpf/offload.c b/kernel/bpf/offload.c index ee35f33a96d1..43aded96c79b 100644 --- a/kernel/bpf/offload.c +++ b/kernel/bpf/offload.c @@ -232,7 +232,11 @@ int bpf_prog_dev_bound_init(struct bpf_prog *prog, union bpf_attr *attr) attr->prog_type != BPF_PROG_TYPE_XDP) return -EINVAL; - if (attr->prog_flags & ~BPF_F_XDP_DEV_BOUND_ONLY) + if (attr->prog_flags & ~(BPF_F_XDP_DEV_BOUND_ONLY | BPF_F_XDP_HAS_FRAGS)) + return -EINVAL; + + if (attr->prog_flags & BPF_F_XDP_HAS_FRAGS && + !(attr->prog_flags & BPF_F_XDP_DEV_BOUND_ONLY)) return -EINVAL; if (attr->prog_type == BPF_PROG_TYPE_SCHED_CLS &&