1. 31 Aug, 2019 7 commits
    • David S. Miller's avatar
      Merge branch 'Dynamic-toggling-of-vlan_filtering-for-SJA1105-DSA' · b0274eb0
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      Dynamic toggling of vlan_filtering for SJA1105 DSA
      
      This patchset addresses a limitation in dsa_8021q where this sequence of
      commands was causing the switch to stop forwarding traffic:
      
        ip link add name br0 type bridge vlan_filtering 0
        ip link set dev swp2 master br0
        echo 1 > /sys/class/net/br0/bridge/vlan_filtering
        echo 0 > /sys/class/net/br0/bridge/vlan_filtering
      
      The issue has to do with the VLAN table manipulations that dsa_8021q
      does without notifying the bridge layer. The solution is to always
      restore the VLANs that the bridge knows about, when disabling tagging.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b0274eb0
    • Vladimir Oltean's avatar
      net: dsa: tag_8021q: Restore bridge VLANs when enabling vlan_filtering · 5f33183b
      Vladimir Oltean authored
      The bridge core assumes that enabling/disabling vlan_filtering will
      translate into the simple toggling of a flag for switchdev drivers.
      
      That is clearly not the case for sja1105, which alters the VLAN table
      and the pvids in order to obtain port separation in standalone mode.
      
      There are 2 parts to the issue.
      
      First, tag_8021q changes the pvid to a unique per-port rx_vid for frame
      identification. But we need to disable tag_8021q when vlan_filtering
      kicks in, and at that point, the VLAN configured as pvid will have to be
      removed from the filtering table of the ports. With an invalid pvid, the
      ports will drop all traffic.  Since the bridge will not call any vlan
      operation through switchdev after enabling vlan_filtering, we need to
      ensure we're in a functional state ourselves. Hence read the pvid that
      the bridge is aware of, and program that into our ports.
      
      Secondly, tag_8021q uses the 1024-3071 range privately in
      vlan_filtering=0 mode. Had the user installed one of these VLANs during
      a previous vlan_filtering=1 session, then upon the next tag_8021q
      cleanup for vlan_filtering to kick in again, VLANs in that range will
      get deleted unconditionally, hence breaking user expectation. So when
      deleting the VLANs, check if the bridge had knowledge about them, and if
      it did, re-apply the settings. Wrap this logic inside a
      dsa_8021q_vid_apply helper function to reduce code duplication.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5f33183b
    • Vladimir Oltean's avatar
      net: bridge: Populate the pvid flag in br_vlan_get_info · f40d9b20
      Vladimir Oltean authored
      Currently this simplified code snippet fails:
      
      	br_vlan_get_pvid(netdev, &pvid);
      	br_vlan_get_info(netdev, pvid, &vinfo);
      	ASSERT(!(vinfo.flags & BRIDGE_VLAN_INFO_PVID));
      
      It is intuitive that the pvid of a netdevice should have the
      BRIDGE_VLAN_INFO_PVID flag set.
      
      However I can't seem to pinpoint a commit where this behavior was
      introduced. It seems like it's been like that since forever.
      
      At a first glance it would make more sense to just handle the
      BRIDGE_VLAN_INFO_PVID flag in __vlan_add_flags. However, as Nikolay
      explains:
      
        There are a few reasons why we don't do it, most importantly because
        we need to have only one visible pvid at any single time, even if it's
        stale - it must be just one. Right now that rule will not be violated
        by this change, but people will try using this flag and could see two
        pvids simultaneously. You can see that the pvid code is even using
        memory barriers to propagate the new value faster and everywhere the
        pvid is read only once.  That is the reason the flag is set
        dynamically when dumping entries, too.  A second (weaker) argument
        against would be given the above we don't want another way to do the
        same thing, specifically if it can provide us with two pvids (e.g. if
        walking the vlan list) or if it can provide us with a pvid different
        from the one set in the vg. [Obviously, I'm talking about RCU
        pvid/vlan use cases similar to the dumps.  The locked cases are fine.
        I would like to avoid explaining why this shouldn't be relied upon
        without locking]
      
      So instead of introducing the above change and making sure of the pvid
      uniqueness under RCU, simply dynamically populate the pvid flag in
      br_vlan_get_info().
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Acked-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f40d9b20
    • David S. Miller's avatar
      Merge tag 'batadv-next-for-davem-20190830' of git://git.open-mesh.org/linux-merge · 5c63592f
      David S. Miller authored
      Simon Wunderlich says:
      
      ====================
      This maintenance patchset includes the following patches:
      
       - Add Sven to the MAINTAINERS file, by Simon Wunderlich
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5c63592f
    • Denis Efremov's avatar
      udp: Remove unlikely() from IS_ERR*() condition · 974ceb21
      Denis Efremov authored
      "unlikely(IS_ERR_OR_NULL(x))" is excessive. IS_ERR_OR_NULL() already uses
      unlikely() internally.
      Signed-off-by: default avatarDenis Efremov <efremov@linux.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Joe Perches <joe@perches.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      974ceb21
    • Denis Efremov's avatar
      net/mlx5e: Remove unlikely() from WARN*() condition · 7cf92ccb
      Denis Efremov authored
      "unlikely(WARN_ON_ONCE(x))" is excessive. WARN_ON_ONCE() already uses
      unlikely() internally.
      Signed-off-by: default avatarDenis Efremov <efremov@linux.com>
      Cc: Boris Pismenny <borisp@mellanox.com>
      Cc: Saeed Mahameed <saeedm@mellanox.com>
      Cc: Leon Romanovsky <leon@kernel.org>
      Cc: Joe Perches <joe@perches.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: netdev@vger.kernel.org
      Acked-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7cf92ccb
    • Michael Chan's avatar
      bnxt_en: Fix compile error regression with CONFIG_BNXT_SRIOV not set. · e72cb7d6
      Michael Chan authored
      Add a new function bnxt_get_registered_vfs() to handle the work
      of getting the number of registered VFs under #ifdef CONFIG_BNXT_SRIOV.
      The main code will call this function and will always work correctly
      whether CONFIG_BNXT_SRIOV is set or not.
      
      Fixes: 230d1f0d ("bnxt_en: Handle firmware reset.")
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e72cb7d6
  2. 30 Aug, 2019 33 commits