1. 08 1月, 2015 3 次提交
  2. 07 1月, 2015 2 次提交
    • I
      mac80211: Re-fix accounting of the tailroom-needed counter · db12847c
      Ido Yariv 提交于
      When hw acceleration is enabled, the GENERATE_IV or PUT_IV_SPACE flags
      only require headroom space. Therefore, the tailroom-needed counter can
      safely be decremented for most drivers.
      
      The older incarnation of this patch (ca34e3b5) assumed that the above
      holds true for all drivers. As reported by Christopher Chavez and
      researched by Christian Lamparter and Larry Finger, this isn't a valid
      assumption for p54 and cw1200.
      
      Drivers that still require tailroom for ICV/MIC even when HW encryption
      is enabled can use IEEE80211_KEY_FLAG_RESERVE_TAILROOM to indicate it.
      Signed-off-by: NIdo Yariv <idox.yariv@intel.com>
      Cc: Christopher Chavez <chrischavez@gmx.us>
      Cc: Christian Lamparter <chunkeey@googlemail.com>
      Cc: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Solomon Peachy <pizza@shaftnet.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      db12847c
    • J
      Merge branch 'mac80211' into mac80211-next · 3a4b0c94
      Johannes Berg 提交于
      Merge mac80211.git to get some changes that would otherwise
      cause conflicts with new changes coming here.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      3a4b0c94
  3. 06 1月, 2015 3 次提交
  4. 05 1月, 2015 2 次提交
  5. 23 12月, 2014 1 次提交
  6. 22 12月, 2014 1 次提交
  7. 20 12月, 2014 1 次提交
  8. 18 12月, 2014 3 次提交
  9. 17 12月, 2014 13 次提交
  10. 15 12月, 2014 2 次提交
  11. 12 12月, 2014 9 次提交
    • S
      mac80211: Fix accounting of multicast frames · 5cf16616
      Sujith Manoharan 提交于
      Since multicast frames are marked as no-ack, using
      IEEE80211_TX_STAT_ACK to check if they have been
      successfully transmitted by the driver is incorrect
      since a driver can choose to ignore transmission status
      for no-ack frames. This results in incorrect accounting
      for such frames.
      
      To fix this issue, this patch introduces a new flag
      that can be used by drivers to indicate error-free
      transmission of no-ack frames.
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      [add a note about not setting the flag for non-no-ack frames]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      5cf16616
    • S
      mac80211: Move IEEE80211_TX_CTL_PS_RESPONSE · 6b127c71
      Sujith Manoharan 提交于
      Move IEEE80211_TX_CTL_PS_RESPONSE to info->control.flags since
      this is used only in the TX path (by ath9k). This frees up
      a bit which can be used for other purposes.
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6b127c71
    • V
      wireless: Support of IFLA_INFO_KIND rtnl attribute · ba1debdf
      Vadim Kochan 提交于
      It allows to identify the wlan kind of device for the user application,
      e.g.:
      
          # ip -d link
      
          1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
              link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0
          2: enp0s25: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
              link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff promiscuity 0
          3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
              link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff promiscuity 0
              wlan
      Signed-off-by: NVadim Kochan <vadim4j@gmail.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      [make wireless_link_ops const]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      ba1debdf
    • A
      cfg80211: correctly check ad-hoc channels · 185076d6
      Arik Nemtsov 提交于
      Ad-hoc requires beaconing for regulatory purposes. Validate that the
      channel is valid for beaconing, and not only enabled.
      Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
      Reviewed-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      185076d6
    • E
      cfg80211: don't WARN about two consecutive Country IE hint · 70dcec5a
      Emmanuel Grumbach 提交于
      This can happen and there is no point in added more
      detection code lower in the stack. Catching these in one
      single point (cfg80211) is enough. Stop WARNING about this
      case.
      
      This fixes:
      https://bugzilla.kernel.org/show_bug.cgi?id=89001
      
      Cc: stable@vger.kernel.org
      Fixes: 2f1c6c57 ("cfg80211: process non country IE conflicting first")
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      70dcec5a
    • E
      mac80211: update the channel context after channel switch · 722ddb0d
      Emmanuel Grumbach 提交于
      When the channel switch has been made, a vif is now using
      the channel context which was reserved. When that happens,
      we need to update the channel context since its parameters
      may change.
      
      I hit a case in which I switched to a 40Mhz channel but the
      reserved channel context was still on 20Mhz. The rate control
      would try to send 40Mhz packets on a 20Mhz channel context and
      that made iwlwifi's firmware unhappy.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      722ddb0d
    • L
      nl80211: check matches array length before acessing it · f89f46cf
      Luciano Coelho 提交于
      If the userspace passes a malformed sched scan request (or a net
      detect wowlan configuration) by adding a NL80211_ATTR_SCHED_SCAN_MATCH
      attribute without any nested matchsets, a NULL pointer dereference
      will occur.  Fix this by checking that we do have matchsets in our
      array before trying to access it.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000024
      IP: [<ffffffffa002fd69>] nl80211_parse_sched_scan.part.67+0x6e9/0x900 [cfg80211]
      PGD 865c067 PUD 865b067 PMD 0
      Oops: 0002 [#1] SMP
      Modules linked in: iwlmvm(O) iwlwifi(O) mac80211(O) cfg80211(O) compat(O) [last unloaded: compat]
      CPU: 2 PID: 2442 Comm: iw Tainted: G           O   3.17.2 #31
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      task: ffff880013800790 ti: ffff880008d80000 task.ti: ffff880008d80000
      RIP: 0010:[<ffffffffa002fd69>]  [<ffffffffa002fd69>] nl80211_parse_sched_scan.part.67+0x6e9/0x900 [cfg80211]
      RSP: 0018:ffff880008d838d0  EFLAGS: 00010293
      RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
      RDX: 000000000000143c RSI: 0000000000000000 RDI: ffff880008ee8dd0
      RBP: ffff880008d83948 R08: 0000000000000002 R09: 0000000000000019
      R10: ffff88001d1b3c40 R11: 0000000000000002 R12: ffff880019e85e00
      R13: 00000000fffffed4 R14: ffff880009757800 R15: 0000000000001388
      FS:  00007fa3b6d13700(0000) GS:ffff88003e200000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000024 CR3: 0000000008670000 CR4: 00000000000006e0
      Stack:
       ffff880009757800 ffff880000000001 0000000000000000 ffff880008ee84e0
       0000000000000000 ffff880009757800 00000000fffffed4 ffff880008d83948
       ffffffff814689c9 ffff880009757800 ffff880008ee8000 0000000000000000
      Call Trace:
       [<ffffffff814689c9>] ? nla_parse+0xb9/0x120
       [<ffffffffa00306de>] nl80211_set_wowlan+0x75e/0x960 [cfg80211]
       [<ffffffff810bf3d5>] ? mark_held_locks+0x75/0xa0
       [<ffffffff8161a77b>] genl_family_rcv_msg+0x18b/0x360
       [<ffffffff810bf66d>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff8161a9d4>] genl_rcv_msg+0x84/0xc0
       [<ffffffff8161a950>] ? genl_family_rcv_msg+0x360/0x360
       [<ffffffff81618e79>] netlink_rcv_skb+0xa9/0xd0
       [<ffffffff81619458>] genl_rcv+0x28/0x40
       [<ffffffff816184a5>] netlink_unicast+0x105/0x180
       [<ffffffff8161886f>] netlink_sendmsg+0x34f/0x7a0
       [<ffffffff8105a097>] ? kvm_clock_read+0x27/0x40
       [<ffffffff815c644d>] sock_sendmsg+0x8d/0xc0
       [<ffffffff811a75c9>] ? might_fault+0xb9/0xc0
       [<ffffffff811a756e>] ? might_fault+0x5e/0xc0
       [<ffffffff815d5d26>] ? verify_iovec+0x56/0xe0
       [<ffffffff815c73e0>] ___sys_sendmsg+0x3d0/0x3e0
       [<ffffffff810a7be8>] ? sched_clock_cpu+0x98/0xd0
       [<ffffffff810611b4>] ? __do_page_fault+0x254/0x580
       [<ffffffff810bb39f>] ? up_read+0x1f/0x40
       [<ffffffff810611b4>] ? __do_page_fault+0x254/0x580
       [<ffffffff812146ed>] ? __fget_light+0x13d/0x160
       [<ffffffff815c7b02>] __sys_sendmsg+0x42/0x80
       [<ffffffff815c7b52>] SyS_sendmsg+0x12/0x20
       [<ffffffff81751f69>] system_call_fastpath+0x16/0x1b
      
      Fixes: ea73cbce ("nl80211: fix scheduled scan RSSI matchset attribute confusion")
      Cc: stable@vger.kernel.org [3.15+]
      Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f89f46cf
    • J
      cfg80211: use __force __rcu to suppress sparse warning · cec3f0ed
      Johannes Berg 提交于
      The code assigns a constant value (a pointer to a static variable)
      to an RCU pointer, which results in a sparse warning:
        reg.c:112:10: warning: cast adds address space to expression (<asn:4>)
      
      Suppress this warning by using __force.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      cec3f0ed
    • A
      cfg80211: avoid mem leak on driver hint set · 34f05f54
      Arik Nemtsov 提交于
      In the already-set and intersect case of a driver-hint, the previous
      wiphy regdomain was not freed before being reset with a copy of the
      cfg80211 regdomain.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
      Acked-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      34f05f54