linux-toradex.git/net/hsr, branch v4.12

hsr: fix incorrect warning

2017-06-12T19:21:20+00:00

When HSR interface is setup using ip link command, an annoying warning
appears with the trace as below:-

[  203.019828] hsr_get_node: Non-HSR frame
[  203.019833] Modules linked in:
[  203.019848] CPU: 0 PID: 158 Comm: sd-resolve Tainted: G        W       4.12.0-rc3-00052-g9fa6bf70 #2
[  203.019853] Hardware name: Generic DRA74X (Flattened Device Tree)
[  203.019869] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[  203.019880] [] (show_stack) from [] (dump_stack+0xac/0xe0)
[  203.019894] [] (dump_stack) from [] (__warn+0xd8/0x104)
[  203.019907] [] (__warn) from [] (warn_slowpath_fmt+0x34/0x44)
root@am57xx-evm:~# [  203.019921] [] (warn_slowpath_fmt) from [] (hsr_get_node+0x148/0x170)
[  203.019932] [] (hsr_get_node) from [] (hsr_forward_skb+0x110/0x7c0)
[  203.019942] [] (hsr_forward_skb) from [] (hsr_dev_xmit+0x2c/0x34)
[  203.019954] [] (hsr_dev_xmit) from [] (dev_hard_start_xmit+0xc4/0x3bc)
[  203.019963] [] (dev_hard_start_xmit) from [] (__dev_queue_xmit+0x7c4/0x98c)
[  203.019974] [] (__dev_queue_xmit) from [] (ip6_finish_output2+0x330/0xc1c)
[  203.019983] [] (ip6_finish_output2) from [] (ip6_output+0x58/0x454)
[  203.019994] [] (ip6_output) from [] (mld_sendpack+0x420/0x744)

As this is an expected path to hsr_get_node() with frame coming from
the master interface, add a check to ensure packet is not from the
master port and then warn.

Signed-off-by: Murali Karicheri 
Signed-off-by: David S. Miller

net: Fix inconsistent teardown and release of private netdev state.

2017-06-07T19:53:24+00:00

Network devices can allocate reasources and private memory using
netdev_ops->ndo_init().  However, the release of these resources
can occur in one of two different places.

Either netdev_ops->ndo_uninit() or netdev->destructor().

The decision of which operation frees the resources depends upon
whether it is necessary for all netdev refs to be released before it
is safe to perform the freeing.

netdev_ops->ndo_uninit() presumably can occur right after the
NETDEV_UNREGISTER notifier completes and the unicast and multicast
address lists are flushed.

netdev->destructor(), on the other hand, does not run until the
netdev references all go away.

Further complicating the situation is that netdev->destructor()
almost universally does also a free_netdev().

This creates a problem for the logic in register_netdevice().
Because all callers of register_netdevice() manage the freeing
of the netdev, and invoke free_netdev(dev) if register_netdevice()
fails.

If netdev_ops->ndo_init() succeeds, but something else fails inside
of register_netdevice(), it does call ndo_ops->ndo_uninit().  But
it is not able to invoke netdev->destructor().

This is because netdev->destructor() will do a free_netdev() and
then the caller of register_netdevice() will do the same.

However, this means that the resources that would normally be released
by netdev->destructor() will not be.

Over the years drivers have added local hacks to deal with this, by
invoking their destructor parts by hand when register_netdevice()
fails.

Many drivers do not try to deal with this, and instead we have leaks.

Let's close this hole by formalizing the distinction between what
private things need to be freed up by netdev->destructor() and whether
the driver needs unregister_netdevice() to perform the free_netdev().

netdev->priv_destructor() performs all actions to free up the private
resources that used to be freed by netdev->destructor(), except for
free_netdev().

netdev->needs_free_netdev is a boolean that indicates whether
free_netdev() should be done at the end of unregister_netdevice().

Now, register_netdevice() can sanely release all resources after
ndo_ops->ndo_init() succeeds, by invoking both ndo_ops->ndo_uninit()
and netdev->priv_destructor().

And at the end of unregister_netdevice(), we invoke
netdev->priv_destructor() and optionally call free_netdev().

Signed-off-by: David S. Miller

netlink: extended ACK reporting

2017-04-13T17:58:20+00:00

Add the base infrastructure and UAPI for netlink extended ACK
reporting. All "manual" calls to netlink_ack() pass NULL for now and
thus don't get extended ACK reporting.

Big thanks goes to Pablo Neira Ayuso for not only bringing up the
whole topic at netconf (again) but also coming up with the nlattr
passing trick and various other ideas.

Signed-off-by: Johannes Berg 
Reviewed-by: David Ahern 
Signed-off-by: David S. Miller

net/hsr: use eth_hw_addr_random()

2017-02-21T18:25:22+00:00

Use eth_hw_addr_random() to set a random MAC address in order to make sure
dev->addr_assign_type will be properly set to NET_ADDR_RANDOM.

Signed-off-by: Tobias Klauser 
Signed-off-by: David S. Miller

net-next: treewide use is_vlan_dev() helper function.

2017-02-06T21:33:29+00:00

