linux-stable.git/net/ipv4/arp.c, branch linux-3.9.y

net: proc: change proc_net_remove to remove_proc_entry

2013-02-18T19:53:08+00:00

proc_net_remove is only used to remove proc entries
that under /proc/net,it's not a general function for
removing proc entries of netns. if we want to remove
some proc entries which under /proc/net/stat/, we still
need to call remove_proc_entry.

this patch use remove_proc_entry to replace proc_net_remove.
we can remove proc_net_remove after this patch.

Signed-off-by: Gao feng 
Signed-off-by: David S. Miller

net: proc: change proc_net_fops_create to proc_create

2013-02-18T19:53:08+00:00

Right now, some modules such as bonding use proc_create
to create proc entries under /proc/net/, and other modules
such as ipv4 use proc_net_fops_create.

It looks a little chaos.this patch changes all of
proc_net_fops_create to proc_create. we can remove
proc_net_fops_create after this patch.

Signed-off-by: Gao feng 
Signed-off-by: David S. Miller

arp: fix possible crash in arp_rcv()

2013-02-11T01:39:39+00:00

We should call skb_share_check() before pskb_may_pull(), or we
can crash in pskb_expand_head()

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

arp: fix a regression in arp_solicit()

2012-12-25T02:42:58+00:00

Sedat reported the following commit caused a regression:

commit 9650388b5c56578fdccc79c57a8c82fb92b8e7f1
Author: Eric Dumazet 
Date:   Fri Dec 21 07:32:10 2012 +0000

    ipv4: arp: fix a lockdep splat in arp_solicit

This is due to the 6th parameter of arp_send() needs to be NULL
for the broadcast case, the above commit changed it to an all-zero
array by mistake.

Reported-by: Sedat Dilek 
Tested-by: Sedat Dilek 
Cc: Sedat Dilek 
Cc: Eric Dumazet 
Cc: David S. Miller 
Cc: Julian Anastasov 
Signed-off-by: Cong Wang 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller

ipv4: arp: fix a lockdep splat in arp_solicit()

2012-12-21T21:14:07+00:00

Yan Burman reported following lockdep warning :

=============================================
[ INFO: possible recursive locking detected ]
3.7.0+ #24 Not tainted
---------------------------------------------
swapper/1/0 is trying to acquire lock:
  (&n->lock){++--..}, at: [] __neigh_event_send
+0x2e/0x2f0

but task is already holding lock:
  (&n->lock){++--..}, at: [] arp_solicit+0x1d4/0x280

other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(&n->lock);
   lock(&n->lock);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

4 locks held by swapper/1/0:
  #0:  (((&n->timer))){+.-...}, at: []
call_timer_fn+0x0/0x1c0
  #1:  (&n->lock){++--..}, at: [] arp_solicit
+0x1d4/0x280
  #2:  (rcu_read_lock_bh){.+....}, at: []
dev_queue_xmit+0x0/0x5d0
  #3:  (rcu_read_lock_bh){.+....}, at: []
ip_finish_output+0x13e/0x640

stack backtrace:
Pid: 0, comm: swapper/1 Not tainted 3.7.0+ #24
Call Trace:
    [] validate_chain+0xdcc/0x11f0
  [] ? __lock_acquire+0x440/0xc30
  [] ? kmem_cache_free+0xe5/0x1c0
  [] __lock_acquire+0x440/0xc30
  [] ? inet_getpeer+0x40/0x600
  [] ? __lock_acquire+0x440/0xc30
  [] ? __neigh_event_send+0x2e/0x2f0
  [] lock_acquire+0x95/0x140
  [] ? __neigh_event_send+0x2e/0x2f0
  [] ? __lock_acquire+0x440/0xc30
  [] _raw_write_lock_bh+0x3b/0x50
  [] ? __neigh_event_send+0x2e/0x2f0
  [] __neigh_event_send+0x2e/0x2f0
  [] neigh_resolve_output+0x16b/0x270
  [] ip_finish_output+0x34d/0x640
  [] ? ip_finish_output+0x13e/0x640
  [] ? vxlan_xmit+0x556/0xbec [vxlan]
  [] ip_output+0x80/0xf0
  [] ip_local_out+0x28/0x80
  [] vxlan_xmit+0x66a/0xbec [vxlan]
  [] ? vxlan_xmit+0x556/0xbec [vxlan]
  [] ? skb_gso_segment+0x2b0/0x2b0
  [] ? _raw_spin_unlock_irqrestore+0x65/0x80
  [] ? dev_queue_xmit_nit+0x207/0x270
  [] dev_hard_start_xmit+0x298/0x5d0
  [] dev_queue_xmit+0x2f3/0x5d0
  [] ? dev_hard_start_xmit+0x5d0/0x5d0
  [] arp_xmit+0x58/0x60
  [] arp_send+0x3b/0x40
  [] arp_solicit+0x204/0x280
  [] ? neigh_add+0x310/0x310
  [] neigh_probe+0x45/0x70
  [] neigh_timer_handler+0x1a0/0x2a0
  [] call_timer_fn+0x7f/0x1c0
  [] ? detach_if_pending+0x120/0x120
  [] run_timer_softirq+0x238/0x2b0
  [] ? neigh_add+0x310/0x310
  [] __do_softirq+0x101/0x280
  [] call_softirq+0x1c/0x30
  [] do_softirq+0x85/0xc0
  [] irq_exit+0x9e/0xc0
  [] smp_apic_timer_interrupt+0x68/0xa0
  [] apic_timer_interrupt+0x6f/0x80
    [] ? mwait_idle+0xa4/0x1c0
  [] ? mwait_idle+0x9b/0x1c0
  [] cpu_idle+0x89/0xe0
  [] start_secondary+0x1b2/0x1b6

