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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <PH7PR21MB31162E14795F1FD030C1C2A7CA809@PH7PR21MB3116.namprd21.prod.outlook.com>
Date:   Mon, 20 Mar 2023 15:13:45 +0000
From:   Haiyang Zhang <haiyangz@...rosoft.com>
To:     Francois Romieu <romieu@...zoreil.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



> -----Original Message-----
> From: Francois Romieu <romieu@...zoreil.com>
> Sent: Monday, March 20, 2023 7:33 AM
> To: Haiyang Zhang <haiyangz@...rosoft.com>
> Cc: linux-hyperv@...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; vkuznets@...hat.com;
> davem@...emloft.net; wei.liu@...nel.org; edumazet@...gle.com;
> kuba@...nel.org; pabeni@...hat.com; leon@...nel.org; Long Li
> <longli@...rosoft.com>; ssengar@...ux.microsoft.com; linux-
> kernel@...r.kernel.org
> Subject: Re: [PATCH net-next] net: mana: Add support for jumbo frame
> 
> [You don't often get email from romieu@...zoreil.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> 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.

Thanks for the idea -- I will look into that. But the real world implementation may
be less than ideal :)

- Haiyang