1. 21 7月, 2015 5 次提交
  2. 26 5月, 2015 1 次提交
  3. 09 5月, 2015 1 次提交
  4. 17 3月, 2015 3 次提交
  5. 04 3月, 2015 1 次提交
  6. 03 2月, 2015 1 次提交
  7. 06 12月, 2014 2 次提交
  8. 26 11月, 2014 1 次提交
  9. 26 6月, 2014 3 次提交
  10. 21 6月, 2014 1 次提交
  11. 30 5月, 2014 1 次提交
  12. 23 5月, 2014 1 次提交
  13. 19 5月, 2014 1 次提交
  14. 23 4月, 2014 1 次提交
  15. 15 3月, 2014 1 次提交
  16. 21 2月, 2014 1 次提交
  17. 13 2月, 2014 6 次提交
  18. 12 11月, 2013 1 次提交
  19. 11 10月, 2013 1 次提交
  20. 27 9月, 2013 1 次提交
  21. 24 7月, 2013 2 次提交
  22. 13 6月, 2013 1 次提交
  23. 24 4月, 2013 2 次提交
  24. 09 4月, 2013 1 次提交
    • A
      mwifiex: hold proper locks when accessing ra_list / bss_prio lists · 2716fd7d
      Andreas Fenkart 提交于
      Not locking ra_list when dequeuing packets creates race conditions.
      When adding a packet 'tx_pkts_queued' is modified before setting
      highest_priority_queue. If in-between the main loop starts, it will
      see a packet queued (tx_pkts_queued > 0) but will not find it, since
      max prio is not set yet. Depending on the scheduling, the thread
      trying to add the packet could complete and restore the situation.
      But this is not something to rely on.
      
      Another race condition exists, if a new packet, exceeding current
      max prio is added. If concurrently a packet is dequeued, the newly
      set max prio will be overwritten with the value of the dequeued
      packet. This can occur, because selecting a packet and modifying
      the max prio is not atomic. The result in an infinite loop unless,
      a new packet is added that has at least the priority of the hidden
      packet.
      
      Same applies to bss_prio_tbl. Forward iteration is no proper
      lock-free technique and provides no protection from calls to
      list_del. Although BSS are currently not added/removed dynamically,
      this must not be the case in the future. Hence always hold proper
      locks when accessing those lists.
      Signed-off-by: NAndreas Fenkart <andreas.fenkart@streamunlimited.com>
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2716fd7d