Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 27 6月, 2017 2 次提交
  3. 13 6月, 2017 2 次提交
  5. 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
  7. 22 5月, 2017 1 次提交
  9. 18 5月, 2017 1 次提交
  11. 28 4月, 2017 2 次提交
  13. 27 4月, 2017 2 次提交
  15. 13 4月, 2017 4 次提交
  17. 05 4月, 2017 1 次提交
  19. 21 3月, 2017 2 次提交
  21. 28 2月, 2017 1 次提交
  23. 07 2月, 2017 1 次提交
  25. 31 1月, 2017 4 次提交
  27. 20 1月, 2017 1 次提交
  29. 17 1月, 2017 3 次提交
    • R
      brcmfmac: setup wiphy bands after registering it first · ab99063f
      由 Rafał Miłecki 提交于 
      During bands setup we disable all channels that firmware doesn't support
in the current regulatory setup. If we do this before wiphy_register
it will result in copying set flags (including IEEE80211_CHAN_DISABLED)
to the orig_flags which is supposed to be persistent. We don't want this
as regulatory change may result in enabling some channels. We shouldn't
mess with orig_flags then (by changing them or ignoring them) so it's
better to just take care of their proper values.

This patch cleanups code a bit (by taking orig_flags more seriously) and
allows further improvements like disabling really unavailable channels.
We will need that e.g. if some frequencies should be disabled for good
due to hardware setup (design).
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Acked-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      ab99063f
    • R
      brcmfmac: don't preset all channels as disabled · 9ea0c307
      由 Rafał Miłecki 提交于 
      During init we take care of regulatory stuff by disabling all
unavailable channels (see brcmf_construct_chaninfo) so this predisabling
them is not really required (and this patch won't change any behavior).
It will on the other hand allow more detailed runtime control over
channels which is the main reason for this change.
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      9ea0c307
    • R
      brcmfmac: avoid writing channel out of allocated array · 77c0d0cd
      由 Rafał Miłecki 提交于 
      Our code was assigning number of channels to the index variable by
default. If firmware reported channel we didn't predict this would
result in using that initial index value and writing out of array. This
never happened so far (we got a complete list of supported channels) but
it means possible memory corruption so we should handle it anyway.

This patch simply detects unexpected channel and ignores it.

As we don't try to create new entry now, it's also safe to drop hw_value
and center_freq assignment. For known channels we have these set anyway.

I decided to fix this issue by assigning NULL or a target channel to the
channel variable. This was one of possible ways, I prefefred this one as
it also avoids using channel[index] over and over.

Fixes: 58de92d2 ("brcmfmac: use static superset of channels for wiphy bands")
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Acked-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      77c0d0cd
  31. 30 12月, 2016 1 次提交
  33. 20 12月, 2016 1 次提交
  35. 29 11月, 2016 9 次提交
  37. 23 11月, 2016 1 次提交