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] [day] [month] [year] [list]

Message-Id: <20160107.165526.1258840836259244024.davem@davemloft.net>
Date:	Thu, 07 Jan 2016 16:55:26 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	jakub.kicinski@...ronome.com
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

From: Jakub Kicinski <jakub.kicinski@...ronome.com>
Date: Thu, 7 Jan 2016 21:50:11 +0000

> 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.

Then the best you can do is retry the FW configuration using the
original MTU, and if _that_ fails you must return and error as well as
emit a kernel log message because this is a failure that cannot be
recovered from and the user must be able to figure out what happened.