1. 28 7月, 2017 14 次提交
  2. 27 7月, 2017 1 次提交
    • B
      mwifiex: correct channel stat buffer overflows · 4b5dde2d
      Brian Norris 提交于
      mwifiex records information about various channels as it receives scan
      information. It does this by appending to a buffer that was sized
      to the max number of supported channels on any band, but there are
      numerous problems:
      
      (a) scans can return info from more than one band (e.g., both 2.4 and 5
          GHz), so the determined "max" is not large enough
      (b) some firmware appears to return multiple results for a given
          channel, so the max *really* isn't large enough
      (c) there is no bounds checking when stashing these stats, so problems
          (a) and (b) can easily lead to buffer overflows
      
      Let's patch this by setting a slightly-more-correct max (that accounts
      for a combination of both 2.4G and 5G bands) and adding a bounds check
      when writing to our statistics buffer.
      
      Due to problem (b), we still might not properly report all known survey
      information (e.g., with "iw <dev> survey dump"), since duplicate results
      (or otherwise "larger than expected" results) will cause some
      truncation. But that's a problem for a future bugfix.
      
      (And because of this known deficiency, only log the excess at the WARN
      level, since that isn't visible by default in this driver and would
      otherwise be a bit too noisy.)
      
      Fixes: bf354433 ("mwifiex: channel statistics support for mwifiex")
      Cc: <stable@vger.kernel.org>
      Cc: Avinash Patil <patila@marvell.com>
      Cc: Xinming Hu <huxm@marvell.com>
      Signed-off-by: NBrian Norris <briannorris@chromium.org>
      Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Reviewed-by: NGanapathi Bhat <gbhat@marvell.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      4b5dde2d
  3. 03 7月, 2017 1 次提交
  4. 30 6月, 2017 1 次提交
  5. 29 6月, 2017 2 次提交
  6. 21 6月, 2017 2 次提交
    • S
      mwifiex: debugfs: remove redunant check of mwifiex_dfs_dir · 7c26029f
      Shawn Lin 提交于
      debugfs_remove already check mwifiex_dfs_dir, so remove it.
      Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      7c26029f
    • C
      mwifiex: fixes the unexpected be printed log by default · 421ba82c
      Caesar Wang 提交于
      This patch uses WARN level is not printed by default.
      
      In some cases, some boards have always met the unused log be printed as
      follows.
      ...
      [23193.523182] mwifiex_pcie 0000:01:00.0: mwifiex_get_cfp:
      cannot find cfp by band 2    & channel=13 freq=0
      [23378.633684] mwifiex_pcie 0000:01:00.0: mwifiex_get_cfp:
      cannot find cfp by band 2    & channel=13 freq=0
      
      Due to we used the wifi default area was US and didn't support 12~14
      channels. As Frequencies:
      * 2412 MHz [1] (30.0 dBm)
      * 2417 MHz [2] (30.0 dBm)
      * 2422 MHz [3] (30.0 dBm)
      * 2427 MHz [4] (30.0 dBm)
      * 2432 MHz [5] (30.0 dBm)
      * 2437 MHz [6] (30.0 dBm)
      * 2442 MHz [7] (30.0 dBm)
      * 2447 MHz [8] (30.0 dBm)
      * 2452 MHz [9] (30.0 dBm)
      * 2457 MHz [10] (30.0 dBm)
      * 2462 MHz [11] (30.0 dBm)
      * 2467 MHz [12] (disabled)
      * 2472 MHz [13] (disabled)
      * 2484 MHz [14] (disabled)
      
      Also, as the commit 1b499cb7
      ("mwifiex: disable channel filtering feature in firmware"), it proved to
      be a feature to get better scan result from overlapping channel.
      
      Even there could be AP from overlapping channel (might be 12/13/14
      in this case), it will be filtered depend on reg domain rules.
      e.g:
      ...
      if (ch->flags & IEEE80211_CHAN_DISABLED)
              continue;
      
      So it should not been an ERROR, use the WARN level to instead it for now.
      Signed-off-by: NCaesar Wang <wxt@rock-chips.com>
      Acked-by: NXinming Hu <huxm@marvell.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      421ba82c
  7. 16 6月, 2017 3 次提交
    • J
      networking: make skb_put & friends return void pointers · 4df864c1
      Johannes Berg 提交于
      It seems like a historic accident that these return unsigned char *,
      and in many places that means casts are required, more often than not.
      
      Make these functions (skb_put, __skb_put and pskb_put) return void *
      and remove all the casts across the tree, adding a (u8 *) cast only
      where the unsigned char pointer was used directly, all done with the
      following spatch:
      
          @@
          expression SKB, LEN;
          typedef u8;
          identifier fn = { skb_put, __skb_put };
          @@
          - *(fn(SKB, LEN))
          + *(u8 *)fn(SKB, LEN)
      
          @@
          expression E, SKB, LEN;
          identifier fn = { skb_put, __skb_put };
          type T;
          @@
          - E = ((T *)(fn(SKB, LEN)))
          + E = fn(SKB, LEN)
      
      which actually doesn't cover pskb_put since there are only three
      users overall.
      
      A handful of stragglers were converted manually, notably a macro in
      drivers/isdn/i4l/isdn_bsdcomp.c and, oddly enough, one of the many
      instances in net/bluetooth/hci_sock.c. In the former file, I also
      had to fix one whitespace problem spatch introduced.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4df864c1
    • J
      networking: introduce and use skb_put_data() · 59ae1d12
      Johannes Berg 提交于
      A common pattern with skb_put() is to just want to memcpy()
      some data into the new space, introduce skb_put_data() for
      this.
      
      An spatch similar to the one for skb_put_zero() converts many
      of the places using it:
      
          @@
          identifier p, p2;
          expression len, skb, data;
          type t, t2;
          @@
          (
          -p = skb_put(skb, len);
          +p = skb_put_data(skb, data, len);
          |
          -p = (t)skb_put(skb, len);
          +p = skb_put_data(skb, data, len);
          )
          (
          p2 = (t2)p;
          -memcpy(p2, data, len);
          |
          -memcpy(p, data, len);
          )
      
          @@
          type t, t2;
          identifier p, p2;
          expression skb, data;
          @@
          t *p;
          ...
          (
          -p = skb_put(skb, sizeof(t));
          +p = skb_put_data(skb, data, sizeof(t));
          |
          -p = (t *)skb_put(skb, sizeof(t));
          +p = skb_put_data(skb, data, sizeof(t));
          )
          (
          p2 = (t2)p;
          -memcpy(p2, data, sizeof(*p));
          |
          -memcpy(p, data, sizeof(*p));
          )
      
          @@
          expression skb, len, data;
          @@
          -memcpy(skb_put(skb, len), data, len);
          +skb_put_data(skb, data, len);
      
      (again, manually post-processed to retain some comments)
      Reviewed-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59ae1d12
    • J
      networking: convert many more places to skb_put_zero() · b080db58
      Johannes Berg 提交于
      There were many places that my previous spatch didn't find,
      as pointed out by yuan linyu in various patches.
      
      The following spatch found many more and also removes the
      now unnecessary casts:
      
          @@
          identifier p, p2;
          expression len;
          expression skb;
          type t, t2;
          @@
          (
          -p = skb_put(skb, len);
          +p = skb_put_zero(skb, len);
          |
          -p = (t)skb_put(skb, len);
          +p = skb_put_zero(skb, len);
          )
          ... when != p
          (
          p2 = (t2)p;
          -memset(p2, 0, len);
          |
          -memset(p, 0, len);
          )
      
          @@
          type t, t2;
          identifier p, p2;
          expression skb;
          @@
          t *p;
          ...
          (
          -p = skb_put(skb, sizeof(t));
          +p = skb_put_zero(skb, sizeof(t));
          |
          -p = (t *)skb_put(skb, sizeof(t));
          +p = skb_put_zero(skb, sizeof(t));
          )
          ... when != p
          (
          p2 = (t2)p;
          -memset(p2, 0, sizeof(*p));
          |
          -memset(p, 0, sizeof(*p));
          )
      
          @@
          expression skb, len;
          @@
          -memset(skb_put(skb, len), 0, len);
          +skb_put_zero(skb, len);
      
      Apply it to the tree (with one manual fixup to keep the
      comment in vxlan.c, which spatch removed.)
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b080db58
  8. 14 6月, 2017 1 次提交
  9. 13 6月, 2017 2 次提交
  10. 08 6月, 2017 1 次提交
    • D
      net: Fix inconsistent teardown and release of private netdev state. · cf124db5
      David S. Miller 提交于
      Network devices can allocate reasources and private memory using
      netdev_ops->ndo_init().  However, the release of these resources
      can occur in one of two different places.
      
      Either netdev_ops->ndo_uninit() or netdev->destructor().
      
      The decision of which operation frees the resources depends upon
      whether it is necessary for all netdev refs to be released before it
      is safe to perform the freeing.
      
      netdev_ops->ndo_uninit() presumably can occur right after the
      NETDEV_UNREGISTER notifier completes and the unicast and multicast
      address lists are flushed.
      
      netdev->destructor(), on the other hand, does not run until the
      netdev references all go away.
      
      Further complicating the situation is that netdev->destructor()
      almost universally does also a free_netdev().
      
      This creates a problem for the logic in register_netdevice().
      Because all callers of register_netdevice() manage the freeing
      of the netdev, and invoke free_netdev(dev) if register_netdevice()
      fails.
      
      If netdev_ops->ndo_init() succeeds, but something else fails inside
      of register_netdevice(), it does call ndo_ops->ndo_uninit().  But
      it is not able to invoke netdev->destructor().
      
      This is because netdev->destructor() will do a free_netdev() and
      then the caller of register_netdevice() will do the same.
      
      However, this means that the resources that would normally be released
      by netdev->destructor() will not be.
      
      Over the years drivers have added local hacks to deal with this, by
      invoking their destructor parts by hand when register_netdevice()
      fails.
      
      Many drivers do not try to deal with this, and instead we have leaks.
      
      Let's close this hole by formalizing the distinction between what
      private things need to be freed up by netdev->destructor() and whether
      the driver needs unregister_netdevice() to perform the free_netdev().
      
      netdev->priv_destructor() performs all actions to free up the private
      resources that used to be freed by netdev->destructor(), except for
      free_netdev().
      
      netdev->needs_free_netdev is a boolean that indicates whether
      free_netdev() should be done at the end of unregister_netdevice().
      
      Now, register_netdevice() can sanely release all resources after
      ndo_ops->ndo_init() succeeds, by invoking both ndo_ops->ndo_uninit()
      and netdev->priv_destructor().
      
      And at the end of unregister_netdevice(), we invoke
      netdev->priv_destructor() and optionally call free_netdev().
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cf124db5
  11. 01 6月, 2017 2 次提交
  12. 31 5月, 2017 5 次提交
  13. 19 5月, 2017 5 次提交