Bug is from arp_solicit(), releasing the neigh lock after arp_send()
In case of vxlan, we eventually need to write lock a neigh lock later.

Its a false positive, but we can get rid of it without lockdep
annotations.

We can instead use neigh_ha_snapshot() helper.

Reported-by: Yan Burman 
Signed-off-by: Eric Dumazet 
Acked-by: Stephen Hemminger 
Signed-off-by: David S. Miller

net: Allow userns root to control ipv4

2012-11-19T01:32:45+00:00

Allow an unpriviled user who has created a user namespace, and then
created a network namespace to effectively use the new network
namespace, by reducing capable(CAP_NET_ADMIN) and
capable(CAP_NET_RAW) calls to be ns_capable(net->user_ns,
CAP_NET_ADMIN), or capable(net->user_ns, CAP_NET_RAW) calls.

Settings that merely control a single network device are allowed.
Either the network device is a logical network device where
restrictions make no difference or the network device is hardware NIC
that has been explicity moved from the initial network namespace.

In general policy and network stack state changes are allowed
while resource control is left unchanged.

Allow creating raw sockets.
Allow the SIOCSARP ioctl to control the arp cache.
Allow the SIOCSIFFLAG ioctl to allow setting network device flags.
Allow the SIOCSIFADDR ioctl to allow setting a netdevice ipv4 address.
Allow the SIOCSIFBRDADDR ioctl to allow setting a netdevice ipv4 broadcast address.
Allow the SIOCSIFDSTADDR ioctl to allow setting a netdevice ipv4 destination address.
Allow the SIOCSIFNETMASK ioctl to allow setting a netdevice ipv4 netmask.
Allow the SIOCADDRT and SIOCDELRT ioctls to allow adding and deleting ipv4 routes.

Allow the SIOCADDTUNNEL, SIOCCHGTUNNEL and SIOCDELTUNNEL ioctls for
adding, changing and deleting gre tunnels.

Allow the SIOCADDTUNNEL, SIOCCHGTUNNEL and SIOCDELTUNNEL ioctls for
adding, changing and deleting ipip tunnels.

Allow the SIOCADDTUNNEL, SIOCCHGTUNNEL and SIOCDELTUNNEL ioctls for
adding, changing and deleting ipsec virtual tunnel interfaces.

Allow setting the MRT_INIT, MRT_DONE, MRT_ADD_VIF, MRT_DEL_VIF, MRT_ADD_MFC,
MRT_DEL_MFC, MRT_ASSERT, MRT_PIM, MRT_TABLE socket options on multicast routing
sockets.

Allow setting and receiving IPOPT_CIPSO, IP_OPT_SEC, IP_OPT_SID and
arbitrary ip options.

Allow setting IP_SEC_POLICY/IP_XFRM_POLICY ipv4 socket option.
Allow setting the IP_TRANSPARENT ipv4 socket option.
Allow setting the TCP_REPAIR socket option.
Allow setting the TCP_CONGESTION socket option.

Signed-off-by: "Eric W. Biederman" 
Signed-off-by: David S. Miller

ipv4/route: arg delay is useless in rt_cache_flush()

2012-09-18T19:44:34+00:00

Since route cache deletion (89aef8921bfbac22f), delay is no
more used. Remove it.

Signed-off-by: Nicolas Dichtel 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller

ipv4: Fix input route performance regression.

2012-07-26T22:50:39+00:00

With the routing cache removal we lost the "noref" code paths on
input, and this can kill some routing workloads.

Reinstate the noref path when we hit a cached route in the FIB
nexthops.

With help from Eric Dumazet.

Reported-by: Alexander Duyck 
Signed-off-by: David S. Miller 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

ipv4: Adjust semantics of rt->rt_gateway.

2012-07-20T20:31:20+00:00

In order to allow prefixed routes, we have to adjust how rt_gateway
is set and interpreted.

The new interpretation is:

1) rt_gateway == 0, destination is on-link, nexthop is iph->daddr

2) rt_gateway != 0, destination requires a nexthop gateway

Abstract the fetching of the proper nexthop value using a new
inline helper, rt_nexthop(), as suggested by Joe Perches.

Signed-off-by: David S. Miller 
Tested-by: Vijay Subramanian

ipv4: Kill ip_route_input_noref().

2012-07-20T20:30:59+00:00

The "noref" argument to ip_route_input_common() is now always ignored
because we do not cache routes, and in that case we must always grab
a reference to the resulting 'dst'.

Signed-off-by: David S. Miller