linux-kernel - Re: [PATCH 0/3] net: dsa: move skb reallocation to dsa_slave

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 16 Oct 2020 19:44:37 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Christian Eggers <ceggers@...i.de>, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Kurt Kanzenbach <kurt@...utronix.de>
Cc:     "David S . Miller" <davem@...emloft.net>,
        Woojung Huh <woojung.huh@...rochip.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] net: dsa: move skb reallocation to dsa_slave_xmit



On 10/16/2020 1:02 PM, Christian Eggers wrote:

[snip]

> On Friday, 16 October 2020, 20:03:11 CEST, Jakub Kicinski wrote:
>> FWIW if you want to avoid the reallocs you may want to set
>> needed_tailroom on the netdev.
> I haven't looked for this yet. If this can really solve the tagging AND
> padding problem, I would like to do this in a follow up patch.

The comment in netdevice.h says:

    *      @needed_headroom: Extra headroom the hardware may need, but 
not in all
    *                        cases can this be guaranteed
    *      @needed_tailroom: Extra tailroom the hardware may need, but 
not in all
    *                        cases can this be guaranteed. Some cases 
also use
    *                        LL_MAX_HEADER instead to allocate the skb

and while I have never seen a reallocation occur while pushing a 
descriptor status block in front of a frame on transmit after setting 
the correct needed_headroom, it was not exercised in a very complicated 
way either, just TCP or UDP over IPv4 or IPv6. This makes me think that 
the comment is cautionary about more complicated transmit scenarios with 
stacked devices, tunneling etc.

> 
> Wishing a nice weekend for netdev.

Likewise!
-- 
Florian