1. 26 5月, 2009 1 次提交
  2. 22 5月, 2009 1 次提交
  3. 21 5月, 2009 2 次提交
    • E
      net: fix rtable leak in net/ipv4/route.c · 1ddbcb00
      Eric Dumazet 提交于
      Alexander V. Lukyanov found a regression in 2.6.29 and made a complete
      analysis found in http://bugzilla.kernel.org/show_bug.cgi?id=13339
      Quoted here because its a perfect one :
      
      begin_of_quotation
       2.6.29 patch has introduced flexible route cache rebuilding. Unfortunately the
       patch has at least one critical flaw, and another problem.
      
       rt_intern_hash calculates rthi pointer, which is later used for new entry
       insertion. The same loop calculates cand pointer which is used to clean the
       list. If the pointers are the same, rtable leak occurs, as first the cand is
       removed then the new entry is appended to it.
      
       This leak leads to unregister_netdevice problem (usage count > 0).
      
       Another problem of the patch is that it tries to insert the entries in certain
       order, to facilitate counting of entries distinct by all but QoS parameters.
       Unfortunately, referencing an existing rtable entry moves it to list beginning,
       to speed up further lookups, so the carefully built order is destroyed.
      
       For the first problem the simplest patch it to set rthi=0 when rthi==cand, but
       it will also destroy the ordering.
      end_of_quotation
      
      Problematic commit is 1080d709
      (net: implement emergency route cache rebulds when gc_elasticity is exceeded)
      
      Trying to keep dst_entries ordered is too complex and breaks the fact that
      order should depend on the frequency of use for garbage collection.
      
      A possible fix is to make rt_intern_hash() simpler, and only makes
      rt_check_expire() a litle bit smarter, being able to cope with an arbitrary
      entries order. The added loop is running on cache hot data, while cpu
      is prefetching next object, so should be unnoticied.
      Reported-and-analyzed-by: NAlexander V. Lukyanov <lav@yar.ru>
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1ddbcb00
    • E
      net: fix length computation in rt_check_expire() · cf8da764
      Eric Dumazet 提交于
      rt_check_expire() computes average and standard deviation of chain lengths,
      but not correclty reset length to 0 at beginning of each chain.
      This probably gives overflows for sum2 (and sum) on loaded machines instead
      of meaningful results.
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cf8da764
  4. 19 5月, 2009 2 次提交
  5. 18 5月, 2009 1 次提交
    • C
      ipconfig: handle case of delayed DHCP server · 2513dfb8
      Chris Friesen 提交于
      If a DHCP server is delayed, it's possible for the client to receive the 
      DHCPOFFER after it has already sent out a new DHCPDISCOVER message from 
      a second interface.  The client then sends out a DHCPREQUEST from the 
      second interface, but the server doesn't recognize the device and 
      rejects the request.
      
      This patch simply tracks the current device being configured and throws 
      away the OFFER if it is not intended for the current device.  A more 
      sophisticated approach would be to put the OFFER information into the 
      struct ic_device rather than storing it globally.
      Signed-off-by: NChris Friesen <cfriesen@nortel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2513dfb8
  6. 09 5月, 2009 1 次提交
  7. 05 5月, 2009 1 次提交
  8. 29 4月, 2009 1 次提交
  9. 27 4月, 2009 1 次提交
    • A
      ipv4: Limit size of route cache hash table · c9503e0f
      Anton Blanchard 提交于
      Right now we have no upper limit on the size of the route cache hash table.
      On a 128GB POWER6 box it ends up as 32MB:
      
          IP route cache hash table entries: 4194304 (order: 9, 33554432 bytes)
      
      It would be nice to cap this for memory consumption reasons, but a massive
      hashtable also causes a significant spike when measuring OS jitter.
      
      With a 32MB hashtable and 4 million entries, rt_worker_func is taking
      5 ms to complete. On another system with more memory it's taking 14 ms.
      Even though rt_worker_func does call cond_sched() to limit its impact,
      in an HPC environment we want to keep all sources of OS jitter to a minimum.
      
      With the patch applied we limit the number of entries to 512k which
      can still be overriden by using the rt_entries boot option:
      
          IP route cache hash table entries: 524288 (order: 6, 4194304 bytes)
      
      With this patch rt_worker_func now takes 0.460 ms on the same system.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Acked-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c9503e0f
  10. 20 4月, 2009 1 次提交
  11. 17 4月, 2009 2 次提交
  12. 14 4月, 2009 1 次提交
  13. 11 4月, 2009 1 次提交
    • V
      ipv6: Fix NULL pointer dereference with time-wait sockets · 499923c7
      Vlad Yasevich 提交于
      Commit b2f5e7cd
      (ipv6: Fix conflict resolutions during ipv6 binding)
      introduced a regression where time-wait sockets were
      not treated correctly.  This resulted in the following:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000062
      IP: [<ffffffff805d7d61>] ipv4_rcv_saddr_equal+0x61/0x70
      ...
      Call Trace:
      [<ffffffffa033847b>] ipv6_rcv_saddr_equal+0x1bb/0x250 [ipv6]
      [<ffffffffa03505a8>] inet6_csk_bind_conflict+0x88/0xd0 [ipv6]
      [<ffffffff805bb18e>] inet_csk_get_port+0x1ee/0x400
      [<ffffffffa0319b7f>] inet6_bind+0x1cf/0x3a0 [ipv6]
      [<ffffffff8056d17c>] ? sockfd_lookup_light+0x3c/0xd0
      [<ffffffff8056ed49>] sys_bind+0x89/0x100
      [<ffffffff80613ea2>] ? trace_hardirqs_on_thunk+0x3a/0x3c
      [<ffffffff8020bf9b>] system_call_fastpath+0x16/0x1b
      Tested-by: NBrian Haley <brian.haley@hp.com>
      Tested-by: NEd Tomlinson <edt@aei.ca>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      499923c7
  14. 03 4月, 2009 2 次提交
  15. 02 4月, 2009 1 次提交
  16. 01 4月, 2009 1 次提交
  17. 28 3月, 2009 2 次提交
    • P
      netlabel: Label incoming TCP connections correctly in SELinux · 389fb800
      Paul Moore 提交于
      The current NetLabel/SELinux behavior for incoming TCP connections works but
      only through a series of happy coincidences that rely on the limited nature of
      standard CIPSO (only able to convey MLS attributes) and the write equality
      imposed by the SELinux MLS constraints.  The problem is that network sockets
      created as the result of an incoming TCP connection were not on-the-wire
      labeled based on the security attributes of the parent socket but rather based
      on the wire label of the remote peer.  The issue had to do with how IP options
      were managed as part of the network stack and where the LSM hooks were in
      relation to the code which set the IP options on these newly created child
      sockets.  While NetLabel/SELinux did correctly set the socket's on-the-wire
      label it was promptly cleared by the network stack and reset based on the IP
      options of the remote peer.
      
      This patch, in conjunction with a prior patch that adjusted the LSM hook
      locations, works to set the correct on-the-wire label format for new incoming
      connections through the security_inet_conn_request() hook.  Besides the
      correct behavior there are many advantages to this change, the most significant
      is that all of the NetLabel socket labeling code in SELinux now lives in hooks
      which can return error codes to the core stack which allows us to finally get
      ride of the selinux_netlbl_inode_permission() logic which greatly simplfies
      the NetLabel/SELinux glue code.  In the process of developing this patch I
      also ran into a small handful of AF_INET6 cleanliness issues that have been
      fixed which should make the code safer and easier to extend in the future.
      Signed-off-by: NPaul Moore <paul.moore@hp.com>
      Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      389fb800
    • P
      lsm: Relocate the IPv4 security_inet_conn_request() hooks · 284904aa
      Paul Moore 提交于
      The current placement of the security_inet_conn_request() hooks do not allow
      individual LSMs to override the IP options of the connection's request_sock.
      This is a problem as both SELinux and Smack have the ability to use labeled
      networking protocols which make use of IP options to carry security attributes
      and the inability to set the IP options at the start of the TCP handshake is
      problematic.
      
      This patch moves the IPv4 security_inet_conn_request() hooks past the code
      where the request_sock's IP options are set/reset so that the LSM can safely
      manipulate the IP options as needed.  This patch intentionally does not change
      the related IPv6 hooks as IPv6 based labeling protocols which use IPv6 options
      are not currently implemented, once they are we will have a better idea of
      the correct placement for the IPv6 hooks.
      Signed-off-by: NPaul Moore <paul.moore@hp.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      284904aa
  18. 26 3月, 2009 4 次提交
  19. 25 3月, 2009 2 次提交
  20. 24 3月, 2009 1 次提交
    • V
      udp: Wrong locking code in udp seq_file infrastructure · 30842f29
      Vitaly Mayatskikh 提交于
      Reading zero bytes from /proc/net/udp or other similar files which use
      the same seq_file udp infrastructure panics kernel in that way:
      
      =====================================
      [ BUG: bad unlock balance detected! ]
      -------------------------------------
      read/1985 is trying to release lock (&table->hash[i].lock) at:
      [<ffffffff81321d83>] udp_seq_stop+0x27/0x29
      but there are no more locks to release!
      
      other info that might help us debug this:
      1 lock held by read/1985:
       #0:  (&p->lock){--..}, at: [<ffffffff810eefb6>] seq_read+0x38/0x348
      
      stack backtrace:
      Pid: 1985, comm: read Not tainted 2.6.29-rc8 #9
      Call Trace:
       [<ffffffff81321d83>] ? udp_seq_stop+0x27/0x29
       [<ffffffff8106dab9>] print_unlock_inbalance_bug+0xd6/0xe1
       [<ffffffff8106db62>] lock_release_non_nested+0x9e/0x1c6
       [<ffffffff810ef030>] ? seq_read+0xb2/0x348
       [<ffffffff8106bdba>] ? mark_held_locks+0x68/0x86
       [<ffffffff81321d83>] ? udp_seq_stop+0x27/0x29
       [<ffffffff8106dde7>] lock_release+0x15d/0x189
       [<ffffffff8137163c>] _spin_unlock_bh+0x1e/0x34
       [<ffffffff81321d83>] udp_seq_stop+0x27/0x29
       [<ffffffff810ef239>] seq_read+0x2bb/0x348
       [<ffffffff810eef7e>] ? seq_read+0x0/0x348
       [<ffffffff8111aedd>] proc_reg_read+0x90/0xaf
       [<ffffffff810d878f>] vfs_read+0xa6/0x103
       [<ffffffff8106bfac>] ? trace_hardirqs_on_caller+0x12f/0x153
       [<ffffffff810d88a2>] sys_read+0x45/0x69
       [<ffffffff8101123a>] system_call_fastpath+0x16/0x1b
      BUG: scheduling while atomic: read/1985/0xffffff00
      INFO: lockdep is turned off.
      Modules linked in: cpufreq_ondemand acpi_cpufreq freq_table dm_multipath kvm ppdev snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi_event arc4 snd_s
      eq ecb thinkpad_acpi snd_seq_device iwl3945 hwmon sdhci_pci snd_pcm_oss sdhci rfkill mmc_core snd_mixer_oss i2c_i801 mac80211 yenta_socket ricoh_mmc i2c_core iTCO_wdt snd_pcm iTCO_vendor_support rs
      rc_nonstatic snd_timer snd lib80211 cfg80211 soundcore snd_page_alloc video parport_pc output parport e1000e [last unloaded: scsi_wait_scan]
      Pid: 1985, comm: read Not tainted 2.6.29-rc8 #9
      Call Trace:
       [<ffffffff8106b456>] ? __debug_show_held_locks+0x1b/0x24
       [<ffffffff81043660>] __schedule_bug+0x7e/0x83
       [<ffffffff8136ede9>] schedule+0xce/0x838
       [<ffffffff810d7972>] ? fsnotify_access+0x5f/0x67
       [<ffffffff810112d0>] ? sysret_careful+0xb/0x37
       [<ffffffff8106be9c>] ? trace_hardirqs_on_caller+0x1f/0x153
       [<ffffffff8137127b>] ? trace_hardirqs_on_thunk+0x3a/0x3f
       [<ffffffff810112f6>] sysret_careful+0x31/0x37
      read[1985]: segfault at 7fffc479bfe8 ip 0000003e7420a180 sp 00007fffc479bfa0 error 6
      Kernel panic - not syncing: Aiee, killing interrupt handler!
      
      udp_seq_stop() tries to unlock not yet locked spinlock. The lock was lost
      during splitting global udp_hash_lock to subsequent spinlocks.
      
      Signed-off by: Vitaly Mayatskikh <v.mayatskih@gmail.com>
      Acked-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      30842f29
  21. 23 3月, 2009 1 次提交
  22. 22 3月, 2009 1 次提交
  23. 19 3月, 2009 2 次提交
  24. 16 3月, 2009 7 次提交