1. 19 Dec, 2018 16 commits
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 3061169a
      David S. Miller authored
      Alexei Starovoitov says:
      
      ====================
      pull-request: bpf 2018-12-18
      
      The following pull-request contains BPF updates for your *net* tree.
      
      The main changes are:
      
      1) promote bpf_perf_event.h to mandatory UAPI header, from Masahiro.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3061169a
    • Myungho Jung's avatar
      net/smc: fix TCP fallback socket release · 78abe3d0
      Myungho Jung authored
      clcsock can be released while kernel_accept() references it in TCP
      listen worker. Also, clcsock needs to wake up before released if TCP
      fallback is used and the clcsock is blocked by accept. Add a lock to
      safely release clcsock and call kernel_sock_shutdown() to wake up
      clcsock from accept in smc_release().
      
      Reported-by: syzbot+0bf2e01269f1274b4b03@syzkaller.appspotmail.com
      Reported-by: syzbot+e3132895630f957306bc@syzkaller.appspotmail.com
      Signed-off-by: default avatarMyungho Jung <mhjungk@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      78abe3d0
    • Colin Ian King's avatar
      vxge: ensure data0 is initialized in when fetching firmware version information · f7db2beb
      Colin Ian King authored
      Currently variable data0 is not being initialized so a garbage value is
      being passed to vxge_hw_vpath_fw_api and this value is being written to
      the rts_access_steer_data0 register.  There are other occurrances where
      data0 is being initialized to zero (e.g. in function
      vxge_hw_upgrade_read_version) so I think it makes sense to ensure data0
      is initialized likewise to 0.
      
      Detected by CoverityScan, CID#140696 ("Uninitialized scalar variable")
      
      Fixes: 8424e00d ("vxge: serialize access to steering control register")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f7db2beb
    • Juergen Gross's avatar
      xen/netfront: tolerate frags with no data · d81c5054
      Juergen Gross authored
      At least old Xen net backends seem to send frags with no real data
      sometimes. In case such a fragment happens to occur with the frag limit
      already reached the frontend will BUG currently even if this situation
      is easily recoverable.
      
      Modify the BUG_ON() condition accordingly.
      Tested-by: default avatarDietmar Hahn <dietmar.hahn@ts.fujitsu.com>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d81c5054
    • Kunihiko Hayashi's avatar
      net: phy: Fix the issue that netif always links up after resuming · 8742beb5
      Kunihiko Hayashi authored
      Even though the link is down before entering hibernation,
      there is an issue that the network interface always links up after resuming
      from hibernation.
      
      If the link is still down before enabling the network interface,
      and after resuming from hibernation, the phydev->state is forcibly set
      to PHY_UP in mdio_bus_phy_restore(), and the link becomes up.
      
      In suspend sequence, only if the PHY is attached, mdio_bus_phy_suspend()
      calls phy_stop_machine(), and mdio_bus_phy_resume() calls
      phy_start_machine().
      In resume sequence, it's enough to do the same as mdio_bus_phy_resume()
      because the state has been preserved.
      
      This patch fixes the issue by calling phy_start_machine() in
      mdio_bus_phy_restore() in the same way as mdio_bus_phy_resume().
      
      Fixes: bc87922f ("phy: Move PHY PM operations into phy_device")
      Suggested-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarKunihiko Hayashi <hayashi.kunihiko@socionext.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8742beb5
    • Jason Martinsen's avatar
      lan78xx: Resolve issue with changing MAC address · 15515aaa
      Jason Martinsen authored
      Current state for the lan78xx driver does not allow for changing the
      MAC address of the interface, without either removing the module (if
      you compiled it that way) or rebooting the machine.  If you attempt to
      change the MAC address, ifconfig will show the new address, however,
      the system/interface will not respond to any traffic using that
      configuration.  A few short-term options to work around this are to
      unload the module and reload it with the new MAC address, change the
      interface to "promisc", or reboot with the correct configuration to
      change the MAC.
      
      This patch enables the ability to change the MAC address via fairly normal means...
      ifdown <interface>
      modify entry in /etc/network/interfaces OR a similar method
      ifup <interface>
      Then test via any network communication, such as ICMP requests to gateway.
      
      My only test platform for this patch has been a raspberry pi model 3b+.
      Signed-off-by: default avatarJason Martinsen <jasonmartinsen@msn.com>
      
      -----
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      15515aaa
    • Bryan Whitehead's avatar
      lan743x: Expand phy search for LAN7431 · 0db7d253
      Bryan Whitehead authored
      The LAN7431 uses an external phy, and it can be found anywhere in
      the phy address space. This patch uses phy address 1 for LAN7430
      only. And searches all addresses otherwise.
      Signed-off-by: default avatarBryan Whitehead <Bryan.Whitehead@microchip.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0db7d253
    • David S. Miller's avatar
      Merge branch 'vxlan-Various-fixes' · 59fc137e
      David S. Miller authored
      Petr Machata says:
      
      ====================
      vxlan: Various fixes
      
      This patch set contains three fixes for the vxlan driver.
      
      Patch #1 fixes handling of offload mark on replaced VXLAN FDB entries. A
      way to trigger this is to replace the FDB entry with one that can not be
      offloaded. A future patch set should make it possible to veto such FDB
      changes. However the FDB might still fail to be offloaded due to another
      issue, and the offload mark should reflect that.
      
      Patch #2 fixes problems in __vxlan_dev_create() when a call to
      rtnl_configure_link() fails. These failures would be tricky to hit on a
      real system, the most likely vector is through an error in vxlan_open().
      However, with the abovementioned vetoing patchset, vetoing the created
      entry would trigger the same problems (and be easier to reproduce).
      
      Patch #3 fixes a problem in vxlan_changelink(). In situations where the
      default remote configured in the FDB table (if any) does not exactly
      match the remote address configured at the VXLAN device, changing the
      remote address breaks the default FDB entry. Patch #4 is then a self
      test for this issue.
      
      v3:
      - Patch #2:
          - Reuse the same errout block for both cleanup paths. Use a bool to
            decide whether the unregister_netdevice() call should be made.
      
      v2:
      - Drop former patch #3
      - Patch #2:
          - Delete the default entry before calling unregister_netdevice(). That
            takes care of former patch #3, hence tweak the commit message to
            mention that problem as well.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      59fc137e
    • Petr Machata's avatar
      selftests: net: Add test_vxlan_fdb_changelink.sh · 55cbe079
      Petr Machata authored
      Add a test to exercise the fix from the previous patch.
      Signed-off-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      55cbe079
    • Petr Machata's avatar
      vxlan: changelink: Fix handling of default remotes · ce5e098f
      Petr Machata authored
      Default remotes are stored as FDB entries with an Ethernet address of
      00:00:00:00:00:00. When a request is made to change a remote address of
      a VXLAN device, vxlan_changelink() first deletes the existing default
      remote, and then creates a new FDB entry.
      
      This works well as long as the list of default remotes matches exactly
      the configuration of a VXLAN remote address. Thus when the VXLAN device
      has a remote of X, there should be exactly one default remote FDB entry
      X. If the VXLAN device has no remote address, there should be no such
      entry.
      
      Besides using "ip link set", it is possible to manipulate the list of
      default remotes by using the "bridge fdb". It is therefore easy to break
      the above condition. Under such circumstances, the __vxlan_fdb_delete()
      call doesn't delete the FDB entry itself, but just one remote. The
      following vxlan_fdb_create() then creates a new FDB entry, leading to a
      situation where two entries exist for the address 00:00:00:00:00:00,
      each with a different subset of default remotes.
      
      An even more obvious breakage rooted in the same cause can be observed
      when a remote address is configured for a VXLAN device that did not have
      one before. In that case vxlan_changelink() doesn't remove any remote,
      and just creates a new FDB entry for the new address:
      
      $ ip link add name vx up type vxlan id 2000 dstport 4789
      $ bridge fdb ap dev vx 00:00:00:00:00:00 dst 192.0.2.20 self permanent
      $ bridge fdb ap dev vx 00:00:00:00:00:00 dst 192.0.2.30 self permanent
      $ ip link set dev vx type vxlan remote 192.0.2.30
      $ bridge fdb sh dev vx | grep 00:00:00:00:00:00
      00:00:00:00:00:00 dst 192.0.2.30 self permanent <- new entry, 1 rdst
      00:00:00:00:00:00 dst 192.0.2.20 self permanent <- orig. entry, 2 rdsts
      00:00:00:00:00:00 dst 192.0.2.30 self permanent
      
      To fix this, instead of calling vxlan_fdb_create() directly, defer to
      vxlan_fdb_update(). That has logic to handle the duplicates properly.
      Additionally, it also handles notifications, so drop that call from
      changelink as well.
      
      Fixes: 0241b836 ("vxlan: fix default fdb entry netlink notify ordering during netdev create")
      Signed-off-by: default avatarPetr Machata <petrm@mellanox.com>
      Acked-by: default avatarRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ce5e098f
    • Petr Machata's avatar
      vxlan: Fix error path in __vxlan_dev_create() · 6db92468
      Petr Machata authored
      When a failure occurs in rtnl_configure_link(), the current code
      calls unregister_netdevice() to roll back the earlier call to
      register_netdevice(), and jumps to errout, which calls
      vxlan_fdb_destroy().
      
      However unregister_netdevice() calls transitively ndo_uninit, which is
      vxlan_uninit(), and that already takes care of deleting the default FDB
      entry by calling vxlan_fdb_delete_default(). Since the entry added
      earlier in __vxlan_dev_create() is exactly the default entry, the
      cleanup code in the errout block always leads to double free and thus a
      panic.
      
      Besides, since vxlan_fdb_delete_default() always destroys the FDB entry
      with notification enabled, the deletion of the default entry is notified
      even before the addition was notified.
      
      Instead, move the unregister_netdevice() call after the manual destroy,
      which solves both problems.
      
      Fixes: 0241b836 ("vxlan: fix default fdb entry netlink notify ordering during netdev create")
      Signed-off-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6db92468
    • Petr Machata's avatar
      vxlan: Unmark offloaded bit on replaced FDB entries · 6ad0b5a4
      Petr Machata authored
      When rdst of an offloaded FDB entry is replaced, it certainly isn't
      offloaded anymore. Drivers are notified about such replacements, and can
      re-mark the entry as offloaded again if they so wish. However until a
      driver does so explicitly, assume a replaced FDB entry is not offloaded.
      
      Note that replaces coming via vxlan_fdb_external_learn_add() are always
      immediately followed by an explicit offload marking.
      
      Fixes: 0efe1173 ("vxlan: Support marking RDSTs as offloaded")
      Signed-off-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6ad0b5a4
    • David S. Miller's avatar
      Merge branch 'macb-DMA-race-fixes' · a9d6d897
      David S. Miller authored
      Anssi Hannula says:
      
      ====================
      net: macb: DMA race condition fixes
      
      Here are a couple of race condition fixes for the macb driver. The first
      two are for issues observed at runtime on real HW.
      
      v2:
      - added received Tested-bys and Acked-bys to the first two patches
      - in patch 3/3, moved the timestamp protection barrier closer to the
        timestamp reads
      - in patch 3/3, removed unnecessary move of the addr assignment in
        gem_rx() to keep the patch minimal for maximum clarity
      - in patch 3/3, clarified commit message and comments
      
      The 3/3 is the same one I improperly sent last week as a standalone
      patch.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a9d6d897
    • Anssi Hannula's avatar
      net: macb: add missing barriers when reading descriptors · 6e0af298
      Anssi Hannula authored
      When reading buffer descriptors on RX or on TX completion, an
      RX_USED/TX_USED bit is checked first to ensure that the descriptors have
      been populated, i.e. the ownership has been transferred. However, there
      are no memory barriers to ensure that the data protected by the
      RX_USED/TX_USED bit is up-to-date with respect to that bit.
      
      Specifically:
      
      - TX timestamp descriptors may be loaded before ctrl is loaded for the
        TX_USED check, which is racy as the descriptors may be updated between
        the loads, causing old timestamp descriptor data to be used.
      
      - RX ctrl may be loaded before addr is loaded for the RX_USED check,
        which is racy as a new frame may be written between the loads, causing
        old ctrl descriptor data to be used.
        This issue exists for both macb_rx() and gem_rx() variants.
      
      Fix the races by adding DMA read memory barriers on those paths and
      reordering the reads in macb_rx().
      
      I have not observed any actual problems in practice caused by these
      being missing, though.
      
      Tested on a ZynqMP based system.
      
      Fixes: 89e5785f ("[PATCH] Atmel MACB ethernet driver")
      Signed-off-by: default avatarAnssi Hannula <anssi.hannula@bitwise.fi>
      Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6e0af298
    • Anssi Hannula's avatar
      net: macb: fix dropped RX frames due to a race · 8159ecab
      Anssi Hannula authored
      Bit RX_USED set to 0 in the address field allows the controller to write
      data to the receive buffer descriptor.
      
      The driver does not ensure the ctrl field is ready (cleared) when the
      controller sees the RX_USED=0 written by the driver. The ctrl field might
      only be cleared after the controller has already updated it according to
      a newly received frame, causing the frame to be discarded in gem_rx() due
      to unexpected ctrl field contents.
      
      A message is logged when the above scenario occurs:
      
        macb ff0b0000.ethernet eth0: not whole frame pointed by descriptor
      
      Fix the issue by ensuring that when the controller sees RX_USED=0 the
      ctrl field is already cleared.
      
      This issue was observed on a ZynqMP based system.
      
      Fixes: 4df95131 ("net/macb: change RX path for GEM")
      Signed-off-by: default avatarAnssi Hannula <anssi.hannula@bitwise.fi>
      Tested-by: default avatarClaudiu Beznea <claudiu.beznea@microchip.com>
      Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8159ecab
    • Anssi Hannula's avatar
      net: macb: fix random memory corruption on RX with 64-bit DMA · e100a897
      Anssi Hannula authored
      64-bit DMA addresses are split in upper and lower halves that are
      written in separate fields on GEM. For RX, bit 0 of the address is used
      as the ownership bit (RX_USED). When the RX_USED bit is unset the
      controller is allowed to write data to the buffer.
      
      The driver does not guarantee that the controller already sees the upper
      half when the RX_USED bit is cleared, possibly resulting in the
      controller writing an incoming frame to an address with an incorrect
      upper half and therefore possibly corrupting unrelated system memory.
      
      Fix that by adding the necessary DMA memory barrier between the writes.
      
      This corruption was observed on a ZynqMP based system.
      
      Fixes: fff8019a ("net: macb: Add 64 bit addressing support for GEM")
      Signed-off-by: default avatarAnssi Hannula <anssi.hannula@bitwise.fi>
      Acked-by: default avatarHarini Katakam <harini.katakam@xilinx.com>
      Tested-by: default avatarClaudiu Beznea <claudiu.beznea@microchip.com>
      Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
      Cc: Michal Simek <michal.simek@xilinx.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e100a897
  2. 18 Dec, 2018 16 commits
  3. 17 Dec, 2018 2 commits
  4. 16 Dec, 2018 6 commits