netdev - RE: [PATCH RFC 5/6] net: dsa: microchip: Update tag

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:   Tue, 11 Dec 2018 23:59:34 +0000
From:   <Tristram.Ha@...rochip.com>
To:     <pavel@....cz>
CC:     <f.fainelli@...il.com>, <andrew@...n.ch>,
        <UNGLinuxDriver@...rochip.com>, <netdev@...r.kernel.org>
Subject: RE: [PATCH RFC 5/6] net: dsa: microchip: Update tag_ksz.c to access
 switch driver

> I'd be careful about locking. Seems like dsa was designed with "tag
> format is static", and you want to change it dynamically...

I see there is now a new overhead parameter in the dsa_device_ops structure
and dev_set_mtu is called in master.c.  It does not prevent the tag size to
change dynamically though.  A bigger size can be used instead to make sure the
MAC controller can support it.

In practice I do not think it does anything meaningful.  Most MAC controllers
can transmit and receive more than 1518 bytes but still only advertise 1500
MTU.  It is only when they support jumbo frame the drivers allow increasing
the MTU.  In the case of Atmel MAC controller I only see the mtu size is 1502,
but there is nothing changed inside the driver.

I did find another bug in the Atmel MAC driver concerning this max_mtu
implementation.  It does not affect the DSA operation as the child devices
still have the cap of 1500 MTU, but the main device will have problem running
by itself when MTU is increased.