netdev - Re: [PATCH v4] ravb: implement MTU change while device is up

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]

Message-ID: <CAMuHMdXZQpYwAU4DE-Odnm0=EZMUDJ+0WLJjeErbVZJ8PkC5Dg@mail.gmail.com>
Date:   Thu, 14 Nov 2019 11:26:31 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Ulrich Hecht <uli+renesas@...nd.eu>
Cc:     Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
        Niklas Söderlund <niklas.soderlund@...natech.se>,
        Wolfram Sang <wsa@...-dreams.de>,
        Simon Horman <horms@...ge.net.au>,
        Magnus Damm <magnus.damm@...il.com>
Subject: Re: [PATCH v4] ravb: implement MTU change while device is up

Hi Uli,

On Thu, Nov 14, 2019 at 2:50 AM Ulrich Hecht <uli+renesas@...nd.eu> wrote:
> Pre-allocates buffers sufficient for the maximum supported MTU (2026) in
> order to eliminate the possibility of resource exhaustion when changing the
> MTU while the device is up.
>
> Signed-off-by: Ulrich Hecht <uli+renesas@...nd.eu>

Thanks for your patch!

> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -293,9 +293,9 @@ static void ravb_ring_format(struct net_device *ndev, int q)
>         for (i = 0; i < priv->num_rx_ring[q]; i++) {
>                 /* RX descriptor */
>                 rx_desc = &priv->rx_ring[q][i];
> -               rx_desc->ds_cc = cpu_to_le16(priv->rx_buf_sz);
> +               rx_desc->ds_cc = cpu_to_le16(RX_BUF_SZ);

So the RAVB hardware will always see the full buffer size.
Hence if it receives a frame that is larger than the configured MTU, it will
still happily pass it to the driver, and to the network stack, which will
reject it, presumably?

Note that the driver doesn't seem to configure the Reception Truncation
Configuration register, so it will never reject frames up to 4092 bytes (unless
the boot loader has changed that).

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds