linux-kernel - Re: [PATCH net-next v8 3/5] net: dsa: add out-of-band tagging protocol

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 7 Nov 2022 11:27:37 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     Maxime Chevallier <maxime.chevallier@...tlin.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "thomas.petazzoni@...tlin.com" <thomas.petazzoni@...tlin.com>,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Luka Perkov <luka.perkov@...tura.hr>,
        Robert Marko <robert.marko@...tura.hr>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>
Subject: Re: [PATCH net-next v8 3/5] net: dsa: add out-of-band tagging
 protocol

Hi Jakub,

On Fri, Nov 04, 2022 at 08:05:30PM -0700, Jakub Kicinski wrote:
> On Fri,  4 Nov 2022 18:41:49 +0100 Maxime Chevallier wrote:
> > Add a new tagging protocol based on SKB extensions to convey the
> > information about the destination port to the MAC driver
>
> This is what METADATA_HW_PORT_MUX is for, you shouldn't have
> to allocate a piece of memory for every single packet.

Since this is the model that skb extensions propose and not something
that Maxime invented for this series, I presume that's not such a big
deal? What's more, couldn't this specific limitation of skb extensions
be addressed in a punctual way, via one-time calls to __skb_ext_alloc()
and fast path calls to __skb_ext_set()?

I'm unfamiliar to the concept of destination cache entries and even more
so to the concept of struct dst_entry * carrying metadata. I suppose the
latter were introduced for lack of space in struct sk_buff, to carry
metadata between layers that aren't L3/L4 (where normal dst_entry structs
are used)? What makes metadata dst's preferable to skb extensions?
The latter are more general; AFAIK they can be used between any layer
and any other layer, like for example between RX and TX in the
forwarding path. Side note, I am not exactly clear what are the lifetime
guarantees of a metadata dst entry, and if DSA's use would be 100% safe
(DSA is kind of L3, since it has an ETH_P_XDSA packet_type handler, not
an rx_handler).

More importantly, what happens if a DSA switch is used together with a
SRIOV-capable DSA master which already uses METADATA_HW_PORT_MUX for
PF-VF communication? (if I understood the commit message of 3fcece12bc1b
("net: store port/representator id in metadata_dst") correctly)