Skip to content
Snippets Groups Projects
  1. Sep 07, 2021
  2. May 30, 2019
  3. Jun 07, 2017
    • David S. Miller's avatar
      net: Fix inconsistent teardown and release of private netdev state. · cf124db5
      David S. Miller authored
      
      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: default avatarDavid S. Miller <davem@davemloft.net>
      cf124db5
  4. Sep 19, 2016
  5. Sep 30, 2015
    • Alexander Aring's avatar
      ieee802154: change mtu size behaviour · b40988c4
      Alexander Aring authored
      
      This patch changes the mtu size of 802.15.4 interfaces. The current
      setting is the meaning of the maximum transport unit with mac header,
      which is 127 bytes according 802.15.4. The linux meaning of the mtu size
      field is the maximum payload of a mac frame. Like in ethernet, which is
      1500 bytes.
      
      We have dynamic length of mac frames in 802.15.4, this is why we assume
      the minimum header length which is hard_header_len. This contains fc and
      sequence fields. These can evaluated by driver layer without additional
      checks. We currently don't support to set the FCS from userspace, so we
      need to subtract this from mtu size as well.
      
      Signed-off-by: default avatarAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      b40988c4
  6. Sep 24, 2015
  7. Sep 22, 2015
    • Alexander Aring's avatar
      ieee802154: change needed headroom/tailroom · 87a93e4e
      Alexander Aring authored
      
      This patch cleanups needed_headroom, needed_tailroom and hard_header_len
      fields for wpan and lowpan interfaces.
      
      For wpan interfaces the worst case mac header len should be part of
      needed_headroom, currently this is set as hard_header_len, but
      hard_header_len should be set to the minimum header length which xmit
      call assumes and this is the minimum frame length of 802.15.4.
      The hard_header_len value will check inside send callbacl of AF_PACKET
      raw sockets.
      
      For lowpan interfaces, if fragmentation isn't needed the skb will
      call dev_hard_header for 802154 layer and queue it afterwards. This
      happens without new skb allocation, so we need the same headroom and
      tailroom lengths like 802154 inside 802154 6lowpan layer. At least we
      assume as minimum header length an ipv6 header size.
      
      Signed-off-by: default avatarAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      87a93e4e
    • Alexander Aring's avatar
      ieee802154: introduce wpan_dev_header_ops · 838b83d6
      Alexander Aring authored
      
      The current header_ops callback structure of net device are used mostly
      from 802.15.4 upper-layers. Because this callback structure is a very
      generic one, which is also used by e.g. DGRAM AF_PACKET sockets, we
      can't make this callback structure 802.15.4 specific which is currently
      is.
      
      I saw the smallest "constraint" for calling this callback with
      dev_hard_header/dev_parse_header by AF_PACKET which assign a 8 byte
      array for address void pointers. Currently 802.15.4 specific protocols
      like af802154 and 6LoWPAN will assign the "struct ieee802154_addr" as
      these parameters which is greater than 8 bytes. The current callback
      implementation for header_ops.create assumes always a complete
      "struct ieee802154_addr" which AF_PACKET can't never handled and is
      greater than 8 bytes.
      
      For that reason we introduce now a "generic" create/parse header_ops
      callback which allows handling with intra-pan extended addresses only.
      This allows a small use-case with AF_PACKET to send "somehow" a valid
      dataframe over DGRAM.
      
      To keeping the current dev_hard_header behaviour we introduce a similar
      callback structure "wpan_dev_header_ops" which contains 802.15.4 specific
      upper-layer header creation functionality, which can be called by
      wpan_dev_hard_header.
      
      Signed-off-by: default avatarAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      838b83d6
  8. Aug 10, 2015
    • Alexander Aring's avatar
      mac802154: change frame_retries behaviour · 89c7d788
      Alexander Aring authored
      
      This patch changes the default minimum value of frame_retries to 0 and
      changes the frame_retries default value to 3 which is also 802.15.4
      default.
      
      We don't use the frame_retries "-1" value as indicator for no-aret mode
      anymore, instead we checking on the ack request bit inside the 802.15.4
      frame control field. This allows a acknowledge handling per frame. This
      checking is done by transceiver or inside xmit callback of driver layer.
      
      If a transceiver doesn't support ARET handling the transmit
      functionality ignores ack frames then, which isn't well but should not
      effect anything of current functionality.
      
      Reviewed-by: default avatarStefan Schmidt <stefan@osg.samsung.com>
      Signed-off-by: default avatarAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      89c7d788
    • Alexander Aring's avatar
      mac802154: fix wpan mac setting while lowpan is there · 09095fdc
      Alexander Aring authored
      
      If we currently change the mac address inside the wpan interface while
      we have a lowpan interface on top of the wpan interface, the mac address
      setting doesn't reach the lowpan interface. The effect would be that the
      IPv6 lowpan interface has the old SLAAC address and isn't working
      anymore because the lowpan interface use in internal mechanism sometimes
      dev->addr which is the old mac address of the wpan interface.
      
      This patch checks if a wpan interface belongs to lowpan interface, if
      yes then we need to check if the lowpan interface is down and change the
      mac address also at the lowpan interface. When the lowpan interface will
      be set up afterwards, it will use the correct SLAAC address which based
      on the updated mac address setting.
      
      Reviewed-by: default avatarStefan Schmidt <stefan@osg.samsung.com>
      Tested-by: default avatarStefan Schmidt <stefan@osg.samsung.com>
      Signed-off-by: default avatarAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      09095fdc
  9. Jul 23, 2015
  10. Jun 17, 2015
  11. Jun 14, 2015
  12. Jun 09, 2015
  13. Jun 07, 2015
  14. May 31, 2015
  15. May 26, 2015
  16. May 23, 2015
  17. Apr 30, 2015
  18. Mar 27, 2015
  19. Dec 19, 2014
  20. Nov 26, 2014
  21. Nov 17, 2014
  22. Nov 13, 2014
    • Alexander Aring's avatar
      mac802154: add interframe spacing time handling · 61f2dcba
      Alexander Aring authored
      
      This patch adds a new interframe spacing time handling into mac802154
      layer. Interframe spacing time is a time period between each transmit.
      This patch adds a high resolution timer into mac802154 and starts on
      xmit complete with corresponding interframe spacing expire time if
      ifs_handling is true. We make it variable because it depends if
      interframe spacing time is handled by transceiver or mac802154. At the
      timer complete function we wake the netdev queue again. This avoids
      new frame transmit in range of interframe spacing time.
      
      For synced driver we add no handling of interframe spacing time. This
      is currently a lack of support in all synced xmit drivers. I suppose
      it's working because the latency of workqueue which is needed to call
      spi_sync.
      
      Signed-off-by: default avatarAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      61f2dcba
  23. Nov 12, 2014
  24. Nov 09, 2014
Loading