- 29 Jun, 2021 4 commits
-
-
Vladimir Oltean authored
We want to add reference counting for FDB entries in cross-chip topologies, and in order for that to have any chance of working and not be unbalanced (leading to entries which are never deleted), we need to ensure that higher layers are sane, because if they aren't, it's garbage in, garbage out. For example, if we add a bridge FDB entry twice, the bridge properly errors out: $ bridge fdb add dev swp0 00:01:02:03:04:07 master static $ bridge fdb add dev swp0 00:01:02:03:04:07 master static RTNETLINK answers: File exists However, the same thing cannot be said about the bridge bypass operations: $ bridge fdb add dev swp0 00:01:02:03:04:07 $ bridge fdb add dev swp0 00:01:02:03:04:07 $ bridge fdb add dev swp0 00:01:02:03:04:07 $ bridge fdb add dev swp0 00:01:02:03:04:07 $ echo $? 0 But one 'bridge fdb del' is enough to remove the entry, no matter how many times it was added. The bridge bypass operations are impossible to maintain in these circumstances and lack of support for reference counting the cross-chip notifiers is holding us back from making further progress, so just drop support for them. The only way left for users to install static bridge FDB entries is the proper one, using the "master static" flags. With this change, rtnl_fdb_add() falls back to calling ndo_dflt_fdb_add() which uses the duplicate-exclusive variant of dev_uc_add(): dev_uc_add_excl(). Because DSA does not (yet) declare IFF_UNICAST_FLT, this results in us going to promiscuous mode: $ bridge fdb add dev swp0 00:01:02:03:04:05 [ 28.206743] device swp0 entered promiscuous mode $ bridge fdb add dev swp0 00:01:02:03:04:05 RTNETLINK answers: File exists So even if it does not completely fail, there is at least some indication that it is behaving differently from before, and closer to user space expectations, I would argue (the lack of a "local|static" specifier defaults to "local", or "host-only", so dev_uc_add() is a reasonable default implementation). If the generic implementation of .ndo_fdb_add provided by Vlad Yasevich is a proof of anything, it only proves that the implementation provided by DSA was always wrong, by not looking at "ndm->ndm_state & NUD_NOARP" (the "static" flag which means that the FDB entry points outwards) and "ndm->ndm_state & NUD_PERMANENT" (the "local" flag which means that the FDB entry points towards the host). It all used to mean the same thing to DSA. Update the documentation so that the users are not confused about what's going on. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
When a port joins a bridge which already has local FDB entries pointing to the bridge device itself, we would like to offload those, so allow the "dev" argument to be equal to the bridge too. The code already does what we need in that case. Signed-off-by:
-
Tobias Waldekranz authored
Treat addresses added to the bridge itself in the same way as regular ports and send out a notification so that drivers may sync it down to the hardware FDB. Signed-off-by:
Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by:
-
Vladimir Oltean authored
Annotate the writer side of fdb->dst: - fdb_create() - br_fdb_update() - fdb_add_entry() - br_fdb_external_learn_add() with WRITE_ONCE() and the reader side: - br_fdb_test_addr() - br_fdb_update() - fdb_fill_info() - fdb_add_entry() - fdb_delete_by_addr_and_port() - br_fdb_external_learn_add() - br_switchdev_fdb_notify() with compiler barriers such that the readers do not attempt to reload fdb->dst multiple times, leading to potentially different destination ports when the fdb entry is updated concurrently. This is especially important in read-side sections where fdb->dst is used more than once, but let's convert all accesses for the sake of uniformity. Suggested-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
-
- 28 Jun, 2021 36 commits
-
-
David S. Miller authored
Tanner Love says: ==================== net: update netdev_rx_csum_fault() print dump only once First patch implements DO_ONCE_LITE to abstract uses of the ".data.once" trick. It is defined in its own, new header file -- rather than alongside the existing DO_ONCE in include/linux/once.h -- because include/linux/once.h includes include/linux/jump_label.h, and this causes the build to break for some architectures if include/linux/once.h is included in include/linux/printk.h or include/asm-generic/bug.h. Second patch uses DO_ONCE_LITE in netdev_rx_csum_fault to print dump only once. ==================== Signed-off-by: -
Tanner Love authored
Printing this stack dump multiple times does not provide additional useful information, and consumes time in the data path. Printing once is sufficient. Changes v2: Format indentation properly Signed-off-by:
Tanner Love <tannerlove@google.com> Acked-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Mahesh Bandewar <maheshb@google.com> Signed-off-by:
-
Tanner Love authored
Certain uses of "do once" functionality reside outside of fast path, and so do not require jump label patching via static keys, making existing DO_ONCE undesirable in such cases. Replace uses of __section(".data.once") with DO_ONCE_LITE(_IF)? This patch changes the return values of xfs_printk_once, printk_once, and printk_deferred_once. Before, they returned whether the print was performed, but now, they always return true. This is okay because the return values of the following macros are entirely ignored throughout the kernel: - xfs_printk_once - xfs_warn_once - xfs_notice_once - xfs_info_once - printk_once - pr_emerg_once - pr_alert_once - pr_crit_once - pr_err_once - pr_warn_once - pr_notice_once - pr_info_once - pr_devel_once - pr_debug_once - printk_deferred_once - orc_warn Changes v3: - Expand commit message to explain why changing return values of xfs_printk_once, printk_once, printk_deferred_once is benign v2: - Fix i386 build warnings Signed-off-by:Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Nathan Chancellor authored
Clang warns: drivers/net/ethernet/microchip/sparx5/sparx5_main.c:760:29: warning: variable 'mac_addr' is uninitialized when used here [-Wuninitialized] if (of_get_mac_address(np, mac_addr)) { ^~~~~~~~ drivers/net/ethernet/microchip/sparx5/sparx5_main.c:669:14: note: initialize the variable 'mac_addr' to silence this warning u8 *mac_addr; ^ = NULL 1 warning generated. mac_addr is only used to store the value retrieved from of_get_mac_address(), which is then copied into the base_mac member of the sparx5 struct using ether_addr_copy(). It is easier to just use the base_mac address directly, which avoids the warning and the extra copy. Fixes: 3cfa11ba ("net: sparx5: add the basic sparx5 driver") Link: https://github.com/ClangBuiltLinux/linux/issues/1413Signed-off-by:Nathan Chancellor <nathan@kernel.org> Signed-off-by:
-
Vladimir Oltean authored
The SJA1105P/Q/R/S and SJA1110 may have the same layout for the command to read/write/search for L2 Address Lookup entries, but as explained in the comments at the beginning of the sja1105_dynamic_config.c file, the command portion of the buffer is at the end, and we need to obtain a pointer to it by adding the length of the entry to the buffer. Alas, the length of an L2 Address Lookup entry is larger in SJA1110 than it is for SJA1105P/Q/R/S, so we need to create a common helper to access the command buffer, and this receives as argument the length of the entry buffer. Fixes: 3e77e59b ("net: dsa: sja1105: add support for the SJA1110 switch family") Signed-off-by:
-
Horatiu Vultur authored
According to the standard IEC 62439-2, in case the node behaves as MRA and needs to send Test frames on ring ports, then these Test frames need to have an Option TLV and a Sub-Option TLV which has the type AUTO_MGR. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
David S. Miller authored
Merge tag 'for-net-next-2021-06-28' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Luiz Augusto von Dentz says: ==================== bluetooth-next pull request for net-next: - Add support for QCA_ROME device (0cf3:e500) and RTL8822CE - Update management interface revision to 21 - Use of incluse language - Proper handling of HCI_LE_Advertising_Set_Terminated event - Recovery handing of HCI ncmd=0 - Various memory fixes ==================== Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller authored
Daniel Borkmann says: ==================== pull-request: bpf-next 2021-06-28 The following pull-request contains BPF updates for your *net-next* tree. We've added 37 non-merge commits during the last 12 day(s) which contain a total of 56 files changed, 394 insertions(+), 380 deletions(-). The main changes are: 1) XDP driver RCU cleanups, from Toke Høiland-Jørgensen and Paul E. McKenney. 2) Fix bpf_skb_change_proto() IPv4/v6 GSO handling, from Maciej Żenczykowski. 3) Fix false positive kmemleak report for BPF ringbuf alloc, from Rustam Kovhaev. 4) Fix x86 JIT's extable offset calculation for PROBE_LDX NULL, from Ravi Bangoria. 5) Enable libbpf fallback probing with tracing under RHEL7, from Jonathan Edwards. 6) Clean up x86 JIT to remove unused cnt tracking from EMIT macro, from Jiri Olsa. 7) Netlink cleanups for libbpf to please Coverity, from Kumar Kartikeya Dwivedi. 8) Allow to retrieve ancestor cgroup id in tracing programs, from Namhyung Kim. 9) Fix lirc BPF program query to use user-provided prog_cnt, from Sean Young. 10) Add initial libbpf doc including generated kdoc for its API, from Grant Seltzer. 11) Make xdp_rxq_info_unreg_mem_model() more robust, from Jakub Kicinski. 12) Fix up bpfilter startup log-level to info level, from Gary Lin. ==================== Signed-off-by: -
Andreas Roeseler authored
This patch builds off of commit 2b246b25 and adds functionality to respond to ICMPV6 PROBE requests. Add icmp_build_probe function to construct PROBE requests for both ICMPV4 and ICMPV6. Modify icmpv6_rcv to detect ICMPV6 PROBE messages and call the icmpv6_echo_reply handler. Modify icmpv6_echo_reply to build a PROBE response message based on the queried interface. This patch has been tested using a branch of the iputils git repo which can be found here: https://github.com/Juniper-Clinic-2020/iputils/tree/probe-requestSigned-off-by:
Andreas Roeseler <andreas.a.roeseler@gmail.com> Reviewed-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Yang Yingliang authored
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: d6fce514 ("net: sparx5: add switching support") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
Yang Yingliang authored
In case of error, the function devm_ioremap() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Fixes: 3cfa11ba ("net: sparx5: add the basic sparx5 driver") Reported-by:
-
Yang Yingliang authored
It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Fixes: 3cfa11ba ("net: sparx5: add the basic sparx5 driver") Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== mlx5-updates-2021-06-26 This series provides small updates to mlx5 driver. 1) Increase hairpin buffer size 2) Improve peroformance in SF allocation 3) Add IPsec support to uplink representor 4) Add stats for number of deleted kTLS TX offloaded connections 5) Add support for flow sampler in SW steering ==================== Signed-off-by: -
David S. Miller authored
Vladimir Oltean says: ==================== Cleanup for the bridge replay helpers This patch series brings some improvements to the logic added to the bridge and DSA to handle LAG interfaces sandwiched between a bridge and a DSA switch port. br0 / \ / \ bond0 swp2 / \ / \ swp0 swp1 In particular, it ensures that the switchdev object additions and deletions are well balanced per physical port. This is important for future work in the area of offloading local bridge FDB entries to hardware in the context of DSA requesting a replay of those entries at bridge join time (this will be submitted in a future patch series). Due to some difficulty ensuring that the deletion of local FDB entries pointing towards the bridge device itself is notified to switchdev in time (before the switchdev port disconnects from the bridge), this is potentially still not the final form in which the replay helpers will exist. I'm thinking about moving from the pull mode (in which DSA requests the replay) to a push mode (in which the bridge initiates the replay). Nonetheless, these preliminary changes are needed either way. The patch series also addresses some feedback from Nikolai which is long overdue by now (sorry). Switchdev driver maintainers were deliberately omitted due to the trivial nature of the driver changes (just a function prototype). Changes in v2: - fix build issue in patch 4 (function prototype mismatch) - move switchdev object unsync to the NETDEV_PRECHANGEUPPER code path ==================== Signed-off-by: -
Vladimir Oltean authored
When a DSA switch port leaves a bonding interface that is under a bridge, there might be dangling switchdev objects on that port left behind, because the bridge is not aware that its lower interface (the bond) changed state in any way. Call the bridge replay helpers with adding=false before changing dp->bridge_dev to NULL, because we need to simulate to dsa_slave_port_obj_del() that these notifications were emitted by the bridge. We add this hook to the NETDEV_PRECHANGEUPPER event handler, because we are calling into switchdev (and the __switchdev_handle_port_obj_del fanout helpers expect the upper/lower adjacency lists to still be valid) and PRECHANGEUPPER is the last moment in time when they still are. Signed-off-by:
-
Vladimir Oltean authored
We need to add more logic to the DSA NETDEV_PRECHANGEUPPER event handler, more exactly we need to request an unsync of switchdev objects. In order to fit more code, refactor the existing logic into a helper. Signed-off-by:
-
Vladimir Oltean authored
When a switchdev port leaves a LAG that is a bridge port, the switchdev objects and port attributes offloaded to that port are not removed: ip link add br0 type bridge ip link add bond0 type bond mode 802.3ad ip link set swp0 master bond0 ip link set bond0 master br0 bridge vlan add dev bond0 vid 100 ip link set swp0 nomaster VLAN 100 will remain installed on swp0 despite it going into standalone mode, because as far as the bridge is concerned, nothing ever happened to its bridge port. Let's extend the bridge vlan, fdb and mdb replay functions to take a 'bool adding' argument, and make DSA and ocelot call the replay functions with 'adding' as false from the switchdev unsync path, for the switch port that leaves the bridge. Note that this patch in itself does not salvage anything, because in the current pull mode of operation, DSA still needs to call the replay helpers with adding=false. This will be done in another patch. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
Some of the arguments and local variables for the newly added switchdev replay helpers can be const, so let's make them so. Signed-off-by:
-
Vladimir Oltean authored
There is a slight inconvenience in the switchdev replay helpers added recently, and this is when: ip link add br0 type bridge ip link add bond0 type bond ip link set bond0 master br0 bridge vlan add dev bond0 vid 100 ip link set swp0 master bond0 ip link set swp1 master bond0 Since the underlying driver (currently only DSA) asks for a replay of VLANs when swp0 and swp1 join the LAG because it is bridged, what will happen is that DSA will try to react twice on the VLAN event for swp0. This is not really a huge problem right now, because most drivers accept duplicates since the bridge itself does, but it will become a problem when we add support for replaying switchdev object deletions. Let's fix this by adding a blank void *ctx in the replay helpers, which will be passed on by the bridge in the switchdev notifications. If the context is NULL, everything is the same as before. But if the context is populated with a valid pointer, the underlying switchdev driver (currently DSA) can use the pointer to 'see through' the bridge port (which in the example above is bond0) and 'know' that the event is only for a particular physical port offloading that bridge port, and not for all of them. Signed-off-by:
-
Vladimir Oltean authored
In the case where the driver asks for a replay of a certain type of event (port object or attribute) for a bridge port that is a LAG, it may do so because this port has just joined the LAG. But there might already be other switchdev ports in that LAG, and it is preferable that those preexisting switchdev ports do not act upon the replayed event. The solution is to add a context to switchdev events, which is NULL most of the time (when the bridge layer initiates the call) but which can be set to a value controlled by the switchdev driver when a replay is requested. The driver can then check the context to figure out if all ports within the LAG should act upon the switchdev event, or just the ones that match the context. We have to modify all switchdev_handle_* helper functions as well as the prototypes in the drivers that use these helpers too, because these helpers hide the underlying struct switchdev_notifier_info from us and there is no way to retrieve the context otherwise. The context structure will be populated and used in later patches. Signed-off-by:
-
Vladimir Oltean authored
Not using this driver, I did not realize it doesn't react to SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE notifications, but it implements just the bridge bypass operations (.ndo_fdb_{add,del}). So the call to br_fdb_replay just produces notifications that are ignored, delete it for now. Signed-off-by: -
Vladimir Oltean authored
Since commit 2c4eca3e ("net: bridge: switchdev: include local flag in FDB notifications"), the bridge emits SWITCHDEV_FDB_ADD_TO_DEVICE events with the is_local flag populated (but we ignore it nonetheless). We would like DSA to start treating this bit, but it is still not populated by the replay helper, so add it there too. Signed-off-by:
-
Jakub Kicinski authored
xdp_rxq_info_unreg() implicitly calls xdp_rxq_info_unreg_mem_model(). This may well be confusing to the driver authors, and lead to double free if they call xdp_rxq_info_unreg_mem_model() before xdp_rxq_info_unreg() (when mem model type == MEM_TYPE_PAGE_POOL). In fact error path of mvpp2_rxq_init() seems to currently do exactly that. The double free will result in refcount underflow in page_pool_destroy(). Make the interface a little more programmer friendly by clearing type and id so that xdp_rxq_info_unreg_mem_model() can be called multiple times. Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20210625221612.2637086-1-kuba@kernel.org
-
David S. Miller authored
Michael Chan says: ==================== bnxt_en: Add hardware PTP timestamping support on 575XX devices Add PTP RX and TX hardware timestamp support on 575XX devices. These devices use the two-step method to implement the IEEE-1588 timestamping support. v2: Add spinlock to serialize access to the timecounter. Use .do_aux_work() for the periodic timer reading and to get the TX timestamp from the firmware. Propagate error code from ptp_clock_register(). Make the 64-bit timer access safe on 32-bit CPUs. Read PHC using direct register access. ==================== Signed-off-by: -
Michael Chan authored
Call bnxt_ptp_init() to initialize and register with the clock driver to enable PTP support. Call bnxt_ptp_free() to unregister and clean up during shutdown. Reviewed-by:
Edwin Peer <edwin.peer@broadcom.com> Reviewed-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Pavan Chebbi authored
Setup the TXBD to enable TX timestamp if requested. At TX packet DMA completion, if we requested TX timestamp on that packet, we defer to .do_aux_work() to obtain the TX timestamp from the firmware before we free the TX SKB. v2: Use .do_aux_work() to get the TX timestamp from firmware. Reviewed-by:
-
Pavan Chebbi authored
If the RX packet is timestamped by the hardware, the RX completion record will contain the lower 32-bit of the timestamp. This needs to be combined with the upper 16-bit of the periodic timestamp that we get from the timer. The previous snapshot in ptp->old_timer is used to make sure that the snapshot is not ahead of the RX timestamp and we adjust for wrap-around if needed. v2: Make ptp->old_time read access safe on 32-bit CPUs. Reviewed-by:
-
Pavan Chebbi authored
From the bnxt_timer(), read the 48-bit hardware running clock periodically and store it in ptp->current_time. The previous snapshot of the clock will be stored in ptp->old_time. The old_time snapshot will be used in the next patches to compute the RX packet timestamps. v2: Use .do_aux_work() to read the timer periodically. Reviewed-by:
-
Michael Chan authored
Add the clock APIs to set/get/adjust the hw clock, and the related ioctls and ethtool methods. v2: Propagate error code from ptp_clock_register(). Add spinlock to serialize access to the timecounter. The timecounter is accessed in process context and the RX datapath. Read the PHC using direct registers. Reviewed-by: -
Michael Chan authored
Store PTP hardware info in a structure if hardware and firmware support PTP. Reviewed-by:
-
Michael Chan authored
Adding the PTP related firmware interface is the main change. There is also a name change for admin_mtu, requiring code fixup. Reviewed-by:
-
David S. Miller authored
Guangbin Huang says: ==================== net: hns3: add new debugfs commands This series adds three new debugfs commands for the HNS3 ethernet driver. change log: V1 -> V2: 1. remove patch "net: hns3: add support for link diagnosis info in debugfs" and use ethtool extended link state to implement similar function according to Jakub Kicinski's opinion. ==================== Signed-off-by: -
Jian Shen authored
This patch adds support of dumping MAC umv counter in debugfs, which will be helpful for debugging. The display style is below: $ cat umv_info num_alloc_vport : 2 max_umv_size : 256 wanted_umv_size : 256 priv_umv_size : 85 share_umv_size : 86 vport(0) used_umv_num : 1 vport(1) used_umv_num : 1 Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
-
Jian Shen authored
Previously, the flow director counter is not enabled. To improve the maintainability for chechking whether flow director hit or not, enable flow director counter for each function, and add debugfs query inerface to query the counters for each function. The debugfs command is below: cat fd_counter func_id hit_times pf 0 vf0 0 vf1 0 Signed-off-by:
-
David S. Miller authored
Menglong Dong says: ==================== net: tipc: fix FB_MTU eat two pages and do some code cleanup In the first patch, FB_MTU is redefined to make sure data size will not exceed PAGE_SIZE. Besides, I removed the alignment for buf_size in tipc_buf_acquire, because skb_alloc_fclone will do the alignment job. In the second patch, I removed align() in msg.c and replace it with ALIGN(). Changes since V5: - remove blank line after Fixes in commit log in the first patch Changes since V4: - remove ONE_PAGE_SKB_SZ and replace it with one_page_mtu in the first patch. - fix some code style problems for the second patch. ==================== Signed-off-by: -
Menglong Dong authored
The function align() which is defined in msg.c is redundant, replace it with ALIGN() and introduce a BUF_ALIGN(). Signed-off-by:
Menglong Dong <dong.menglong@zte.com.cn> Acked-by:
Jon Maloy <jmaloy@redhat.com> Signed-off-by:
-
