1. 10 Jul, 2009 31 commits
  2. 09 Jul, 2009 1 commit
    • Jiri Olsa's avatar
      net: adding memory barrier to the poll and receive callbacks · a57de0b4
      Jiri Olsa authored
      Adding memory barrier after the poll_wait function, paired with
      receive callbacks. Adding fuctions sock_poll_wait and sk_has_sleeper
      to wrap the memory barrier.
      Without the memory barrier, following race can happen.
      The race fires, when following code paths meet, and the tp->rcv_nxt
      and __add_wait_queue updates stay in CPU caches.
      CPU1                         CPU2
      sys_select                   receive packet
        ...                        ...
        __add_wait_queue           update tp->rcv_nxt
        ...                        ...
        tp->rcv_nxt check          sock_def_readable
        ...                        {
        schedule                      ...
                                      if (sk->sk_sleep && waitqueue_active(sk->sk_sleep))
      If there was no cache the code would work ok, since the wait_queue and
      rcv_nxt are opposit to each other.
      Meaning that once tp->rcv_nxt is updated by CPU2, the CPU1 either already
      passed the tp->rcv_nxt check and sleeps, or will get the new value for
      tp->rcv_nxt and will return with new data mask.
      In both cases the process (CPU1) is being added to the wait queue, so the
      waitqueue_active (CPU2) call cannot miss and will wake up CPU1.
      The bad case is when the __add_wait_queue changes done by CPU1 stay in its
      cache, and so does the tp->rcv_nxt update on CPU2 side.  The CPU1 will then
      endup calling schedule and sleep forever if there are no more data on the
      Calls to poll_wait in following modules were ommited:
      Signed-off-by: default avatarJiri Olsa <jolsa@redhat.com>
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  3. 08 Jul, 2009 3 commits
    • Anton Vorontsov's avatar
      netpoll: Fix carrier detection for drivers that are using phylib · 1b614fb9
      Anton Vorontsov authored
      Using early netconsole and gianfar driver this error pops up:
        netconsole: timeout waiting for carrier
      It appears that net/core/netpoll.c:netpoll_setup() is using
      cond_resched() in a loop waiting for a carrier.
      The thing is that cond_resched() is a no-op when system_state !=
      SYSTEM_RUNNING, and so drivers/net/phy/phy.c's state_queue is never
      scheduled, therefore link detection doesn't work.
      I belive that the main problem is in cond_resched()[1], but despite
      how the cond_resched() story ends, it might be a good idea to call
      msleep(1) instead of cond_resched(), as suggested by Andrew Morton.
      [1] http://lkml.org/lkml/2009/7/7/463
      Signed-off-by: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • 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>
    • Jarek Poplawski's avatar
      ipv4: Fix fib_trie rebalancing, part 4 (root thresholds) · 345aa031
      Jarek Poplawski authored
      Pawel Staszewski wrote:
      Some time ago i report this:
      and now with 2.6.29 / / 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.
              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
      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
      Pawel's report:
      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.
              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
      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>
  4. 07 Jul, 2009 4 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>
    • 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>
    • 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
      [ 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>
    • 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
      Signed-off-by: default avatarJiri Slaby <jirislaby@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  5. 06 Jul, 2009 1 commit