1. 09 9月, 2014 18 次提交
  2. 29 8月, 2014 2 次提交
    • M
      net: rfkill: gpio: Add more Broadcom bluetooth ACPI IDs · d0616613
      Mika Westerberg 提交于
      This adds one more ACPI ID of a Broadcom bluetooth chip.
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d0616613
    • M
      mac80211: fix chantype recalc warning · a00f4f6e
      Michal Kazior 提交于
      When a device driver is unloaded local->interfaces
      list is cleared. If there was more than 1
      interface running and connected (bound to a
      chanctx) then chantype recalc was called and it
      ended up with compat being NULL causing a call
      trace warning.
      
      Warn if compat becomes NULL as a result of
      incompatible bss_conf.chandef of interfaces bound
      to a given channel context only.
      
      The call trace looked like this:
      
       WARNING: CPU: 2 PID: 2594 at /devel/src/linux/net/mac80211/chan.c:557 ieee80211_recalc_chanctx_chantype+0x2cd/0x2e0()
       Modules linked in: ath10k_pci(-) ath10k_core ath
       CPU: 2 PID: 2594 Comm: rmmod Tainted: G        W     3.16.0-rc1+ #150
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
        0000000000000009 ffff88001ea279c0 ffffffff818dfa93 0000000000000000
        ffff88001ea279f8 ffffffff810514a8 ffff88001ce09cd0 ffff88001e03cc58
        0000000000000000 ffff88001ce08840 ffff88001ce09cd0 ffff88001ea27a08
       Call Trace:
        [<ffffffff818dfa93>] dump_stack+0x4d/0x66
        [<ffffffff810514a8>] warn_slowpath_common+0x78/0xa0
        [<ffffffff81051585>] warn_slowpath_null+0x15/0x20
        [<ffffffff818a407d>] ieee80211_recalc_chanctx_chantype+0x2cd/0x2e0
        [<ffffffff818a3dda>] ? ieee80211_recalc_chanctx_chantype+0x2a/0x2e0
        [<ffffffff818a4919>] ieee80211_assign_vif_chanctx+0x1a9/0x770
        [<ffffffff818a6220>] __ieee80211_vif_release_channel+0x70/0x130
        [<ffffffff818a6dd3>] ieee80211_vif_release_channel+0x43/0xb0
        [<ffffffff81885f4e>] ieee80211_stop_ap+0x21e/0x5a0
        [<ffffffff8184b9b5>] __cfg80211_stop_ap+0x85/0x520
        [<ffffffff8181c188>] __cfg80211_leave+0x68/0x120
        [<ffffffff8181c268>] cfg80211_leave+0x28/0x40
        [<ffffffff8181c5f3>] cfg80211_netdev_notifier_call+0x373/0x6b0
        [<ffffffff8107f965>] notifier_call_chain+0x55/0x110
        [<ffffffff8107fa41>] raw_notifier_call_chain+0x11/0x20
        [<ffffffff816a8dc0>] call_netdevice_notifiers_info+0x30/0x60
        [<ffffffff816a8eb9>] __dev_close_many+0x59/0xf0
        [<ffffffff816a9021>] dev_close_many+0x81/0x120
        [<ffffffff816aa1c5>] rollback_registered_many+0x115/0x2a0
        [<ffffffff816aa3a6>] unregister_netdevice_many+0x16/0xa0
        [<ffffffff8187d841>] ieee80211_remove_interfaces+0x121/0x1b0
        [<ffffffff8185e0e6>] ieee80211_unregister_hw+0x56/0x110
        [<ffffffffa0011ac4>] ath10k_mac_unregister+0x14/0x60 [ath10k_core]
        [<ffffffffa0014fe7>] ath10k_core_unregister+0x27/0x40 [ath10k_core]
        [<ffffffffa003b1f4>] ath10k_pci_remove+0x44/0xa0 [ath10k_pci]
        [<ffffffff81373138>] pci_device_remove+0x28/0x60
        [<ffffffff814cb534>] __device_release_driver+0x64/0xd0
        [<ffffffff814cbcc8>] driver_detach+0xb8/0xc0
        [<ffffffff814cb23a>] bus_remove_driver+0x4a/0xb0
        [<ffffffff814cc697>] driver_unregister+0x27/0x50
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      a00f4f6e
  3. 27 8月, 2014 1 次提交
  4. 26 8月, 2014 17 次提交
  5. 23 8月, 2014 2 次提交
    • M
      mac80211: fix channel switch for chanctx-based drivers · 47e4df94
      Michal Kazior 提交于
      The new_ctx pointer is set only for non-chanctx drivers.  This yielded a
      crash for chanctx-based drivers during channel switch finalization:
      
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
        IP: ieee80211_vif_use_reserved_switch+0x71c/0xb00 [mac80211]
      
      Use an adequate chanctx pointer to fix this.
      Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      47e4df94
    • D
      net: sctp: fix suboptimal edge-case on non-active active/retrans path selection · aa4a83ee
      Daniel Borkmann 提交于
      In SCTP, selection of active (T.ACT) and retransmission (T.RET)
      transports is being done whenever transport control operations
      (UP, DOWN, PF, ...) are engaged through sctp_assoc_control_transport().
      
      Commits 4c47af4d ("net: sctp: rework multihoming retransmission
      path selection to rfc4960") and a7288c4d ("net: sctp: improve
      sctp_select_active_and_retran_path selection") have both improved
      it towards a more fine-grained and optimal path selection.
      
      Currently, the selection algorithm for T.ACT and T.RET is as follows:
      
      1) Elect the two most recently used ACTIVE transports T1, T2 for
         T.ACT, T.RET, where T.ACT<-T1 and T1 is most recently used
      2) In case primary path T.PRI not in {T1, T2} but ACTIVE, set
         T.ACT<-T.PRI and T.RET<-T1
      3) If only T1 is ACTIVE from the set, set T.ACT<-T1 and T.RET<-T1
      4) If none is ACTIVE, set T.ACT<-best(T.PRI, T.RET, T3) where
         T3 is the most recently used (if avail) in PF, set T.RET<-T.PRI
      
      Prior to above commits, 4) was simply a camp on T.ACT<-T.PRI and
      T.RET<-T.PRI, ignoring possible paths in PF. Camping on T.PRI is
      still slightly suboptimal as it can lead to the following scenario:
      
      Setup:
              <A>                                <B>
          T1: p1p1 (10.0.10.10) <==>  .'`)  <==> p1p1 (10.0.10.12)  <= T.PRI
          T2: p1p2 (10.0.10.20) <==> (_ . ) <==> p1p2 (10.0.10.22)
      
          net.sctp.rto_min = 1000
          net.sctp.path_max_retrans = 2
          net.sctp.pf_retrans = 0
          net.sctp.hb_interval = 1000
      
      T.PRI is permanently down, T2 is put briefly into PF state (e.g. due to
      link flapping). Here, the first time transmission is sent over PF path
      T2 as it's the only non-INACTIVE path, but the retransmitted data-chunks
      are sent over the INACTIVE path T1 (T.PRI), which is not good.
      
      After the patch, it's choosing better transports in both cases by
      modifying step 4):
      
      4) If none is ACTIVE, set T.ACT_new<-best(T.ACT_old, T3) where T3 is
         the most recently used (if avail) in PF, set T.RET<-T.ACT_new
      
      This will still select a best possible path in PF if available (which
      can also include T.PRI/T.RET), and set both T.ACT/T.RET to it.
      
      In case sctp_assoc_control_transport() *just* put T.ACT_old into INACTIVE
      as it transitioned from ACTIVE->PF->INACTIVE and stays in INACTIVE just
      for a very short while before going back ACTIVE, it will guarantee that
      this path will be reselected for T.ACT/T.RET since T3 (PF) is not
      available.
      
      Previously, this was not possible, as we would only select between T.PRI
      and T.RET, and a possible T3 would be NULL due to the fact that we have
      just transitioned T3 in sctp_assoc_control_transport() from PF->INACTIVE
      and would select a suboptimal path when T.PRI/T.RET have worse properties.
      
      In the case that T.ACT_old permanently went to INACTIVE during this
      transition and there's no PF path available, plus T.PRI and T.RET are
      INACTIVE as well, we would now camp on T.ACT_old, but if everything is
      being INACTIVE there's really not much we can do except hoping for a
      successful HB to bring one of the transports back up again and, thus
      cause a new selection through sctp_assoc_control_transport().
      
      Now both tests work fine:
      
      Case 1:
      
       1. T1 S(ACTIVE) T.ACT
          T2 S(ACTIVE) T.RET
      
       2. T1 S(ACTIVE) T.ACT, T.RET
          T2 S(PF)
      
       3. T1 S(ACTIVE) T.ACT, T.RET
          T2 S(INACTIVE)
      
       5. T1 S(PF) T.ACT, T.RET
          T2 S(INACTIVE)
      
      [ 5.1 T1 S(INACTIVE) T.ACT, T.RET
            T2 S(INACTIVE) ]
      
       6. T1 S(ACTIVE) T.ACT, T.RET
          T2 S(INACTIVE)
      
       7. T1 S(ACTIVE) T.ACT
          T2 S(ACTIVE) T.RET
      
      Case 2:
      
       1. T1 S(ACTIVE) T.ACT
          T2 S(ACTIVE) T.RET
      
       2. T1 S(PF)
          T2 S(ACTIVE) T.ACT, T.RET
      
       3. T1 S(INACTIVE)
          T2 S(ACTIVE) T.ACT, T.RET
      
       5. T1 S(INACTIVE)
          T2 S(PF) T.ACT, T.RET
      
      [ 5.1 T1 S(INACTIVE)
            T2 S(INACTIVE) T.ACT, T.RET ]
      
       6. T1 S(INACTIVE)
          T2 S(ACTIVE) T.ACT, T.RET
      
       7. T1 S(ACTIVE) T.ACT
          T2 S(ACTIVE) T.RET
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Acked-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aa4a83ee
新手
引导
客服 返回
顶部