netdev - Re: [PATCH net-next 1/3] nfp: free buffers before changing MTU

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: <20160104.224604.57284296950465229.davem@davemloft.net>
Date:	Mon, 04 Jan 2016 22:46:04 -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: [PATCH net-next 1/3] nfp: free buffers before changing MTU

From: Jakub Kicinski <jakub.kicinski@...ronome.com>
Date: Mon,  4 Jan 2016 16:03:13 +0000

> For freeing DMA buffers we depend on nfp_net.fl_bufsz having the same
> value as during allocation therefore in .ndo_change_mtu we must first
> free the buffers and then change the setting.
> 
> Signed-off-by: Jakub Kicinski <jakub.kicinski@...ronome.com>
> Reviewed-by: Rolf Neugebauer <rolf.neugebauer@...ronome.com>

The behavior implemented by this patch is not acceptable.

If an error occurs reopenning the device after the MTU
change, the user is left with an inoperable interface and
zero feedback about what happened or why.

You MUST, therefore, specifically try to allocate the new memory and
resources that correspond to the new MTU value.

And if you can successfully allocate everything and be guarateed to
succeed, only then can you change the MTU and commit to the new
resources.

Otherwise you must leave the interface in exactly the state it was
in prior to the MTU change call and return an error to the caller.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html