From: Sabrina Dubroca <sd@queasysnail.net>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Cosmin Ratiu <cratiu@nvidia.com>,
netdev@vger.kernel.org, Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Dragos Tatulea <dtatulea@nvidia.com>
Subject: Re: [PATCH net-next v2 3/3] macsec: Support VLAN-filtering lower devices
Date: Sat, 28 Feb 2026 12:27:03 +0100 [thread overview]
Message-ID: <aaLRB-KAUYbFVPao@krikkit> (raw)
In-Reply-To: <20260227065908.6dda892c@kernel.org>
2026-02-27, 06:59:08 -0800, Jakub Kicinski wrote:
> On Fri, 27 Feb 2026 11:02:27 +0200 Cosmin Ratiu wrote:
> > VLAN-filtering is done through two netdev features
> > (NETIF_F_HW_VLAN_CTAG_FILTER and NETIF_F_HW_VLAN_STAG_FILTER) and two
> > netdev ops (ndo_vlan_rx_add_vid and ndo_vlan_rx_kill_vid).
> >
> > Implement these and advertise the features if the lower device supports
> > them. This allows proper VLAN filtering to work on top of macsec
> > devices, when the lower device is capable of VLAN filtering.
> > As a concrete example, having this chain of interfaces now works:
> > vlan_filtering_capable_dev(1) -> macsec_dev(2) -> macsec_vlan_dev(3)
> >
> > Before commit [1] this used to accidentally work because the macsec
The first submission was for net-next, then Jakub asked to make this a
fix for net:
https://lore.kernel.org/netdev/20260106171027.57a7757f@kernel.org/
which makes sense.
So "v1"
https://lore.kernel.org/netdev/20260107104723.2750725-1-cratiu@nvidia.com
was for net, and we discussed making it a net-next patch because the
changes were looking invasive. But in the end by using
vlan_{get,drop}_rx_*_filter_info it's a pretty simple patch, so I
think this should still be for net?
[...]
> > @@ -2616,7 +2616,17 @@ static int macsec_update_offload(struct net_device *dev, enum macsec_offload off
> > if (!ops)
> > return -EOPNOTSUPP;
> >
> > + /* Remove VLAN filters when disabling offload. */
> > + if (offload == MACSEC_OFFLOAD_OFF) {
> > + vlan_drop_rx_ctag_filter_info(dev);
> > + vlan_drop_rx_stag_filter_info(dev);
> > + }
> > macsec->offload = offload;
> > + /* Add VLAN filters when enabling offload. */
> > + if (prev_offload == MACSEC_OFFLOAD_OFF) {
> > + vlan_get_rx_ctag_filter_info(dev);
> > + vlan_get_rx_stag_filter_info(dev);
> > + }
> >
> > ctx.secy = &macsec->secy;
> > ret = offload == MACSEC_OFFLOAD_OFF ? macsec_offload(ops->mdo_del_secy, &ctx)
> > @@ -2633,6 +2643,11 @@ static int macsec_update_offload(struct net_device *dev, enum macsec_offload off
> >
> > if (ret) {
> > macsec->offload = prev_offload;
> > + if (offload == MACSEC_OFFLOAD_OFF && prev_offload == MACSEC_OFFLOAD_MAC) {
> > + vlan_get_rx_ctag_filter_info(dev);
> > + vlan_get_rx_stag_filter_info(dev);
> > + }
> > +
> > return ret;
> > }
>
> Does the error path properly restore VLAN filter state when enabling offload
> fails? When prev_offload is MACSEC_OFFLOAD_OFF and the code calls
> vlan_get_rx_ctag_filter_info(dev) and vlan_get_rx_stag_filter_info(dev) to
> push VLAN filters to the lower device, but then macsec_offload() fails and
> returns an error:
[...]
Looks like it. Since the vlan_*_filter_info ops can't fail, just move
them until after we've called mdo_*_secy, and macsec_update_offload
can't fail anymore?
--
Sabrina
next prev parent reply other threads:[~2026-02-28 11:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-27 9:02 [PATCH net-next v2 0/3] macsec: Add support for VLAN filtering in offload mode Cosmin Ratiu
2026-02-27 9:02 ` [PATCH net-next v2 1/3] nsim: Add support for VLAN filters Cosmin Ratiu
2026-02-28 11:21 ` Sabrina Dubroca
2026-02-27 9:02 ` [PATCH net-next v2 2/3] selftests: Add macsec offload VLAN tests Cosmin Ratiu
2026-02-27 14:58 ` Jakub Kicinski
2026-03-06 15:01 ` Cosmin Ratiu
2026-03-06 20:04 ` Jakub Kicinski
2026-02-27 9:02 ` [PATCH net-next v2 3/3] macsec: Support VLAN-filtering lower devices Cosmin Ratiu
2026-02-27 14:59 ` Jakub Kicinski
2026-02-28 11:27 ` Sabrina Dubroca [this message]
2026-03-06 15:02 ` Cosmin Ratiu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aaLRB-KAUYbFVPao@krikkit \
--to=sd@queasysnail.net \
--cc=andrew+netdev@lunn.ch \
--cc=cratiu@nvidia.com \
--cc=davem@davemloft.net \
--cc=dtatulea@nvidia.com \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.