1. 20 6月, 2013 1 次提交
  2. 13 6月, 2013 1 次提交
  3. 17 4月, 2013 1 次提交
  4. 10 4月, 2013 1 次提交
    • A
      procfs: new helper - PDE_DATA(inode) · d9dda78b
      Al Viro 提交于
      The only part of proc_dir_entry the code outside of fs/proc
      really cares about is PDE(inode)->data.  Provide a helper
      for that; static inline for now, eventually will be moved
      to fs/proc, along with the knowledge of struct proc_dir_entry
      layout.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d9dda78b
  5. 22 3月, 2013 1 次提交
  6. 29 1月, 2013 1 次提交
    • Y
      net neigh: Optimize neighbor entry size calculation. · 08433eff
      YOSHIFUJI Hideaki / 吉藤英明 提交于
      When allocating memory for neighbour cache entry, if
      tbl->entry_size is not set, we always calculate
      sizeof(struct neighbour) + tbl->key_len, which is common
      in the same table.
      
      With this change, set tbl->entry_size during the table
      initialization phase, if it was not set, and use it in
      neigh_alloc() and neighbour_priv().
      
      This change also allow us to have both of protocol private
      data and device priate data at tha same time.
      
      Note that the only user of prototcol private is DECnet
      and the only user of device private is ATM CLIP.
      Since those are exclusive, we have not been facing issues
      here.
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      08433eff
  7. 23 1月, 2013 1 次提交
  8. 06 12月, 2012 2 次提交
  9. 19 11月, 2012 3 次提交
  10. 08 10月, 2012 1 次提交
  11. 11 9月, 2012 1 次提交
  12. 22 8月, 2012 1 次提交
  13. 05 7月, 2012 2 次提交
  14. 08 6月, 2012 1 次提交
  15. 17 5月, 2012 1 次提交
  16. 21 4月, 2012 2 次提交
  17. 16 4月, 2012 1 次提交
  18. 14 4月, 2012 1 次提交
  19. 02 4月, 2012 1 次提交
  20. 22 2月, 2012 1 次提交
    • M
      neighbour: Fixed race condition at tbl->nht · 84338a6c
      Michel Machado 提交于
      When the fixed race condition happens:
      
      1. While function neigh_periodic_work scans the neighbor hash table
      pointed by field tbl->nht, it unlocks and locks tbl->lock between
      buckets in order to call cond_resched.
      
      2. Assume that function neigh_periodic_work calls cond_resched, that is,
      the lock tbl->lock is available, and function neigh_hash_grow runs.
      
      3. Once function neigh_hash_grow finishes, and RCU calls
      neigh_hash_free_rcu, the original struct neigh_hash_table that function
      neigh_periodic_work was using doesn't exist anymore.
      
      4. Once back at neigh_periodic_work, whenever the old struct
      neigh_hash_table is accessed, things can go badly.
      Signed-off-by: NMichel Machado <michel@digirati.com.br>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      84338a6c
  21. 31 1月, 2012 1 次提交
    • T
      net: Allow ipv6 proxies and arp proxies be shown with iproute2 · 84920c14
      Tony Zelenoff 提交于
      Add ability to return neighbour proxies list to caller if
      it sent full ndmsg structure and has NTF_PROXY flag set.
      
      Before this patch (and before iproute2 patches):
      $ ip neigh add proxy 2001::1 dev eth0
      $ ip -6 neigh show
      $
      
      After it and with applied iproute2 patches:
      $ ip neigh add proxy 2001::1 dev eth0
      $ ip -6 neigh show
      2001::1 dev eth0  proxy
      $
      
      Compatibility with old versions of iproute2 is not broken,
      kernel checks for incoming structure size and properly
      works if old structure is came.
      
      [v2]
      * changed comments style.
      * removed useless line with continue and curly bracket.
      * changed incoming message size check from equal to more or
        equal.
      
      CC: davem@davemloft.net
      CC: kuznet@ms2.inr.ac.ru
      CC: netdev@vger.kernel.org
      CC: xemul@parallels.com
      Signed-off-by: NTony Zelenoff <antonz@parallels.com>
      Acked-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      84920c14
  22. 29 12月, 2011 1 次提交
  23. 20 12月, 2011 1 次提交
  24. 14 12月, 2011 1 次提交
  25. 06 12月, 2011 1 次提交
  26. 01 12月, 2011 3 次提交
  27. 26 11月, 2011 1 次提交
  28. 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
  29. 02 11月, 2011 1 次提交
  30. 20 10月, 2011 1 次提交
    • R
      neigh: fix rcu splat in neigh_update() · e049f288
      roy.qing.li@gmail.com 提交于
      when use dst_get_neighbour to get neighbour, we need
      rcu_read_lock to protect, since dst_get_neighbour uses
      rcu_dereference.
      
      The bug was reported by Ari Savolainen <ari.m.savolainen@gmail.com>
      
      [  105.612095]
      [  105.612096] ===================================================
      [  105.612100] [ INFO: suspicious rcu_dereference_check() usage. ]
      [  105.612101] ---------------------------------------------------
      [  105.612103] include/net/dst.h:91 invoked rcu_dereference_check()
      without protection!
      [  105.612105]
      [  105.612106] other info that might help us debug this:
      [  105.612106]
      [  105.612108]
      [  105.612108] rcu_scheduler_active = 1, debug_locks = 0
      [  105.612110] 1 lock held by dnsmasq/2618:
      [  105.612111]  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff815df8c7>]
      rtnl_lock+0x17/0x20
      [  105.612120]
      [  105.612121] stack backtrace:
      [  105.612123] Pid: 2618, comm: dnsmasq Not tainted 3.1.0-rc1 #41
      [  105.612125] Call Trace:
      [  105.612129]  [<ffffffff810ccdcb>] lockdep_rcu_dereference+0xbb/0xc0
      [  105.612132]  [<ffffffff815dc5a9>] neigh_update+0x4f9/0x5f0
      [  105.612135]  [<ffffffff815da001>] ? neigh_lookup+0xe1/0x220
      [  105.612139]  [<ffffffff81639298>] arp_req_set+0xb8/0x230
      [  105.612142]  [<ffffffff8163a59f>] arp_ioctl+0x1bf/0x310
      [  105.612146]  [<ffffffff810baa40>] ? lock_hrtimer_base.isra.26+0x30/0x60
      [  105.612150]  [<ffffffff8163fb75>] inet_ioctl+0x85/0x90
      [  105.612154]  [<ffffffff815b5520>] sock_do_ioctl+0x30/0x70
      [  105.612157]  [<ffffffff815b55d3>] sock_ioctl+0x73/0x280
      [  105.612162]  [<ffffffff811b7698>] do_vfs_ioctl+0x98/0x570
      [  105.612165]  [<ffffffff811a5c40>] ? fget_light+0x340/0x3a0
      [  105.612168]  [<ffffffff811b7bbf>] sys_ioctl+0x4f/0x80
      [  105.612172]  [<ffffffff816fdcab>] system_call_fastpath+0x16/0x1b
      Reported-by: NAri Savolainen <ari.m.savolainen@gmail.com>
      Signed-off-by: NRongQing <roy.qing.li@gmail.com>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e049f288
  31. 25 8月, 2011 1 次提交
    • E
      arp: fix rcu lockdep splat in arp_process() · 20e6074e
      Eric Dumazet 提交于
      Dave Jones reported a lockdep splat triggered by an arp_process() call
      from parp_redo().
      
      Commit faa9dcf7 (arp: RCU changes) is the origin of the bug, since
      it assumed arp_process() was called under rcu_read_lock(), which is not
      true in this particular path.
      
      Instead of adding rcu_read_lock() in parp_redo(), I chose to add it in
      neigh_proxy_process() to take care of IPv6 side too.
      
       ===================================================
       [ INFO: suspicious rcu_dereference_check() usage. ]
       ---------------------------------------------------
       include/linux/inetdevice.h:209 invoked rcu_dereference_check() without
      protection!
      
       other info that might help us debug this:
      
       rcu_scheduler_active = 1, debug_locks = 0
       4 locks held by setfiles/2123:
        #0:  (&sb->s_type->i_mutex_key#13){+.+.+.}, at: [<ffffffff8114cbc4>]
      walk_component+0x1ef/0x3e8
        #1:  (&isec->lock){+.+.+.}, at: [<ffffffff81204bca>]
      inode_doinit_with_dentry+0x3f/0x41f
        #2:  (&tbl->proxy_timer){+.-...}, at: [<ffffffff8106a803>]
      run_timer_softirq+0x157/0x372
        #3:  (class){+.-...}, at: [<ffffffff8141f256>] neigh_proxy_process
      +0x36/0x103
      
       stack backtrace:
       Pid: 2123, comm: setfiles Tainted: G        W
      3.1.0-0.rc2.git7.2.fc16.x86_64 #1
       Call Trace:
        <IRQ>  [<ffffffff8108ca23>] lockdep_rcu_dereference+0xa7/0xaf
        [<ffffffff8146a0b7>] __in_dev_get_rcu+0x55/0x5d
        [<ffffffff8146a751>] arp_process+0x25/0x4d7
        [<ffffffff8146ac11>] parp_redo+0xe/0x10
        [<ffffffff8141f2ba>] neigh_proxy_process+0x9a/0x103
        [<ffffffff8106a8c4>] run_timer_softirq+0x218/0x372
        [<ffffffff8106a803>] ? run_timer_softirq+0x157/0x372
        [<ffffffff8141f220>] ? neigh_stat_seq_open+0x41/0x41
        [<ffffffff8108f2f0>] ? mark_held_locks+0x6d/0x95
        [<ffffffff81062bb6>] __do_softirq+0x112/0x25a
        [<ffffffff8150d27c>] call_softirq+0x1c/0x30
        [<ffffffff81010bf5>] do_softirq+0x4b/0xa2
        [<ffffffff81062f65>] irq_exit+0x5d/0xcf
        [<ffffffff8150dc11>] smp_apic_timer_interrupt+0x7c/0x8a
        [<ffffffff8150baf3>] apic_timer_interrupt+0x73/0x80
        <EOI>  [<ffffffff8108f439>] ? trace_hardirqs_on_caller+0x121/0x158
        [<ffffffff814fc285>] ? __slab_free+0x30/0x24c
        [<ffffffff814fc283>] ? __slab_free+0x2e/0x24c
        [<ffffffff81204e74>] ? inode_doinit_with_dentry+0x2e9/0x41f
        [<ffffffff81204e74>] ? inode_doinit_with_dentry+0x2e9/0x41f
        [<ffffffff81204e74>] ? inode_doinit_with_dentry+0x2e9/0x41f
        [<ffffffff81130cb0>] kfree+0x108/0x131
        [<ffffffff81204e74>] inode_doinit_with_dentry+0x2e9/0x41f
        [<ffffffff81204fc6>] selinux_d_instantiate+0x1c/0x1e
        [<ffffffff81200f4f>] security_d_instantiate+0x21/0x23
        [<ffffffff81154625>] d_instantiate+0x5c/0x61
        [<ffffffff811563ca>] d_splice_alias+0xbc/0xd2
        [<ffffffff811b17ff>] ext4_lookup+0xba/0xeb
        [<ffffffff8114bf1e>] d_alloc_and_lookup+0x45/0x6b
        [<ffffffff8114cbea>] walk_component+0x215/0x3e8
        [<ffffffff8114cdf8>] lookup_last+0x3b/0x3d
        [<ffffffff8114daf3>] path_lookupat+0x82/0x2af
        [<ffffffff8110fc53>] ? might_fault+0xa5/0xac
        [<ffffffff8110fc0a>] ? might_fault+0x5c/0xac
        [<ffffffff8114c564>] ? getname_flags+0x31/0x1ca
        [<ffffffff8114dd48>] do_path_lookup+0x28/0x97
        [<ffffffff8114df2c>] user_path_at+0x59/0x96
        [<ffffffff811467ad>] ? cp_new_stat+0xf7/0x10d
        [<ffffffff811469a6>] vfs_fstatat+0x44/0x6e
        [<ffffffff811469ee>] vfs_lstat+0x1e/0x20
        [<ffffffff81146b3d>] sys_newlstat+0x1a/0x33
        [<ffffffff8108f439>] ? trace_hardirqs_on_caller+0x121/0x158
        [<ffffffff812535fe>] ? trace_hardirqs_on_thunk+0x3a/0x3f
        [<ffffffff8150af82>] system_call_fastpath+0x16/0x1b
      Reported-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      20e6074e
  32. 12 8月, 2011 1 次提交
    • E
      neigh: reduce arp latency · cd28ca0a
      Eric Dumazet 提交于
      Remove the artificial HZ latency on arp resolution.
      
      Instead of firing a timer in one jiffy (up to 10 ms if HZ=100), lets
      send the ARP message immediately.
      
      Before patch :
      
      # arp -d 192.168.20.108 ; ping -c 3 192.168.20.108
      PING 192.168.20.108 (192.168.20.108) 56(84) bytes of data.
      64 bytes from 192.168.20.108: icmp_seq=1 ttl=64 time=9.91 ms
      64 bytes from 192.168.20.108: icmp_seq=2 ttl=64 time=0.065 ms
      64 bytes from 192.168.20.108: icmp_seq=3 ttl=64 time=0.061 ms
      
      After patch :
      
      $ arp -d 192.168.20.108 ; ping -c 3 192.168.20.108
      PING 192.168.20.108 (192.168.20.108) 56(84) bytes of data.
      64 bytes from 192.168.20.108: icmp_seq=1 ttl=64 time=0.152 ms
      64 bytes from 192.168.20.108: icmp_seq=2 ttl=64 time=0.064 ms
      64 bytes from 192.168.20.108: icmp_seq=3 ttl=64 time=0.074 ms
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cd28ca0a
  33. 18 7月, 2011 1 次提交