Merge branch 'centralize-netdevice-mtu-bounds-checking'
authorDavid S. Miller <davem@davemloft.net>
Thu, 13 Oct 2016 13:36:58 +0000 (09:36 -0400)
committerDavid S. Miller <davem@davemloft.net>
Thu, 13 Oct 2016 13:36:58 +0000 (09:36 -0400)
commit0f505b1ae6794242240e40f7904c8b345fa38c41
treed5c763c23ce3faa611fa00b386f9a095ad364315
parent1b830996c1603225a96e233c3b09bf2b12607d78
parenta52ad514fdf3b8a57ca4322c92d2d8d5c6182485
Merge branch 'centralize-netdevice-mtu-bounds-checking'

Jarod Wilson says:

====================
net: centralize net_device MTU bounds checking

While looking into an MTU issue with sfc, I started noticing that almost
every NIC driver with an ndo_change_mtu function implemented almost
exactly the same range checks, and in many cases, that was the only
practical thing their ndo_change_mtu function was doing. Quite a few
drivers have either 68, 64, 60 or 46 as their minimum MTU value checked,
and then various sizes from 1500 to 65535 for their maximum MTU value. We
can remove a whole lot of redundant code here if we simple store min_mtu
and max_mtu in net_device, and check against those in net/core/dev.c's
dev_set_mtu().

This pair of patches looks to introduce centralized MTU range checking
infrastructure, while maintaining compatibility with all existing drivers,
and start to make use of it, converting all eth_change_mtu/ether_setup users
over to this new infra.

Assuming these pass review muster, I've got a ton of follow-on patches to
clean up MTU settings for everything in the kernel with an ndo_change_mtu.

This work is all staged in a (rebasing) git tree here:

https://github.com/jarodwilson/linux-muck

The master branch is based on net-next from Oct 7, and carries these two
patches, plus a ton of follow-on patches to eliminate MTU range checks
and change_mtu functions where possible. All patches were successfully
built across 160 various arch and config combos by the 0-day folks.
(Thanks to Andrew Lunn for the suggestion to get that going).
====================

Signed-off-by: David S. Miller <davem@davemloft.net>