This patch makes use of is_vlan_dev() function instead of flag
comparison which is exactly done by is_vlan_dev() helper function.

Signed-off-by: Parav Pandit 
Reviewed-by: Daniel Jurgens 
Acked-by: Stephen Hemminger 
Acked-by: Jon Maxwell 
Acked-by: Johannes Thumshirn 
Acked-by: Haiyang Zhang 
Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2016-10-30T16:42:58+00:00

Mostly simple overlapping changes.

For example, David Ahern's adjacency list revamp in 'net-next'
conflicted with an adjacency list traversal bug fix in 'net'.

Signed-off-by: David S. Miller

genetlink: mark families as __ro_after_init

2016-10-27T20:16:09+00:00

Now genl_register_family() is the only thing (other than the
users themselves, perhaps, but I didn't find any doing that)
writing to the family struct.

In all families that I found, genl_register_family() is only
called from __init functions (some indirectly, in which case
I've add __init annotations to clarifly things), so all can
actually be marked __ro_after_init.

This protects the data structure from accidental corruption.

Signed-off-by: Johannes Berg 
Signed-off-by: David S. Miller

genetlink: statically initialize families

2016-10-27T20:16:09+00:00

Instead of providing macros/inline functions to initialize
the families, make all users initialize them statically and
get rid of the macros.

This reduces the kernel code size by about 1.6k on x86-64
(with allyesconfig).

Signed-off-by: Johannes Berg 
Signed-off-by: David S. Miller

genetlink: no longer support using static family IDs

2016-10-27T20:16:09+00:00

Static family IDs have never really been used, the only
use case was the workaround I introduced for those users
that assumed their family ID was also their multicast
group ID.

Additionally, because static family IDs would never be
reserved by the generic netlink code, using a relatively
low ID would only work for built-in families that can be
registered immediately after generic netlink is started,
which is basically only the control family (apart from
the workaround code, which I also had to add code for so
it would reserve those IDs)

Thus, anything other than GENL_ID_GENERATE is flawed and
luckily not used except in the cases I mentioned. Move
those workarounds into a few lines of code, and then get
rid of GENL_ID_GENERATE entirely, making it more robust.

Signed-off-by: Johannes Berg 
Signed-off-by: David S. Miller

net: use core MTU range checking in misc drivers

2016-10-20T18:51:10+00:00

firewire-net:
- set min/max_mtu
- remove fwnet_change_mtu

nes:
- set max_mtu
- clean up nes_netdev_change_mtu

xpnet:
- set min/max_mtu
- remove xpnet_dev_change_mtu

hippi:
- set min/max_mtu
- remove hippi_change_mtu

batman-adv:
- set max_mtu
- remove batadv_interface_change_mtu
- initialization is a little async, not 100% certain that max_mtu is set
  in the optimal place, don't have hardware to test with

rionet:
- set min/max_mtu
- remove rionet_change_mtu

slip:
- set min/max_mtu
- streamline sl_change_mtu

um/net_kern:
- remove pointless ndo_change_mtu

hsi/clients/ssi_protocol:
- use core MTU range checking
- remove now redundant ssip_pn_set_mtu

ipoib:
- set a default max MTU value
- Note: ipoib's actual max MTU can vary, depending on if the device is in
  connected mode or not, so we'll just set the max_mtu value to the max
  possible, and let the ndo_change_mtu function continue to validate any new
  MTU change requests with checks for CM or not. Note that ipoib has no
  min_mtu set, and thus, the network core's mtu > 0 check is the only lower
  bounds here.

mptlan:
- use net core MTU range checking
- remove now redundant mpt_lan_change_mtu

fddi:
- min_mtu = 21, max_mtu = 4470
- remove now redundant fddi_change_mtu (including export)

fjes:
- min_mtu = 8192, max_mtu = 65536
- The max_mtu value is actually one over IP_MAX_MTU here, but the idea is to
  get past the core net MTU range checks so fjes_change_mtu can validate a
  new MTU against what it supports (see fjes_support_mtu in fjes_hw.c)

hsr:
- min_mtu = 0 (calls ether_setup, max_mtu is 1500)

f_phonet:
- min_mtu = 6, max_mtu = 65541

u_ether:
- min_mtu = 14, max_mtu = 15412

phonet/pep-gprs:
- min_mtu = 576, max_mtu = 65530
- remove redundant gprs_set_mtu

CC: netdev@vger.kernel.org
CC: linux-rdma@vger.kernel.org
CC: Stefan Richter 
CC: Faisal Latif 
CC: linux-rdma@vger.kernel.org
CC: Cliff Whickman 
CC: Robin Holt 
CC: Jes Sorensen 
CC: Marek Lindner 
CC: Simon Wunderlich 
CC: Antonio Quartulli 
CC: Sathya Prakash 
CC: Chaitra P B 
CC: Suganath Prabu Subramani 
CC: MPT-FusionLinux.pdl@broadcom.com
CC: Sebastian Reichel 
CC: Felipe Balbi 
CC: Arvid Brodin 
CC: Remi Denis-Courmont 
Signed-off-by: Jarod Wilson 
Signed-off-by: David S. Miller