netdev - Re: dsa: sja1105: regression after patch: "net: dsa: configure the MTU for switch ports"

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, 21 Apr 2020 14:56:37 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Oleksij Rempel <o.rempel@...gutronix.de>
Cc:     mkl@...gutronix.de, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>, kernel@...gutronix.de,
        netdev <netdev@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        David Jander <david@...tonic.nl>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: dsa: sja1105: regression after patch: "net: dsa: configure the
 MTU for switch ports"

Hi Oleksij,

On Tue, 21 Apr 2020 at 14:33, Oleksij Rempel <o.rempel@...gutronix.de> wrote:
>
> Hi Vladimir,
>
> I have a regression after this patch:
> |commit bfcb813203e619a8960a819bf533ad2a108d8105
> |Author:     Vladimir Oltean <vladimir.oltean@....com>
> |
> |  net: dsa: configure the MTU for switch ports
>
> with following log:
> [    3.044065] sja1105 spi1.0: Probed switch chip: SJA1105Q
> [    3.071385] sja1105 spi1.0: Enabled switch tagging
> [    3.076484] sja1105 spi1.0: error -34 setting MTU on port 0
> [    3.082795] sja1105: probe of spi1.0 failed with error -34
>
> this is devicetree snippet for the port 0:
>         port@0 {
>                 reg = <0>;
>                 label = "usb";
>                 phy-handle = <&usbeth_phy>;
>                 phy-mode = "rmii";
>         };
>
>
> Is it know issue?
>
> Regards,
> Oleksij
> --
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

The code which is causing problems seems to be this one:

    mtu_limit = min_t(int, master->max_mtu, dev->max_mtu);
    old_master_mtu = master->mtu;
    new_master_mtu = largest_mtu + cpu_dp->tag_ops->overhead;
    if (new_master_mtu > mtu_limit)
        return -ERANGE;

called from

    rtnl_lock();
    ret = dsa_slave_change_mtu(slave_dev, ETH_DATA_LEN);
    rtnl_unlock();
    if (ret && ret != -EOPNOTSUPP) {
        dev_err(ds->dev, "error %d setting MTU on port %d\n",
            ret, port->index);
        goto out_free;
    }

Before this patch, it was silently failing, now it's preventing the
probing of the ports which I might agree with you is not better.
Andrew warned about this, and I guess that during probe, we should
warn but ignore any nonzero return code, not just EOPNOTSUPP. I'll
send a patch out shortly to correct this.

Out of curiosity, what DSA master port do you have? Does it not
support an MTU of 1504 bytes? Does MTU-sized traffic pass correctly
through your interface? (you can test with iperf3)

Thanks,
-Vladimir