1. 22 5月, 2010 2 次提交
    • R
      iwlwifi: fix internal scan race · 073d5eab
      Reinette Chatre 提交于
      It is possible for internal scan to race against itself if the device is
      not returning the scan results from first requests. What happens in this
      case is the cleanup done during the abort of the first internal scan also
      cleans up part of the new scan, causing it to access memory it shouldn't.
      
      Here are details:
      * First internal scan is triggered and scan command sent to device.
      * After seven seconds there is no scan results so the watchdog timer
        triggers a scan abort.
      * The scan abort succeeds and a SCAN_COMPLETE_NOTIFICATION is received for
       failed scan.
      * During processing of SCAN_COMPLETE_NOTIFICATION we clear STATUS_SCANNING
        and queue the "scan_completed" work.
      ** At this time, since the problem that caused the internal scan in first
         place is still present, a new internal scan is triggered.
      The behavior at this point is a bit different between 2.6.34 and 2.6.35
      since 2.6.35 has a lot of this synchronized. The rest of the race
      description will thus be generalized.
      ** As part of preparing for the scan "is_internal_short_scan" is set to
      true.
      * At this point the completion work for fist scan is run. As part of this
        there is some locking missing around the "is_internal_short_scan"
        variable and it is set to "false".
      ** Now the second scan runs and it considers itself a real (not internal0
         scan and thus causes problems with wrong memory being accessed.
      
      The fix is twofold.
      * Since "is_internal_short_scan" should be protected by mutex, fix this in
        scan completion work so that changes to it can be serialized.
      * Do not queue a new internal scan if one is in progress.
      
      This fixes https://bugzilla.kernel.org/show_bug.cgi?id=15824Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      073d5eab
    • S
      cfg80211: Fix signal_type comparison · 22fe88d3
      Sujith 提交于
      signal_type is enum cfg80211_signal_type.
      
      This fixes the gcc warning:
      
      scan.c: In function `cfg80211_inform_bss':
      scan.c:518:6: warning: comparison between `enum cfg80211_signal_type' and `enum nl80211_bss'
      scan.c: In function `cfg80211_inform_bss_frame':
      scan.c:574:6: warning: comparison between `enum cfg80211_signal_type' and `enum nl80211_bss'
      Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      22fe88d3
  2. 21 5月, 2010 38 次提交