- 04 Mar, 2020 18 commits
-
-
Leon Romanovsky authored
Drop driver version in favor of global to linux kernel version. Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Remove driver and module version in favor of default one. Signed-off-by:
-
Leon Romanovsky authored
There is no need to explicitly set N/A if FW not available. Signed-off-by:
-
Leon Romanovsky authored
Use linux kernel version for ethtool and module versions. Signed-off-by:
-
David S. Miller authored
Bjorn Andersson says: ==================== net: qrtr: Nameserver fixes The need to respond to the HELLO message from the firmware was lost in the translation from the user space implementation of the nameserver. Fixing this also means we can remove the FIXME related to launching the ns. ==================== Signed-off-by: -
Bjorn Andersson authored
The 2 second delay before calling qrtr_ns_init() meant that the remote processors would register as endpoints in qrtr and the say_hello() call would therefor broadcast the outgoing HELLO to them. With the HELLO handshake corrected this delay is no longer needed. Reviewed-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Tested-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Bjorn Andersson authored
Lost in the translation from the user space implementation was the detail that HELLO mesages must be exchanged between each node pair. As such the incoming HELLO must be replied to. Similar to the previous implementation no effort is made to prevent two Linux boxes from continuously sending HELLO messages back and forth, this is left to a follow up patch. say_hello() is moved, to facilitate the new call site. Fixes: 0c2204a4 ("net: qrtr: Migrate nameservice to kernel from userspace") Reviewed-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
David S. Miller authored
Petr Machata says: ==================== selftests: Use busywait() in a couple places Two helper function for active waiting for an event were recently introduced: busywait() as the active-waiting tool, and until_counter_is() as a configurable predicate that can be plugged into busywait(). Use these in tc_common and mlxsw's qos_defprio instead of hand-coding equivalents. Patches #1 and #2 extend lib.sh facilities to make the transition possible. Patch #3 converts tc_common, and patch #4 qos_defprio. ==================== Signed-off-by: -
Petr Machata authored
Instead of hand-coding the busywait() predicate, use the until_counter_is() introduced recently. Signed-off-by:
Petr Machata <petrm@mellanox.com> Reviewed-by:
Amit Cohen <amitc@mellanox.com> Signed-off-by:
-
Petr Machata authored
A function busywait() was recently added based on the logic in __tc_check_packets(). Convert the code in tc_common to use the new function. Signed-off-by:
-
Petr Machata authored
until_counter_is() currently takes as an argument a number and the condition holds when the current counter value is >= that number. Make the function more generic by taking a partial expression instead of just the number. Convert the two existing users. Signed-off-by:
-
Petr Machata authored
The function tc_rule_stats_get() fetches a given statistic of a TC rule given the rule preference. Another common way to reference a rule is using its handle. Introduce a dual to the aforementioned function that gets a statistic given rule handle. Signed-off-by:
-
David S. Miller authored
Mat Martineau says: ==================== mptcp: Improve DATA_FIN transmission MPTCP's DATA_FIN flag is sent in a DSS option when closing the MPTCP-level connection. This patch series prepares for correct DATA_FIN handling across multiple subflows (where individual subflows may disconnect without closing the entire MPTCP connection) by changing the way the MPTCP-level socket requests a DATA_FIN on a subflow and propagates the necessary data for the TCP option. ==================== Signed-off-by: -
Mat Martineau authored
When a DATA_FIN is sent in a MPTCP DSS option that contains a data mapping, the DATA_FIN consumes one byte of space in the mapping. In this case, the DATA_FIN should only be included in the DSS option if its sequence number aligns with the end of the mapped data. Otherwise the subflow can send an incorrect implicit sequence number for the DATA_FIN, and the DATA_ACK for that sequence number would not close the MPTCP-level connection correctly. Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
-
Mat Martineau authored
Instead of reading the MPTCP-level sequence number when sending DATA_FIN, store the data in the subflow so it can be safely accessed when the subflow TCP headers are written to the packet without the MPTCP-level lock held. This also allows the MPTCP-level socket to close individual subflows without closing the MPTCP connection. Signed-off-by:
-
Mat Martineau authored
MPTCP should wait for an active connection or skip sending depending on the connection state, as TCP does. This happens before the possible passthrough to a regular TCP sendmsg because the subflow's socket type (MPTCP or TCP fallback) is not known until the connection is complete. This is also relevent at disconnect time, where data should not be sent in certain MPTCP-level connection states. Signed-off-by:
-
- 03 Mar, 2020 11 commits
-
-
David S. Miller authored
Parav Pandit says: ==================== devlink: Introduce devlink port flavour virtual Currently PCI PF and VF devlink devices register their ports as physical port in non-representors mode. Introduce a new port flavour as virtual so that virtual devices can register 'virtual' flavour to make it more clear to users. An example of one PCI PF and 2 PCI virtual functions, each having one devlink port. $ devlink port show pci/0000:06:00.0/1: type eth netdev ens2f0 flavour physical port 0 pci/0000:06:00.2/1: type eth netdev ens2f2 flavour virtual port 0 pci/0000:06:00.3/1: type eth netdev ens2f3 flavour virtual port 0 Patch summary: Patch-1 Introduces new devlink port flavour 'virtual'. Patch-2 Uses new flavour to register PCI VF virtual ports. ==================== Signed-off-by: -
Parav Pandit authored
Use newly introduce 'virtual' port flavour for devlink port of PCI VF devlink device in non-representors mode. While at it, remove recently introduced empty lines at end of the file. Reviewed-by:
Parav Pandit <parav@mellanox.com> Signed-off-by:
-
Parav Pandit authored
Currently mlx5 PCI PF and VF devlink devices register their ports as physical port in non-representors mode. Introduce a new port flavour as virtual so that virtual devices can register 'virtual' flavour to make it more clear to users. An example of one PCI PF and 2 PCI virtual functions, each having one devlink port. $ devlink port show pci/0000:06:00.0/1: type eth netdev ens2f0 flavour physical port 0 pci/0000:06:00.2/1: type eth netdev ens2f2 flavour virtual port 0 pci/0000:06:00.3/1: type eth netdev ens2f3 flavour virtual port 0 Reviewed-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Russell King authored
Using vim to edit the phylink documentation reveals some mistakes due to the "invisible" pythonesque white space indentation that can't be seen with other editors. Fix it. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
David S. Miller authored
Paul Blakey says: ==================== act_ct: Software offload of conntrack_in This series adds software offload of connections with an established ct state using the NF flow table offload infrastructure, so once such flows are offloaded, they will not pass through conntrack again, and instead act_ct will restore the conntrack info metadata on the skb to the state it had on the offload event - established. Act_ct maintains an FT instance per ct zone. Flow table entries are created, per ct connection, when connections enter an established state and deleted otherwise. Once an entry is created, the FT assumes ownership of the entry, and manages it's aging. On the datapath, first lookup the skb in the zone's FT before going into conntrack, and if a matching flow is found, restore the conntrack info metadata on the skb, and skip calling conntrack. Note that this patchset is part of the connection tracking offload feature. Hardware offload of connections with an established ct state series will follow this one. Changelog: v1->v2: Removed now unused netfilter patches ==================== Signed-off-by: -
Paul Blakey authored
Offload nf conntrack processing by looking up the 5-tuple in the zone's flow table. The nf conntrack module will process the packets until a connection is in established state. Once in established state, the ct state pointer (nf_conn) will be restored on the skb from a successful ft lookup. Signed-off-by:
Paul Blakey <paulb@mellanox.com> Acked-by:
-
Paul Blakey authored
Add a ft entry when connections enter an established state and delete the connections when they leave the established state. The flow table assumes ownership of the connection. In the following patch act_ct will lookup the ct state from the FT. In future patches, drivers will register for callbacks for ft add/del events and will be able to use the information to offload the connections. Note that connection aging is managed by the FT. Signed-off-by:
-
Paul Blakey authored
Use the NF flow tables infrastructure for CT offload. Create a nf flow table per zone. Next patches will add FT entries to this table, and do the software offload. Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a dev_warn message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Oleksij Rempel authored
Validate 100baseT1_Full to make this driver work with TJA1102 PHY. Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Acked-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Cambda Zhu authored
The data pointers of ipv6 sysctl are set one by one which is hard to maintain, especially with kconfig. This patch simplifies it by using math to point the per net sysctls into the appropriate struct net, just like what we did for ipv4. Signed-off-by:
Cambda Zhu <cambda@linux.alibaba.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
- 02 Mar, 2020 11 commits
-
-
Jesper Dangaard Brouer authored
Adding ethtool stats for when XDP transmitted packets overrun the TX queue. This is recorded separately for XDP_TX and ndo_xdp_xmit. This is an important aid for troubleshooting XDP based setups. It is currently a known weakness and property of XDP that there isn't any push-back or congestion feedback when transmitting frames via XDP. It's easy to realise when redirecting from a higher speed link into a slower speed link, or simply two ingress links into a single egress. The situation can also happen when Ethernet flow control is active. For testing the patch and provoking the situation to occur on my Espressobin board, I configured the TX-queue to be smaller (434) than RX-queue (512) and overload network with large MTU size frames (as a larger frame takes longer to transmit). Hopefully the upcoming XDP TX hook can be extended to provide insight into these TX queue overflows, to allow programmable adaptation strategies. Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Acked-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
-
David S. Miller authored
More zero-length array transformations from Gustavo A. R. Silva. Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:
-
