1. 10 Jun, 2017 1 commit
  2. 09 Jun, 2017 14 commits
  3. 08 Jun, 2017 21 commits
  4. 07 Jun, 2017 4 commits
    • 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
    • Daniel Borkmann's avatar
      bpf, arm64: use separate register for state in stxr · 7005cade
      Daniel Borkmann authored
      Will reported that in BPF_XADD we must use a different register in stxr
      instruction for the status flag due to otherwise CONSTRAINED UNPREDICTABLE
      behavior per architecture. Reference manual says [1]:
      
        If s == t, then one of the following behaviors must occur:
      
         * The instruction is UNDEFINED.
         * The instruction executes as a NOP.
         * The instruction performs the store to the specified address, but
           the value stored is UNKNOWN.
      
      Thus, use a different temporary register for the status flag to fix it.
      
      Disassembly extract from test 226/STX_XADD_DW from test_bpf.ko:
      
        [...]
        0000003c:  c85f7d4b  ldxr x11, [x10]
        00000040:  8b07016b  add x11, x11, x7
        00000044:  c80c7d4b  stxr w12, x11, [x10]
        00000048:  35ffffac  cbnz w12, 0x0000003c
        [...]
      
        [1] https://static.docs.arm.com/ddi0487/b/DDI0487B_a_armv8_arm.pdf, p.6132
      
      Fixes: 85f68fe8 ("bpf, arm64: implement jiting of BPF_XADD")
      Reported-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7005cade
    • Antoine Ténart's avatar
      net: mvpp2: do not bypass the mvpp22_port_mii_set function · e173db36
      Antoine Ténart authored
      The mvpp22_port_mii_set() function was added by 26975821, but the
      function directly returns without doing anything. This return was used
      when debugging and wasn't removed before sending the patch. Fix this.
      
      Fixes: 26975821 ("net: mvpp2: handle misc PPv2.1/PPv2.2 differences")
      Signed-off-by: default avatarAntoine Tenart <antoine.tenart@free-electrons.com>
      Acked-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e173db36
    • John Allen's avatar
      ibmvnic: Return failure on attempted mtu change · 3a807b75
      John Allen authored
      Changing the mtu is currently not supported in the ibmvnic driver.
      
      Implement .ndo_change_mtu in the driver so that attempting to use ifconfig
      to change the mtu will fail and present the user with an error message.
      Signed-off-by: default avatarJohn Allen <jallen@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3a807b75