From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 66D753D565B for ; Tue, 23 Jun 2026 12:00:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782216054; cv=none; b=IIdECpV9V0jVX50IA176gIMuOFc6WkYXGtiYyQYIC5zG3FNH+Z3W53jW9kAxKMQeoUgQS+zCmELWfXzRvjwYXmZ19FWN2EOFTRdhlUNXLjbV+9B34mcQbHz4rgj/opNKBVvueZx08Gsq3JZGLNx83C8dD0QHRwReYcdubpB5tfY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782216054; c=relaxed/simple; bh=fD1ssBHumg0Z/KRB6UvyA2t+hWd2u9qcEbBZhmVSYkE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Muz0pLTN6n15q8yveEwH4yp6ZGmOat65jhW27AJhKqBGYOg7eGHhs7A0VijJsQEi45AZ/Rv38t2LVxXYMhN63RgdT68L86Lp1WXLBsCYYYACLrqLzGeUBIMBn4ymF1Gih/4nOmkVTF1ntqIoB/UsJvp3tLtaoZrF5RXddBjU0ik= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=ayvHpjuE; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=U749GNPO; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ayvHpjuE"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="U749GNPO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782216052; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fD1ssBHumg0Z/KRB6UvyA2t+hWd2u9qcEbBZhmVSYkE=; b=ayvHpjuEFjS66epcV8p19GBUfLvXttFhQ0yUORosMQ6cY9bmEFeuY7ll6ZZcDky7EhUlTJ d/egR28VYZhUTVR2aDBJIfm8/bN3Mjapn/6+tBtoaRx0UnGrYsX5WNd8+oTuIqRa/+lvub 7CXL6eXV0wGGpMY3vY4KiU7tQkOXqY8= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-472-JzjZ6-OZPq2ZUfB_5iDoFw-1; Tue, 23 Jun 2026 08:00:48 -0400 X-MC-Unique: JzjZ6-OZPq2ZUfB_5iDoFw-1 X-Mimecast-MFC-AGG-ID: JzjZ6-OZPq2ZUfB_5iDoFw_1782216047 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-490c56e2576so41346905e9.3 for ; Tue, 23 Jun 2026 05:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1782216047; x=1782820847; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=fD1ssBHumg0Z/KRB6UvyA2t+hWd2u9qcEbBZhmVSYkE=; b=U749GNPO8r9ksYT1kb/ncRpccrFpkp586Cn5/IDk9Ev/nivI8s72aAiuQuPDVO+OlX 3k2IrEVHyVNwfvEJt2ZjSdF/AbQE4NjfqL98FEJHBkXfWgQpYkXG+6x139sQ7VjczLW3 6gtltwVbG+6zno67XiVNAbRXJWAuEbCrc9EwffzmOABTktf7DGlteaM3moyJqGDumWkm EEwqapqcsAQ6LXv2ymdVd3hm6hVl5EftJI6693EbDqhzNU5i2WiffNtgYX3q2ElJcQh6 4tVQqlcNX/QU/qEsfVTKqNRKZAWsbPSj7dLcoiHydXY/YhbJG/hHjFdaSj2PAZ1k2UMz zrEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782216047; x=1782820847; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=fD1ssBHumg0Z/KRB6UvyA2t+hWd2u9qcEbBZhmVSYkE=; b=IFazldI/rDIPIuWOz6f+dEemlkVfUD+JpPSlsgxkh+vBoRqUUclHXTkcCrlPuL5Szw qabh9s8iJWo6CA+HvTZQkDD8B1vcLWobrNj/z4COlF8IrXiD5jB4a7UKqsCEirYdRw8u hwCOpEKz8/y/aey0jlE7tOIYkEQKTAvYym+IxkxBbAq/ZpXXdxabYxbcNd3ALxkvJi2B r38hLgXZUJQWLimtX/oU9XAaH4n1sqY0LLW/y5d34O5SGqbvqKWkehuEmd7Eidct2dcE YdvXA1VJud8oB/WLSjXPPA2g7Jx2CICuxgl43jnU7MHjd8LTeumiWhbhBEDjWuwtPeFB d4rA== X-Forwarded-Encrypted: i=1; AFNElJ+oeV7xKkjY5DG/BqZqErklY5b7aYlWIBnOm4Lk3XXOufqyo4b4EsCk1oQd7e/Ig3M5RMJp4gCIo5x/9CQ=@vger.kernel.org X-Gm-Message-State: AOJu0YyUVeiWPlQiXW7BrsBqB+q8qavkCQZ4+fMJdM12q/z1ijd1LWgB NGKAMRu/eK488TURnr1v7Bu7yis5fCYHMHx0KgZ610TiF2YQqy+uqLLJNUEME1K8iDu0Cfm3wmb 5cczYzY+zdETNzvzq50qEZiOQomMFc59llURMVwZ/ybOTuJqtdMAEQLtDC7JmxQcdoQ== X-Gm-Gg: AfdE7ckcXhv9UuOu0uGdXgjm7S4l/nN10PQv2L7jzmJ1GggSY4FoKjHq79JQCwMhq9H H4OycS/8OhLlRHxAjERwLeuPOk5YnGEPc3ardMN626BVGp1S9Vjxxydv+3w7elgQvjwuhQoMCcK y/sM2DOrztVIkf92iitE/M9KCDKfjaurYFVfhDGzrmYxygfULWVxhwzs3qo97sK+4hB3xzvt2Kx nWVkgGENHehRy0K1FUm/yaPyUNynoLwgk368Ug/uiKuHOZb4SkE4djqv8UOE8QxR6FZLNjua9XE fX+szr00pDJXGt+MJ13U5cCr+3noZMKKD1rk3naRJrrrX62UbRg58c7rG4Va5NcmE4mnHMz6DV4 MaRMo4bnh5pv1CvfJ/Led72vbz0OuzhNJo5s= X-Received: by 2002:a7b:cb56:0:b0:490:b65f:8b1 with SMTP id 5b1f17b1804b1-49240e22ed1mr202516305e9.5.1782216047213; Tue, 23 Jun 2026 05:00:47 -0700 (PDT) X-Received: by 2002:a7b:cb56:0:b0:490:b65f:8b1 with SMTP id 5b1f17b1804b1-49240e22ed1mr202515915e9.5.1782216046755; Tue, 23 Jun 2026 05:00:46 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([45.145.92.2]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4924944fb71sm273200945e9.14.2026.06.23.05.00.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jun 2026 05:00:45 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 5BC60808C88; Tue, 23 Jun 2026 14:00:44 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Avinash Duduskar , ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org Cc: eddyz87@gmail.com, memxor@gmail.com, martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev, jolsa@kernel.org, emil@etsalapatis.com, john.fastabend@gmail.com, sdf@fomichev.me, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, shuah@kernel.org, hawk@kernel.org, yatsenko@meta.com, leon.hwang@linux.dev, kpsingh@kernel.org, a.s.protopopov@gmail.com, ameryhung@gmail.com, rongtao@cestc.cn, eyal.birger@gmail.com, bpf@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, dsahern@kernel.org Subject: Re: [PATCH bpf-next v4 2/3] bpf: Add BPF_FIB_LOOKUP_VLAN_INPUT flag to bpf_fib_lookup() helper In-Reply-To: <20260623025147.1001664-3-avinash.duduskar@gmail.com> References: <20260623025147.1001664-1-avinash.duduskar@gmail.com> <20260623025147.1001664-3-avinash.duduskar@gmail.com> X-Clacks-Overhead: GNU Terry Pratchett Date: Tue, 23 Jun 2026 14:00:44 +0200 Message-ID: <874iiteaab.fsf@toke.dk> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Avinash Duduskar writes: > BPF_FIB_LOOKUP_VLAN resolves a VLAN egress. The reverse is also > useful: an XDP program receiving a VLAN-tagged frame on a physical > device wants the lookup to behave as if the packet had arrived on the > corresponding VLAN subinterface, so iif-based policy routing and VRF > table selection use the right ingress. > > Add BPF_FIB_LOOKUP_VLAN_INPUT. When set, params->h_vlan_proto and > params->h_vlan_TCI are read as an input VLAN tag and the matching VLAN > device of params->ifindex is resolved with __vlan_find_dev_deep_rcu(). > The device must be up and in the same network namespace as > params->ifindex (a VLAN device can be moved to another netns while > registered on its parent; receive would deliver into that other > namespace, which a lookup here cannot represent). If params->ifindex > is itself a VLAN device, its inner (QinQ) subinterface is matched. > For a bond or team, a tag on a port matches no device and returns > NOT_FWDED; pass the master's ifindex. > The lookup then runs with the resolved device as the ingress; > params->ifindex itself is not modified on the input side. When the > resolved device is enslaved to a VRF, both the full lookup (via the > l3mdev rule) and BPF_FIB_LOOKUP_DIRECT (via l3mdev_fib_table_rcu()) > select the VRF's table from the resolved ingress. That follows from > feeding the resolved device to the flow as the ingress > (fl4.flowi4_iif =3D dev->ifindex), which is what makes l3mdev resolve > the VRF master from the subinterface rather than from > params->ifindex. > > The two failure classes get different treatment on purpose. A > h_vlan_proto other than 802.1Q/802.1ad is API misuse and returns > -EINVAL, since it would otherwise reach the WARN in vlan_proto_idx() > with a program-controlled value. An unmatched VID, a device that is > down, or one in another namespace is a data outcome and returns > BPF_FIB_LKUP_RET_NOT_FWDED, matching the DIRECT path when > fib_get_table() finds no table and mirroring real ingress, where the > receive path drops such frames. A VID of 0 (a priority tag) is looked > up literally and normally fails the same way; receive instead > processes such frames untagged, so callers should not set the flag for > priority tags. Proceeding on the physical device for any of these > would be fail-open for the policy-routing cases above. > > The h_vlan fields share a union with tbid, so the flag cannot be > combined with BPF_FIB_LOOKUP_TBID. It describes ingress, so it also > cannot be combined with BPF_FIB_LOOKUP_OUTPUT. Both combinations > return -EINVAL; restricting now keeps a later relaxation backward > compatible. Combining with BPF_FIB_LOOKUP_VLAN is allowed: the tag is > consumed on the ingress side and the egress tag is written on > success. > > Under !CONFIG_VLAN_8021Q the __vlan_find_dev_deep_rcu() stub returns > NULL, so every lookup with the flag returns NOT_FWDED, which is > correct since no VLAN device can exist. > > Suggested-by: Toke H=C3=B8iland-J=C3=B8rgensen > Signed-off-by: Avinash Duduskar Reviewed-by: Toke H=C3=B8iland-J=C3=B8rgensen