1. 11 Aug, 2019 8 commits
    • Ido Schimmel's avatar
      drop_monitor: Add a command to query current configuration · 444be061
      Ido Schimmel authored
      Users should be able to query the current configuration of drop monitor
      before they start using it. Add a command to query the existing
      configuration which currently consists of alert mode and packet
      truncation length.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      444be061
    • Ido Schimmel's avatar
      drop_monitor: Allow truncation of dropped packets · 57986617
      Ido Schimmel authored
      When sending dropped packets to user space it is not always necessary to
      copy the entire packet as usually only the headers are of interest.
      
      Allow user to specify the truncation length and add the original length
      of the packet as additional metadata to the netlink message.
      
      By default no truncation is performed.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      57986617
    • Ido Schimmel's avatar
      drop_monitor: Add packet alert mode · ca30707d
      Ido Schimmel authored
      So far drop monitor supported only one alert mode in which a summary of
      locations in which packets were recently dropped was sent to user space.
      
      This alert mode is sufficient in order to understand that packets were
      dropped, but lacks information to perform a more detailed analysis.
      
      Add a new alert mode in which the dropped packet itself is passed to
      user space along with metadata: The drop location (as program counter
      and resolved symbol), ingress netdevice and drop timestamp. More
      metadata can be added in the future.
      
      To avoid performing expensive operations in the context in which
      kfree_skb() is invoked (can be hard IRQ), the dropped skb is cloned and
      queued on per-CPU skb drop list. Then, in process context the netlink
      message is allocated, prepared and finally sent to user space.
      
      The per-CPU skb drop list is limited to 1000 skbs to prevent exhausting
      the system's memory. Subsequent patches will make this limit
      configurable and also add a counter that indicates how many skbs were
      tail dropped.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ca30707d
    • Ido Schimmel's avatar
      drop_monitor: Add alert mode operations · 28315f79
      Ido Schimmel authored
      The next patch is going to add another alert mode in which the dropped
      packet is notified to user space, instead of only a summary of recent
      drops.
      
      Abstract the differences between the modes by adding alert mode
      operations. The operations are selected based on the currently
      configured mode and associated with the probes and the work item just
      before tracing starts.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      28315f79
    • Ido Schimmel's avatar
      drop_monitor: Require CAP_NET_ADMIN for drop monitor configuration · c5ab9b1c
      Ido Schimmel authored
      Currently, the configure command does not do anything but return an
      error. Subsequent patches will enable the command to change various
      configuration options such as alert mode and packet truncation.
      
      Similar to other netlink-based configuration channels, make sure only
      users with the CAP_NET_ADMIN capability set can execute this command.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c5ab9b1c
    • Ido Schimmel's avatar
      drop_monitor: Reset per-CPU data before starting to trace · 44075f56
      Ido Schimmel authored
      The function reset_per_cpu_data() allocates and prepares a new skb for
      the summary netlink alert message ('NET_DM_CMD_ALERT'). The new skb is
      stored in the per-CPU 'data' variable and the old is returned.
      
      The function is invoked during module initialization and from the
      workqueue, before an alert is sent. This means that it is possible to
      receive an alert with stale data, if we stopped tracing when the
      hysteresis timer ('data->send_timer') was pending.
      
      Instead of invoking the function during module initialization, invoke it
      just before we start tracing and ensure we get a fresh skb.
      
      This also allows us to remove the calls to initialize the timer and the
      work item from the module initialization path, since both could have
      been triggered by the error paths of reset_per_cpu_data().
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      44075f56
    • Ido Schimmel's avatar
      drop_monitor: Initialize timer and work item upon tracing enable · 70c69274
      Ido Schimmel authored
      The timer and work item are currently initialized once during module
      init, but subsequent patches will need to associate different functions
      with the work item, based on the configured alert mode.
      
      Allow subsequent patches to make that change by initializing and
      de-initializing these objects during tracing enable and disable.
      
      This also guarantees that once the request to disable tracing returns,
      no more netlink notifications will be generated.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      70c69274
    • Ido Schimmel's avatar
      drop_monitor: Split tracing enable / disable to different functions · 7c747838
      Ido Schimmel authored
      Subsequent patches will need to enable / disable tracing based on the
      configured alerting mode.
      
      Reduce the nesting level and prepare for the introduction of this
      functionality by splitting the tracing enable / disable operations into
      two different functions.
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7c747838
  2. 10 Aug, 2019 21 commits
    • David S. Miller's avatar
      Merge branch 'Networking-driver-debugfs-cleanups' · 2cc2743d
      David S. Miller authored
      Greg Kroah-Hartman says:
      
      ====================
      Networking driver debugfs cleanups
      
      There is no need to test the result of any debugfs call anymore.  The
      debugfs core warns the user if something fails, and the return value of
      a debugfs call can always be fed back into another debugfs call with no
      problems.
      
      Also, debugfs is for debugging, so if there are problems with debugfs
      (i.e. the system is out of memory) the rest of the kernel should not
      change behavior, so testing for debugfs calls is pointless and not the
      goal of debugfs at all.
      
      This series cleans up a lot of networking drivers and some wimax code
      that was calling debugfs and trying to do something with the return
      value that it didn't need to.  Removing this logic makes the code
      smaller, easier to understand, and use less run-time memory in some
      cases, all good things.
      
      The series is against net-next, and have no dependancies between any of
      them if they want to go through any random tree/order.  Or, if wanted,
      I can take them through my driver-core tree where other debugfs cleanups
      are being slowly fed during major merge windows.
      
      v3: fix build warning in i2400m, I thought I had caught them all :(
          add acks from some reviewers
      
      v2: fix up build warnings, it's as if I never even built these.  Ugh, so
          sorry for wasting people's time with the v1 series.  I need to stop
          relying on 0-day as it isn't working well anymore :(
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2cc2743d
    • Greg Kroah-Hartman's avatar
      ieee802154: no need to check return value of debugfs_create functions · 7e174a49
      Greg Kroah-Hartman authored
      When calling debugfs functions, there is no need to ever check the
      return value.  The function can work or not, but the code logic should
      never do something different based on this.
      
      Cc: Alexander Aring <alex.aring@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Harry Morris <h.morris@cascoda.com>
      Cc: linux-wpan@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Acked-by: default avatarStefan Schmidt <stefan@datenfreihafen.org>
      Acked-by: default avatarMichael Hennerich <michael.hennerich@analog.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7e174a49
    • Greg Kroah-Hartman's avatar
      ixgbe: no need to check return value of debugfs_create functions · 35dc61eb
      Greg Kroah-Hartman authored
      When calling debugfs functions, there is no need to ever check the
      return value.  The function can work or not, but the code logic should
      never do something different based on this.
      
      Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: intel-wired-lan@lists.osuosl.org
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      35dc61eb
    • Greg Kroah-Hartman's avatar
      i40e: no need to check return value of debugfs_create functions · 43c4eb03
      Greg Kroah-Hartman authored
      When calling debugfs functions, there is no need to ever check the
      return value.  The function can work or not, but the code logic should
      never do something different based on this.
      
      Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: intel-wired-lan@lists.osuosl.org
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      43c4eb03
    • Greg Kroah-Hartman's avatar
      fm10k: no need to check return value of debugfs_create functions · ecc55707
      Greg Kroah-Hartman authored
      When calling debugfs functions, there is no need to ever check the
      return value.  The function can work or not, but the code logic should
      never do something different based on this.
      
      Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: intel-wired-lan@lists.osuosl.org
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ecc55707
    • Greg Kroah-Hartman's avatar
      mvpp2: no need to check return value of debugfs_create functions · e6882aa6
      Greg Kroah-Hartman authored
      When calling debugfs functions, there is no need to ever check the
      return value.  The function can work or not, but the code logic should
      never do something different based on this.
      
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Maxime Chevallier <maxime.chevallier@bootlin.com>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Cc: Nathan Huckleberry <nhuck@google.com>
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e6882aa6
    • Greg Kroah-Hartman's avatar
      skge: no need to check return value of debugfs_create functions · 2f62f8e6
      Greg Kroah-Hartman authored
      When calling debugfs functions, there is no need to ever check the
      return value.  The function can work or not, but the code logic should
      never do something different based on this.
      
      Cc: Mirko Lindner <mlindner@marvell.com>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2f62f8e6
    • Greg Kroah-Hartman's avatar
      qca: no need to check return value of debugfs_create functions · 687236b0
      Greg Kroah-Hartman authored
      When calling debugfs functions, there is no need to ever check the
      return value.  The function can work or not, but the code logic should
      never do something different based on this.
      
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Stefan Wahren <stefan.wahren@i2se.com>
      Cc: Michael Heimpold <michael.heimpold@i2se.com>
      Cc: Yangtao Li <tiny.windzz@gmail.com>
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      687236b0
    • Greg Kroah-Hartman's avatar
      dpaa2: no need to check return value of debugfs_create functions · 92aff5b4
      Greg Kroah-Hartman authored
      When calling debugfs functions, there is no need to ever check the
      return value.  The function can work or not, but the code logic should
      never do something different based on this.
      
      Because we don't care about the individual files, we can remove the
      stored dentry for the files, as they are not needed to be kept track of
      at all.
      
      Cc: Ioana Radulescu <ruxandra.radulescu@nxp.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      92aff5b4
    • Greg Kroah-Hartman's avatar
      stmmac: no need to check return value of debugfs_create functions · 8d72ab11
      Greg Kroah-Hartman authored
      When calling debugfs functions, there is no need to ever check the
      return value.  The function can work or not, but the code logic should
      never do something different based on this.
      
      Because we don't care about the individual files, we can remove the
      stored dentry for the files, as they are not needed to be kept track of
      at all.
      
      Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
      Cc: Alexandre Torgue <alexandre.torgue@st.com>
      Cc: Jose Abreu <joabreu@synopsys.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
      Cc: netdev@vger.kernel.org
      Cc: linux-stm32@st-md-mailman.stormreply.com
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8d72ab11
    • Greg Kroah-Hartman's avatar
      nfp: no need to check return value of debugfs_create functions · 16e9b481
      Greg Kroah-Hartman authored
      When calling debugfs functions, there is no need to ever check the
      return value.  The function can work or not, but the code logic should
      never do something different based on this.
      
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Jesper Dangaard Brouer <hawk@kernel.org>
      Cc: John Fastabend <john.fastabend@gmail.com>
      Cc: Edwin Peer <edwin.peer@netronome.com>
      Cc: Yangtao Li <tiny.windzz@gmail.com>
      Cc: Simon Horman <simon.horman@netronome.com>
      Cc: oss-drivers@netronome.com
      Cc: netdev@vger.kernel.org
      Acked-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      16e9b481
    • Greg Kroah-Hartman's avatar
      hns3: no need to check return value of debugfs_create functions · 11ab11e6
      Greg Kroah-Hartman authored
      When calling debugfs functions, there is no need to ever check the
      return value.  The function can work or not, but the code logic should
      never do something different based on this.
      
      Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
      Cc: Salil Mehta <salil.mehta@huawei.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      11ab11e6
    • Greg Kroah-Hartman's avatar
      cxgb4: no need to check return value of debugfs_create functions · 9dac1e8e
      Greg Kroah-Hartman authored
      When calling debugfs functions, there is no need to ever check the
      return value.  The function can work or not, but the code logic should
      never do something different based on this.
      
      If a debugfs call fails, it will properly warn in the syslog, there's no
      need for all individual drivers to also print a message, so that is one
      more reason to not care about checking the return values.
      
      Cc: Vishal Kulkarni <vishal@chelsio.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Casey Leedom <leedom@chelsio.com>
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9dac1e8e
    • Greg Kroah-Hartman's avatar
      bnxt: no need to check return value of debugfs_create functions · 3a131e85
      Greg Kroah-Hartman authored
      When calling debugfs functions, there is no need to ever check the
      return value.  The function can work or not, but the code logic should
      never do something different based on this.
      
      This cleans up a lot of unneeded code and logic around the debugfs
      files, making all of this much simpler and easier to understand.
      
      Cc: Michael Chan <michael.chan@broadcom.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3a131e85
    • Greg Kroah-Hartman's avatar
      xgbe: no need to check return value of debugfs_create functions · 9e3926df
      Greg Kroah-Hartman authored
      When calling debugfs functions, there is no need to ever check the
      return value.  The function can work or not, but the code logic should
      never do something different based on this.
      
      This cleans up a lot of unneeded code and logic around the debugfs
      files, making all of this much simpler and easier to understand.
      
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9e3926df
    • Greg Kroah-Hartman's avatar
      mlx5: no need to check return value of debugfs_create functions · 9f818c8a
      Greg Kroah-Hartman authored
      When calling debugfs functions, there is no need to ever check the
      return value.  The function can work or not, but the code logic should
      never do something different based on this.
      
      This cleans up a lot of unneeded code and logic around the debugfs
      files, making all of this much simpler and easier to understand as we
      don't need to keep the dentries saved anymore.
      
      Cc: Saeed Mahameed <saeedm@mellanox.com>
      Cc: Leon Romanovsky <leon@kernel.org>
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9f818c8a
    • Greg Kroah-Hartman's avatar
      bonding: no need to print a message if debugfs_create_dir() fails · fedcc6da
      Greg Kroah-Hartman authored
      The debugfs core now will print a message if this function fails, so
      don't duplicate that logic.  Also, no need to change the code logic if
      the call fails either, as no debugfs calls should interrupt normal
      kernel code for any reason.
      
      Cc: Jay Vosburgh <j.vosburgh@gmail.com>
      Cc: Veaceslav Falico <vfalico@gmail.com>
      Cc: Andy Gospodarek <andy@greyhouse.net>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fedcc6da
    • Greg Kroah-Hartman's avatar
      wimax: no need to check return value of debugfs_create functions · a62052ba
      Greg Kroah-Hartman authored
      When calling debugfs functions, there is no need to ever check the
      return value.  The function can work or not, but the code logic should
      never do something different based on this.
      
      This cleans up a lot of unneeded code and logic around the debugfs wimax
      files, making all of this much simpler and easier to understand.
      
      Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
      Cc: linux-wimax@intel.com
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a62052ba
    • David S. Miller's avatar
      Merge tag 'mlx5-updates-2019-08-09' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · 38b9e0f6
      David S. Miller authored
      Saeed Mahameed says:
      
      ====================
      mlx5-updates-2019-08-09
      
      This series includes update to mlx5 ethernet and core driver:
      
      In first #11 patches, Vlad submits part 2 of 3 part series to allow
      TC flow handling for concurrent execution.
      
      1) TC flow handling for concurrent execution (part 2)
      
      Vald Says:
      ==========
      
      Refactor data structures that are shared between flows in tc.
      Currently, all cls API hardware offloads driver callbacks require caller
      to hold rtnl lock when calling them. Cls API has already been updated to
      update software filters in parallel (on classifiers that support
      unlocked execution), however hardware offloads code still obtains rtnl
      lock before calling driver tc callbacks. This set implements support for
      unlocked execution of tc hairpin, mod_hdr and encap subsystem. The
      changed implemented in these subsystems are very similar in general.
      
      The main difference is that hairpin is accessed through mlx5e_tc_table
      (legacy mode), mod_hdr is accessed through both mlx5e_tc_table and
      mlx5_esw_offload (legacy and switchdev modes) and encap is only accessed
      through mlx5_esw_offload (switchdev mode).
      
      1.1) Hairpin handling and structure mlx5e_hairpin_entry refactored in
      following way:
      
      - Hairpin structure is extended with atomic reference counter. This
        approach allows to lookup of hairpin entry and obtain reference to it
        with hairpin_tbl_lock protection and then continue using the entry
        unlocked (including provisioning to hardware).
      
      - To support unlocked provisioning of hairpin entry to hardware, the entry
        is extended with 'res_ready' completion and is inserted to hairpin_tbl
        before calling the firmware. With this approach any concurrent users that
        attempt to use the same hairpin entry wait for completion first to
        prevent access to entries that are not fully initialized.
      
      - Hairpin entry is extended with new flows_lock spinlock to protect the
        list when multiple concurrent tc instances update flows attached to
        the same hairpin entry.
      
      1.2) Modify header handling code and structure mlx5e_mod_hdr_entry
      are refactored in the following way:
      
      - Mod_hdr structure is extended with atomic reference counter. This
        approach allows to lookup of mod_hdr entry and obtain reference to it
        with mod_hdr_tbl_lock protection and then continue using the entry
        unlocked (including provisioning to hardware).
      
      - To support unlocked provisioning of mod_hdr entry to hardware, the entry
        is extended with 'res_ready' completion and is inserted to mod_hdr_tbl
        before calling the firmware. With this approach any concurrent users that
        attempt to use the same mod_hdr entry wait for completion first to
        prevent access to entries that are not fully initialized.
      
      - Mod_Hdr entry is extended with new flows_lock spinlock to protect the
        list when multiple concurrent tc instances update flows attached to
        the same mod_hdr entry.
      
      1.3) Encapsulation handling code and Structure mlx5e_encap_entry
      are refactored in the following way:
      
      - encap structure is extended with atomic reference counter. This
        approach allows to lookup of encap entry and obtain reference to it
        with encap_tbl_lock protection and then continue using the entry
        unlocked (including provisioning to hardware).
      
      - To support unlocked provisioning of encap entry to hardware, the entry is
        extended with 'res_ready' completion and is inserted to encap_tbl before
        calling the firmware. With this approach any concurrent users that
        attempt to use the same encap entry wait for completion first to prevent
        access to entries that are not fully initialized.
      
      - As a difference from approach used to refactor hairpin and mod_hdr,
        encap entry is not extended with any per-entry fine-grained lock.
        Instead, encap_table_lock is used to synchronize all operations on
        encap table and instances of mlx5e_encap_entry. This is necessary
        because single flow can be attached to multiple encap entries
        simultaneously. During new flow creation or neigh update event all of
        encaps that flow is attached to must be accessed together as in atomic
        manner, which makes usage of per-entry lock infeasible.
      
      - Encap entry is extended with new flows_lock spinlock to protect the
        list when multiple concurrent tc instances update flows attached to
        the same encap entry.
      
      ==========
      
      3) Parav improves the way port representors report their parent ID and
      port index.
      
      4) Use refcount_t for refcount in vxlan data base from  Chuhong Yuan
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      38b9e0f6
    • Roman Mashak's avatar
      62ad42ec
    • David Ahern's avatar
      selftests: Fix detection of nettest command in fcnal-test · f887427b
      David Ahern authored
      Most of the tests run by fcnal-test.sh relies on the nettest command.
      Rather than trying to cover all of the individual tests, check for the
      binary only at the beginning.
      
      Also removes the need for log_error which is undefined.
      
      Fixes: 6f9d5cac ("selftests: Setup for functional tests for fib and socket lookups")
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f887427b
  3. 09 Aug, 2019 11 commits