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  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:   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

Powered by blists - more mailing lists