69cc64d8d9
Frank Blaschka provided the bug report and the initial suggested fix for this bug. He also validated this version of this fix. The problem is that the access to neigh->arp_queue is inconsistent, we grab references when dropping the lock lock to call neigh->ops->solicit() but this does not prevent other threads of control from trying to send out that packet at the same time causing corruptions because both code paths believe they have exclusive access to the skb. The best option seems to be to hold the write lock on neigh->lock during the ->solicit() call. I looked at all of the ndisc_ops implementations and this seems workable. The only case that needs special care is the IPV4 ARP implementation of arp_solicit(). It wants to take neigh->lock as a reader to protect the header entry in neigh->ha during the emission of the soliciation. We can simply remove the read lock calls to take care of that since holding the lock as a writer at the caller providers a superset of the protection afforded by the existing read locking. The rest of the ->solicit() implementations don't care whether the neigh is locked or not. Signed-off-by: David S. Miller <davem@davemloft.net> |
||
|---|---|---|
| .. | ||
| Makefile | ||
| datagram.c | ||
| dev.c | ||
| dev_mcast.c | ||
| dst.c | ||
| ethtool.c | ||
| fib_rules.c | ||
| filter.c | ||
| flow.c | ||
| gen_estimator.c | ||
| gen_stats.c | ||
| iovec.c | ||
| kmap_skb.h | ||
| link_watch.c | ||
| neighbour.c | ||
| net-sysfs.c | ||
| net-sysfs.h | ||
| net_namespace.c | ||
| netevent.c | ||
| netpoll.c | ||
| pktgen.c | ||
| request_sock.c | ||
| rtnetlink.c | ||
| scm.c | ||
| skbuff.c | ||
| sock.c | ||
| stream.c | ||
| sysctl_net_core.c | ||
| user_dma.c | ||
| utils.c | ||