linux-kernel - Re: [PATCH net-next] net: mana: Add support for jumbo frame

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:   Mon, 20 Mar 2023 12:33:17 +0100
From:   Francois Romieu <romieu@...zoreil.com>
To:     Haiyang Zhang <haiyangz@...rosoft.com>
Cc:     "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Dexuan Cui <decui@...rosoft.com>,
        KY Srinivasan <kys@...rosoft.com>,
        Paul Rosswurm <paulros@...rosoft.com>,
        "olaf@...fle.de" <olaf@...fle.de>,
        "vkuznets@...hat.com" <vkuznets@...hat.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "wei.liu@...nel.org" <wei.liu@...nel.org>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "leon@...nel.org" <leon@...nel.org>,
        Long Li <longli@...rosoft.com>,
        "ssengar@...ux.microsoft.com" <ssengar@...ux.microsoft.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next] net: mana: Add support for jumbo frame

Haiyang Zhang <haiyangz@...rosoft.com> :
> > From: Francois Romieu <romieu@...zoreil.com>
[...]
> > I do not see where the driver could depend on the MTU. Even if it fails,
> > a single call to mana_change_mtu should thus never wreck the old working
> > state/configuration.
> > 
> > Stated differently, the detach/attach implementation is simple but
> > it makes the driver less reliable than it could be.
> > 
> > No ?
> 
> No, it doesn't make the driver less reliable. To safely remove and reallocate 
> DMA buffers with different size, we have to stop the traffic. So, mana_detach() 
> is called. We also call mana_detach() in mana_close(). So the process in 
> mana_change_mtu() is no more risky than ifdown/ifup of the NIC. 
> 
> In some rare cases, if the system memory is running really low, the bigger 
> buffer allocation may fail, so we re-try with the previous MTU. I don't expect 
> it to fail again. But we still check & log the error code for completeness and 
> debugging.

In a ideal world, I would expect change_mtu() to allocate the new resources,
bail out if some allocation fails, stop the traffic, swap the old and new
resources, then restart the traffic and release the old resources.
This way the device is never left in a failed state.

-- 
Ueimor