1. 10 Jul, 2009 22 commits
  2. 09 Jul, 2009 1 commit
  3. 08 Jul, 2009 2 commits
    • Anton Vorontsov's avatar
      netpoll: Introduce netpoll_carrier_timeout kernel option · bff38771
      Anton Vorontsov authored
      
      
      Some PHYs require longer timeouts for carrier detection, and
      auto-negotiation process may take indefinite amount of time.
      
      It may be inconvenient to force longer timeouts for sane PHYs,
      so let's introduce a kernel command line option.
      
      Since we're using module_param(), the option also can be
      changed in runtime.
      Signed-off-by: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bff38771
    • Jarek Poplawski's avatar
      ipv4: Fix fib_trie rebalancing, part 4 (root thresholds) · 345aa031
      Jarek Poplawski authored
      Pawel Staszewski wrote:
      <blockquote>
      Some time ago i report this:
      http://bugzilla.kernel.org/show_bug.cgi?id=6648
      
      and now with 2.6.29 / 2.6.29.1 / 2.6.29.3 and 2.6.30 it back
      dmesg output:
      oprofile: using NMI interrupt.
      Fix inflate_threshold_root. Now=15 size=11 bits
      ...
      Fix inflate_threshold_root. Now=15 size=11 bits
      
      cat /proc/net/fib_triestat
      Basic info: size of leaf: 40 bytes, size of tnode: 56 bytes.
      Main:
              Aver depth:     2.28
              Max depth:      6
              Leaves:         276539
              Prefixes:       289922
              Internal nodes: 66762
                1: 35046  2: 13824  3: 9508  4: 4897  5: 2331  6: 1149  7: 5
      9: 1  18: 1
              Pointers: 691228
      Null ptrs: 347928
      Total size: 35709  kB
      </blockquote>
      
      It seems, the current threshold for root resizing is too aggressive,
      and it causes misleading warnings during big updates, but it might be
      also responsible for memory problems, especially with non-preempt
      configs, when RCU freeing is delayed long after call_rcu.
      
      It should be also mentioned that because of non-atomic changes during
      resizing/rebalancing the current lookup algorithm can miss valid leaves
      so it's additional argument to shorten these activities even at a cost
      of a minimally longer searching.
      
      This patch restores values before the patch "[IPV4]: fib_trie root
      node settings", commit: 965ffea4
      
       from
      v2.6.22.
      
      Pawel's report:
      <blockquote>
      I dont see any big change of (cpu load or faster/slower
      routing/propagating routes from bgpd or something else) - in avg there
      is from 2% to 3% more of CPU load i dont know why but it is - i change
      from "preempt" to "no preempt" 3 times and check this my "mpstat -P ALL
      1 30"
      always avg cpu load was from 2 to 3% more compared to "no preempt"
      [...]
      cat /proc/net/fib_triestat
      Basic info: size of leaf: 20 bytes, size of tnode: 36 bytes.
      Main:
              Aver depth:     2.44
              Max depth:      6
              Leaves:         277814
              Prefixes:       291306
              Internal nodes: 66420
                1: 32737  2: 14850  3: 10332  4: 4871  5: 2313  6: 942  7: 371  8: 3  17: 1
              Pointers: 599098
      Null ptrs: 254865
      Total size: 18067  kB
      </blockquote>
      
      According to this and other similar reports average depth is slightly
      increased (~0.2), and root nodes are shorter (log 17 vs. 18), but
      there is no visible performance decrease. So, until memory handling is
      improved or added parameters for changing this individually, this
      patch resets to safer defaults.
      Reported-by: default avatarPawel Staszewski <pstaszewski@itcare.pl>
      Reported-by: default avatarJorge Boncompte [DTI2] <jorge@dti2.net>
      Signed-off-by: default avatarJarek Poplawski <jarkao2@gmail.com>
      Tested-by: default avatarPawel Staszewski <pstaszewski@itcare.pl>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      345aa031
  4. 07 Jul, 2009 6 commits
    • Luciano Coelho's avatar
      mac80211: minstrel: avoid accessing negative indices in rix_to_ndx() · 3938b45c
      Luciano Coelho authored
      
      
      If rix is not found in mi->r[], i will become -1 after the loop.  This value
      is eventually used to access arrays, so we were accessing arrays with a
      negative index, which is obviously not what we want to do.  This patch fixes
      this potential problem.
      Signed-off-by: default avatarLuciano Coelho <luciano.coelho@nokia.com>
      Acked-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3938b45c
    • Johannes Berg's avatar
      cfg80211: fix refcount leak · 2dce4c2b
      Johannes Berg authored
      
      
      The code in cfg80211's cfg80211_bss_update erroneously
      grabs a reference to the BSS, which means that it will
      never be freed.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Cc: stable@kernel.org [2.6.29, 2.6.30]
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2dce4c2b
    • Andrey Yurovsky's avatar
      mac80211: fix allocation in mesh_queue_preq · 59615b5f
      Andrey Yurovsky authored
      
      
      We allocate a PREQ queue node in mesh_queue_preq, however the allocation
      may cause us to sleep.  Use GFP_ATOMIC to prevent this.
      
      [ 1869.126498] BUG: scheduling while atomic: ping/1859/0x10000100
      [ 1869.127164] Modules linked in: ath5k mac80211 ath
      [ 1869.128310] Pid: 1859, comm: ping Not tainted 2.6.30-wl #1
      [ 1869.128754] Call Trace:
      [ 1869.129293]  [<c1023a2b>] __schedule_bug+0x48/0x4d
      [ 1869.129866]  [<c13b5533>] __schedule+0x77/0x67a
      [ 1869.130544]  [<c1026f2e>] ? release_console_sem+0x17d/0x185
      [ 1869.131568]  [<c807cf47>] ? mesh_queue_preq+0x2b/0x165 [mac80211]
      [ 1869.132318]  [<c13b5b3e>] schedule+0x8/0x1f
      [ 1869.132807]  [<c1023c12>] __cond_resched+0x16/0x2f
      [ 1869.133478]  [<c13b5bf0>] _cond_resched+0x27/0x32
      [ 1869.134191]  [<c108a370>] kmem_cache_alloc+0x1c/0xcf
      [ 1869.134714]  [<c10273ae>] ? printk+0x15/0x17
      [ 1869.135670]  [<c807cf47>] mesh_queue_preq+0x2b/0x165 [mac80211]
      [ 1869.136731]  [<c807d1f8>] mesh_nexthop_lookup+0xee/0x12d [mac80211]
      [ 1869.138130]  [<c807417e>] ieee80211_xmit+0xe6/0x2b2 [mac80211]
      [ 1869.138935]  [<c80be46d>] ? ath5k_hw_setup_rx_desc+0x0/0x66 [ath5k]
      [ 1869.139831]  [<c80c97bc>] ? ath5k_tasklet_rx+0xba/0x506 [ath5k]
      [ 1869.140863]  [<c8075191>] ieee80211_subif_start_xmit+0x6c9/0x6e4
      [mac80211]
      [ 1869.141665]  [<c105cf1c>] ? handle_level_irq+0x78/0x9d
      [ 1869.142390]  [<c12e3f93>] dev_hard_start_xmit+0x168/0x1c7
      [ 1869.143092]  [<c12f1f17>] __qdisc_run+0xe1/0x1b7
      [ 1869.143612]  [<c12e25ff>] qdisc_run+0x18/0x1a
      [ 1869.144248]  [<c12e62f4>] dev_queue_xmit+0x16a/0x25a
      [ 1869.144785]  [<c13b6dcc>] ? _read_unlock_bh+0xe/0x10
      [ 1869.145465]  [<c12eacdb>] neigh_resolve_output+0x19c/0x1c7
      [ 1869.146182]  [<c130e2da>] ? ip_finish_output+0x0/0x51
      [ 1869.146697]  [<c130e2a0>] ip_finish_output2+0x182/0x1bc
      [ 1869.147358]  [<c130e327>] ip_finish_output+0x4d/0x51
      [ 1869.147863]  [<c130e9d5>] ip_output+0x80/0x85
      [ 1869.148515]  [<c130cc49>] dst_output+0x9/0xb
      [ 1869.149141]  [<c130dec6>] ip_local_out+0x17/0x1a
      [ 1869.149632]  [<c130e0bc>] ip_push_pending_frames+0x1f3/0x255
      [ 1869.150343]  [<c13247ff>] raw_sendmsg+0x5e6/0x667
      [ 1869.150883]  [<c1033c55>] ? insert_work+0x6a/0x73
      [ 1869.151834]  [<c8071e00>] ?
      ieee80211_invoke_rx_handlers+0x17da/0x1ae8 [mac80211]
      [ 1869.152630]  [<c132bd68>] inet_sendmsg+0x3b/0x48
      [ 1869.153232]  [<c12d7deb>] __sock_sendmsg+0x45/0x4e
      [ 1869.153740]  [<c12d8537>] sock_sendmsg+0xb8/0xce
      [ 1869.154519]  [<c80be46d>] ? ath5k_hw_setup_rx_desc+0x0/0x66 [ath5k]
      [ 1869.155289]  [<c1036b25>] ? autoremove_wake_function+0x0/0x30
      [ 1869.155859]  [<c115992b>] ? __copy_from_user_ll+0x11/0xce
      [ 1869.156573]  [<c1159d99>] ? copy_from_user+0x31/0x54
      [ 1869.157235]  [<c12df646>] ? verify_iovec+0x40/0x6e
      [ 1869.157778]  [<c12d869a>] sys_sendmsg+0x14d/0x1a5
      [ 1869.158714]  [<c8072c40>] ? __ieee80211_rx+0x49e/0x4ee [mac80211]
      [ 1869.159641]  [<c80c83fe>] ? ath5k_rxbuf_setup+0x6d/0x8d [ath5k]
      [ 1869.160543]  [<c80be46d>] ? ath5k_hw_setup_rx_desc+0x0/0x66 [ath5k]
      [ 1869.161434]  [<c80beba4>] ? ath5k_hw_get_rxdp+0xe/0x10 [ath5k]
      [ 1869.162319]  [<c80c97bc>] ? ath5k_tasklet_rx+0xba/0x506 [ath5k]
      [ 1869.163063]  [<c1005627>] ? enable_8259A_irq+0x40/0x43
      [ 1869.163594]  [<c101edb8>] ? __dequeue_entity+0x23/0x27
      [ 1869.164793]  [<c100187a>] ? __switch_to+0x2b/0x105
      [ 1869.165442]  [<c1021d5f>] ? finish_task_switch+0x5b/0x74
      [ 1869.166129]  [<c12d963a>] sys_socketcall+0x14b/0x17b
      [ 1869.166612]  [<c1002b95>] syscall_call+0x7/0xb
      Signed-off-by: default avatarAndrey Yurovsky <andrey@cozybit.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      59615b5f
    • Jiri Slaby's avatar
      Wireless: nl80211, fix lock imbalance · 1f5fc70a
      Jiri Slaby authored
      
      
      Don't forget to unlock cfg80211_mutex in one fail path of
      nl80211_set_wiphy.
      Signed-off-by: default avatarJiri Slaby <jirislaby@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      1f5fc70a
    • Mark Smith's avatar
    • Mark Smith's avatar
      ipv6: correct return on ipv6_rcv() packet drop · 5c91face
      Mark Smith authored
      
      
      The routine ipv6_rcv() uses magic number 0 for a return when it drops a
      packet. This corresponds to NET_RX_SUCCESS, which is obviously
      incorrect. Correct this by using NET_RX_DROP instead.
      
      ps. It isn't exactly clear who the IPv6 maintainers are, apologies if
      I've missed any.
      Signed-off-by: default avatarMark Smith <markzzzsmith@yahoo.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5c91face
  5. 06 Jul, 2009 7 commits
  6. 04 Jul, 2009 2 commits
    • Brian Haley's avatar
      IPv6: preferred lifetime of address not getting updated · a1ed0526
      Brian Haley authored
      
      
      There's a bug in addrconf_prefix_rcv() where it won't update the
      preferred lifetime of an IPv6 address if the current valid lifetime
      of the address is less than 2 hours (the minimum value in the RA).
      
      For example, If I send a router advertisement with a prefix that
      has valid lifetime = preferred lifetime = 2 hours we'll build
      this address:
      
      3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
          inet6 2001:1890:1109:a20:217:8ff:fe7d:4718/64 scope global dynamic
             valid_lft 7175sec preferred_lft 7175sec
      
      If I then send the same prefix with valid lifetime = preferred
      lifetime = 0 it will be ignored since the minimum valid lifetime
      is 2 hours:
      
      3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
          inet6 2001:1890:1109:a20:217:8ff:fe7d:4718/64 scope global dynamic
             valid_lft 7161sec preferred_lft 7161sec
      
      But according to RFC 4862 we should always reset the preferred lifetime
      even if the valid lifetime is invalid, which would cause the address
      to immediately get deprecated.  So with this patch we'd see this:
      
      5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
          inet6 2001:1890:1109:a20:21f:29ff:fe5a:ef04/64 scope global deprecated dynamic
             valid_lft 7163sec preferred_lft 0sec
      
      The comment winds-up being 5x the size of the code to fix the problem.
      
      Update the preferred lifetime of IPv6 addresses derived from a prefix
      info option in a router advertisement even if the valid lifetime in
      the option is invalid, as specified in RFC 4862 Section 5.5.3e.  Fixes
      an issue where an address will not immediately become deprecated.
      Reported by Jens Rosenboom.
      Signed-off-by: default avatarBrian Haley <brian.haley@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a1ed0526
    • Wei Yongjun's avatar
      xfrm6: fix the proto and ports decode of sctp protocol · 59cae009
      Wei Yongjun authored
      
      
      The SCTP pushed the skb above the sctp chunk header, so the
      check of pskb_may_pull(skb, nh + offset + 1 - skb->data) in
      _decode_session6() will never return 0 and the ports decode
      of sctp will always fail. (nh + offset + 1 - skb->data < 0)
      Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      59cae009