mirror of
https://github.com/joel16/android_kernel_sony_msm8994.git
synced 2024-11-29 07:01:10 +00:00
bd89efc532
The classical IP over ATM code maintains its own IPv4 <-> <ATM stuff> ARP table, using the standard neighbour-table code. The neigh_table_init function adds this neighbour table to a linked list of all neighbor tables which is used by the functions neigh_delete() neigh_add() and neightbl_set(), all called by the netlink code. Once the ATM neighbour table is added to the list, there are two tables with family == AF_INET there, and ARP entries sent via netlink go into the first table with matching family. This is indeterminate and often wrong. To see the bug, on a kernel with CLIP enabled, create a standard IPv4 ARP entry by pinging an unused address on a local subnet. Then attempt to complete that entry by doing ip neigh replace <ip address> lladdr <some mac address> nud reachable Looking at the ARP tables by using ip neigh show will reveal two ARP entries for the same address. One of these can be found in /proc/net/arp, and the other in /proc/net/atm/arp. This patch adds a new function, neigh_table_init_no_netlink() which does everything the neigh_table_init() does, except add the table to the netlink all-arp-tables chain. In addition neigh_table_init() has a check that all tables on the chain have a distinct address family. The init call in clip.c is changed to call neigh_table_init_no_netlink(). Since ATM ARP tables are rather more complicated than can currently be handled by the available rtattrs in the netlink protocol, no functionality is lost by this patch, and non-ATM ARP manipulation via netlink is rescued. A more complete solution would involve a rtattr for ATM ARP entries and some way for the netlink code to give neigh_add and friends more information than just address family with which to find the correct ARP table. [ I've changed the assertion checking in neigh_table_init() to not use BUG_ON() while holding neigh_tbl_lock. Instead we remember that we found an existing tbl with the same family, and after dropping the lock we'll give a diagnostic kernel log message and a stack dump. -DaveM ] Signed-off-by: Simon Kelley <simon@thekelleys.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net> |
||
|---|---|---|
| .. | ||
| addr.c | ||
| addr.h | ||
| atm_misc.c | ||
| br2684.c | ||
| clip.c | ||
| common.c | ||
| common.h | ||
| ioctl.c | ||
| ipcommon.c | ||
| ipcommon.h | ||
| Kconfig | ||
| lec_arpc.h | ||
| lec.c | ||
| lec.h | ||
| Makefile | ||
| mpc.c | ||
| mpc.h | ||
| mpoa_caches.c | ||
| mpoa_caches.h | ||
| mpoa_proc.c | ||
| pppoatm.c | ||
| proc.c | ||
| protocols.h | ||
| pvc.c | ||
| raw.c | ||
| resources.c | ||
| resources.h | ||
| signaling.c | ||
| signaling.h | ||
| svc.c | ||