1. 19 2月, 2013 2 次提交
  2. 11 2月, 2013 1 次提交
  3. 25 12月, 2012 1 次提交
  4. 22 12月, 2012 1 次提交
    • E
      ipv4: arp: fix a lockdep splat in arp_solicit() · 9650388b
      Eric Dumazet 提交于
      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: [<ffffffff8139f56e>] __neigh_event_send
      +0x2e/0x2f0
      
      but task is already holding lock:
        (&n->lock){++--..}, at: [<ffffffff813f63f4>] 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: [<ffffffff8104b350>]
      call_timer_fn+0x0/0x1c0
        #1:  (&n->lock){++--..}, at: [<ffffffff813f63f4>] arp_solicit
      +0x1d4/0x280
        #2:  (rcu_read_lock_bh){.+....}, at: [<ffffffff81395400>]
      dev_queue_xmit+0x0/0x5d0
        #3:  (rcu_read_lock_bh){.+....}, at: [<ffffffff813cb41e>]
      ip_finish_output+0x13e/0x640
      
      stack backtrace:
      Pid: 0, comm: swapper/1 Not tainted 3.7.0+ #24
      Call Trace:
        <IRQ>  [<ffffffff8108c7ac>] validate_chain+0xdcc/0x11f0
        [<ffffffff8108d570>] ? __lock_acquire+0x440/0xc30
        [<ffffffff81120565>] ? kmem_cache_free+0xe5/0x1c0
        [<ffffffff8108d570>] __lock_acquire+0x440/0xc30
        [<ffffffff813c3570>] ? inet_getpeer+0x40/0x600
        [<ffffffff8108d570>] ? __lock_acquire+0x440/0xc30
        [<ffffffff8139f56e>] ? __neigh_event_send+0x2e/0x2f0
        [<ffffffff8108ddf5>] lock_acquire+0x95/0x140
        [<ffffffff8139f56e>] ? __neigh_event_send+0x2e/0x2f0
        [<ffffffff8108d570>] ? __lock_acquire+0x440/0xc30
        [<ffffffff81448d4b>] _raw_write_lock_bh+0x3b/0x50
        [<ffffffff8139f56e>] ? __neigh_event_send+0x2e/0x2f0
        [<ffffffff8139f56e>] __neigh_event_send+0x2e/0x2f0
        [<ffffffff8139f99b>] neigh_resolve_output+0x16b/0x270
        [<ffffffff813cb62d>] ip_finish_output+0x34d/0x640
        [<ffffffff813cb41e>] ? ip_finish_output+0x13e/0x640
        [<ffffffffa046f146>] ? vxlan_xmit+0x556/0xbec [vxlan]
        [<ffffffff813cb9a0>] ip_output+0x80/0xf0
        [<ffffffff813ca368>] ip_local_out+0x28/0x80
        [<ffffffffa046f25a>] vxlan_xmit+0x66a/0xbec [vxlan]
        [<ffffffffa046f146>] ? vxlan_xmit+0x556/0xbec [vxlan]
        [<ffffffff81394a50>] ? skb_gso_segment+0x2b0/0x2b0
        [<ffffffff81449355>] ? _raw_spin_unlock_irqrestore+0x65/0x80
        [<ffffffff81394c57>] ? dev_queue_xmit_nit+0x207/0x270
        [<ffffffff813950c8>] dev_hard_start_xmit+0x298/0x5d0
        [<ffffffff813956f3>] dev_queue_xmit+0x2f3/0x5d0
        [<ffffffff81395400>] ? dev_hard_start_xmit+0x5d0/0x5d0
        [<ffffffff813f5788>] arp_xmit+0x58/0x60
        [<ffffffff813f59db>] arp_send+0x3b/0x40
        [<ffffffff813f6424>] arp_solicit+0x204/0x280
        [<ffffffff813a1a70>] ? neigh_add+0x310/0x310
        [<ffffffff8139f515>] neigh_probe+0x45/0x70
        [<ffffffff813a1c10>] neigh_timer_handler+0x1a0/0x2a0
        [<ffffffff8104b3cf>] call_timer_fn+0x7f/0x1c0
        [<ffffffff8104b350>] ? detach_if_pending+0x120/0x120
        [<ffffffff8104b748>] run_timer_softirq+0x238/0x2b0
        [<ffffffff813a1a70>] ? neigh_add+0x310/0x310
        [<ffffffff81043e51>] __do_softirq+0x101/0x280
        [<ffffffff814518cc>] call_softirq+0x1c/0x30
        [<ffffffff81003b65>] do_softirq+0x85/0xc0
        [<ffffffff81043a7e>] irq_exit+0x9e/0xc0
        [<ffffffff810264f8>] smp_apic_timer_interrupt+0x68/0xa0
        [<ffffffff8145122f>] apic_timer_interrupt+0x6f/0x80
        <EOI>  [<ffffffff8100a054>] ? mwait_idle+0xa4/0x1c0
        [<ffffffff8100a04b>] ? mwait_idle+0x9b/0x1c0
        [<ffffffff8100a6a9>] cpu_idle+0x89/0xe0
        [<ffffffff81441127>] 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: NYan Burman <yanb@mellanox.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9650388b
  5. 19 11月, 2012 1 次提交
    • E
      net: Allow userns root to control ipv4 · 52e804c6
      Eric W. Biederman 提交于
      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: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      52e804c6
  6. 19 9月, 2012 1 次提交
  7. 08 9月, 2012 1 次提交
  8. 27 7月, 2012 1 次提交
  9. 21 7月, 2012 2 次提交
  10. 28 6月, 2012 2 次提交
    • D
      Revert "ipv4: tcp: dont cache unconfirmed intput dst" · c10237e0
      David S. Miller 提交于
      This reverts commit c074da28.
      
      This change has several unwanted side effects:
      
      1) Sockets will cache the DST_NOCACHE route in sk->sk_rx_dst and we'll
         thus never create a real cached route.
      
      2) All TCP traffic will use DST_NOCACHE and never use the routing
         cache at all.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c10237e0
    • E
      ipv4: tcp: dont cache unconfirmed intput dst · c074da28
      Eric Dumazet 提交于
      DDOS synflood attacks hit badly IP route cache.
      
      On typical machines, this cache is allowed to hold up to 8 Millions dst
      entries, 256 bytes for each, for a total of 2GB of memory.
      
      rt_garbage_collect() triggers and tries to cleanup things.
      
      Eventually route cache is disabled but machine is under fire and might
      OOM and crash.
      
      This patch exploits the new TCP early demux, to set a nocache
      boolean in case incoming TCP frame is for a not yet ESTABLISHED or
      TIMEWAIT socket.
      
      This 'nocache' boolean is then used in case dst entry is not found in
      route cache, to create an unhashed dst entry (DST_NOCACHE)
      
      SYN-cookie-ACK sent use a similar mechanism (ipv4: tcp: dont cache
      output dst for syncookies), so after this patch, a machine is able to
      absorb a DDOS synflood attack without polluting its IP route cache.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Hans Schillstrom <hans.schillstrom@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c074da28
  11. 13 6月, 2012 1 次提交
    • T
      ipv4: Add interface option to enable routing of 127.0.0.0/8 · d0daebc3
      Thomas Graf 提交于
      Routing of 127/8 is tradtionally forbidden, we consider
      packets from that address block martian when routing and do
      not process corresponding ARP requests.
      
      This is a sane default but renders a huge address space
      practically unuseable.
      
      The RFC states that no address within the 127/8 block should
      ever appear on any network anywhere but it does not forbid
      the use of such addresses outside of the loopback device in
      particular. For example to address a pool of virtual guests
      behind a load balancer.
      
      This patch adds a new interface option 'route_localnet'
      enabling routing of the 127/8 address block and processing
      of ARP requests on a specific interface.
      
      Note that for the feature to work, the default local route
      covering 127/8 dev lo needs to be removed.
      
      Example:
        $ sysctl -w net.ipv4.conf.eth0.route_localnet=1
        $ ip route del 127.0.0.0/8 dev lo table local
        $ ip addr add 127.1.0.1/16 dev eth0
        $ ip route flush cache
      
      V2: Fix invalid check to auto flush cache (thanks davem)
      Signed-off-by: NThomas Graf <tgraf@suug.ch>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0daebc3
  12. 16 5月, 2012 2 次提交
  13. 16 4月, 2012 1 次提交
  14. 29 3月, 2012 1 次提交
  15. 17 3月, 2012 1 次提交
    • N
      arp: allow arp processing to honor per interface arp_accept sysctl · 124d37e9
      Neil Horman 提交于
      I found recently that the arp_process function which handles all of our received
      arp frames, is using IPV4_DEVCONF_ALL macro to check the state of the arp_process
      flag.  This seems wrong, as it implies that either none or all of the network
      interfaces accept gratuitous arps.  This patch corrects that, allowing
      per-interface arp_accept configuration to deviate from the all setting.  Note
      this also brings us into line with the way the arp_filter setting is handled
      during arp_process execution.
      
      Tested this myself on my home network, and confirmed it works as expected.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      124d37e9
  16. 11 2月, 2012 1 次提交
  17. 29 12月, 2011 1 次提交
  18. 06 12月, 2011 1 次提交
  19. 01 12月, 2011 2 次提交
  20. 19 11月, 2011 1 次提交
    • H
      ipv4: Remove all uses of LL_ALLOCATED_SPACE · 66088243
      Herbert Xu 提交于
      ipv4: Remove all uses of LL_ALLOCATED_SPACE
      
      The macro LL_ALLOCATED_SPACE was ill-conceived.  It applies the
      alignment to the sum of needed_headroom and needed_tailroom.  As
      the amount that is then reserved for head room is needed_headroom
      with alignment, this means that the tail room left may be too small.
      
      This patch replaces all uses of LL_ALLOCATED_SPACE in net/ipv4
      with the macro LL_RESERVED_SPACE and direct reference to
      needed_tailroom.
      
      This also fixes the problem with needed_headroom changing between
      allocating the skb and reserving the head room.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      66088243
  21. 14 11月, 2011 1 次提交
    • E
      neigh: new unresolved queue limits · 8b5c171b
      Eric Dumazet 提交于
      Le mercredi 09 novembre 2011 à 16:21 -0500, David Miller a écrit :
      > From: David Miller <davem@davemloft.net>
      > Date: Wed, 09 Nov 2011 16:16:44 -0500 (EST)
      >
      > > From: Eric Dumazet <eric.dumazet@gmail.com>
      > > Date: Wed, 09 Nov 2011 12:14:09 +0100
      > >
      > >> unres_qlen is the number of frames we are able to queue per unresolved
      > >> neighbour. Its default value (3) was never changed and is responsible
      > >> for strange drops, especially if IP fragments are used, or multiple
      > >> sessions start in parallel. Even a single tcp flow can hit this limit.
      > >  ...
      > >
      > > Ok, I've applied this, let's see what happens :-)
      >
      > Early answer, build fails.
      >
      > Please test build this patch with DECNET enabled and resubmit.  The
      > decnet neigh layer still refers to the removed ->queue_len member.
      >
      > Thanks.
      
      Ouch, this was fixed on one machine yesterday, but not the other one I
      used this morning, sorry.
      
      [PATCH V5 net-next] neigh: new unresolved queue limits
      
      unres_qlen is the number of frames we are able to queue per unresolved
      neighbour. Its default value (3) was never changed and is responsible
      for strange drops, especially if IP fragments are used, or multiple
      sessions start in parallel. Even a single tcp flow can hit this limit.
      
      $ arp -d 192.168.20.108 ; ping -c 2 -s 8000 192.168.20.108
      PING 192.168.20.108 (192.168.20.108) 8000(8028) bytes of data.
      8008 bytes from 192.168.20.108: icmp_seq=2 ttl=64 time=0.322 ms
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8b5c171b
  22. 18 7月, 2011 1 次提交
  23. 17 7月, 2011 2 次提交
  24. 13 7月, 2011 1 次提交
    • D
      ipv4: Inline neigh binding. · 3769cffb
      David Miller 提交于
      Get rid of all of the useless and costly indirection
      by doing the neigh hash table lookup directly inside
      of the neighbour binding.
      
      Rename from arp_bind_neighbour to rt_bind_neighbour.
      
      Use new helpers {__,}ipv4_neigh_lookup()
      
      In rt_bind_neighbour() get rid of useless tests which
      are never true in the context this function is called,
      namely dev is never NULL and the dst->neighbour is
      always NULL.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3769cffb
  25. 11 7月, 2011 1 次提交
  26. 30 3月, 2011 1 次提交
  27. 13 3月, 2011 1 次提交
  28. 03 3月, 2011 1 次提交
  29. 25 1月, 2011 1 次提交
  30. 11 1月, 2011 1 次提交
  31. 09 12月, 2010 1 次提交
    • E
      net: RCU conversion of dev_getbyhwaddr() and arp_ioctl() · 941666c2
      Eric Dumazet 提交于
      Le dimanche 05 décembre 2010 à 09:19 +0100, Eric Dumazet a écrit :
      
      > Hmm..
      >
      > If somebody can explain why RTNL is held in arp_ioctl() (and therefore
      > in arp_req_delete()), we might first remove RTNL use in arp_ioctl() so
      > that your patch can be applied.
      >
      > Right now it is not good, because RTNL wont be necessarly held when you
      > are going to call arp_invalidate() ?
      
      While doing this analysis, I found a refcount bug in llc, I'll send a
      patch for net-2.6
      
      Meanwhile, here is the patch for net-next-2.6
      
      Your patch then can be applied after mine.
      
      Thanks
      
      [PATCH] net: RCU conversion of dev_getbyhwaddr() and arp_ioctl()
      
      dev_getbyhwaddr() was called under RTNL.
      
      Rename it to dev_getbyhwaddr_rcu() and change all its caller to now use
      RCU locking instead of RTNL.
      
      Change arp_ioctl() to use RCU instead of RTNL locking.
      
      Note: this fix a dev refcount bug in llc
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      941666c2
  32. 07 12月, 2010 1 次提交
  33. 18 11月, 2010 1 次提交
  34. 12 10月, 2010 1 次提交