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, 07 Jan 2016 14:57:50 -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: Tue,  5 Jan 2016 11:57:27 +0000

> v2:
>  - add first patch (return error on fail).

You didn't read my feedback, so I'm not going to read your patches.

Is that OK with you?  I personally think it's fair.

I said that you need to reorganize how you do the MTU
changes.

You _MUST_ try to allocate the resources (queues, data
structures, whatever) for the new MTU size.

And if that fails, release those new resources and leave
the device exactly in the state it was in prior to the MTU
change call.

This means you can't use the close/open scheme, I'm explicitly
telling you not to use that mechanism to change the MTU because
it can leave the device inoperative if the re-open fails.

That is completely unexpected behavior for the user.

The interface must remain up and functioning at the original
MTU if the MTU change operation fails.  Your code does not
do this.

Yes, this is a lot of more work, but that's the only correct
way to implement this.

If you fail to implement this properly one more time I will start
simply ignoring your patch submissions for a while because you will be
completely wasting my time.

Thanks.