netdev - Re: [PATCHv2 net-next 0/4] MTU changes and other fixes

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:	Thu, 7 Jan 2016 21:50:11 +0000
From:	Jakub Kicinski <jakub.kicinski@...ronome.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, simon.horman@...ronome.com,
	rolf.neugebauer@...ronome.com
Subject: Re: [PATCHv2 net-next 0/4] MTU changes and other fixes

On Thu, 07 Jan 2016 16:33:14 -0500 (EST), David Miller wrote:
> From: Jakub Kicinski <jakub.kicinski@...ronome.com>
> Date: Thu, 7 Jan 2016 20:49:28 +0000
> 
> > I know this is not what you asked for but, since we are using FW
> > commands to disable/enable RX, even if we allocate all required
> > resources before freeing old ones we still cannot guarantee that
> > the reenabling operation will not fail.  Should we refuse to do
> > MTU changes while the interface is running altogether?
> 
> If you issue the MTU change command and it fails, then you're still
> configured at the old MTU.  There should therefore be no problem
> rewinding in that case.

No, no...  The FW command is to stop and start the RX path in
the NIC.  Our NIC is NPU-based, it has a ton of programmability
so even though we try to make it work like a run-of-the-mill
NIC there are some gotchas.

Unless there is a way to change MTU without stopping RX which
escapes me.

> > All drivers I've seen ...
> 
> Bad practice in other drivers should be ignored, not copied.

I'll take that to heart.