aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-08-27netkit: Disable netpoll supportDaniel Borkmann1-0/+1
Follow-up to 45160cebd6ac ("net: veth: Disable netpoll support") to also disable netpoll for netkit interfaces. Same conditions apply here as well. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Cc: Breno Leitao <leitao@debian.org> Cc: Nikolay Aleksandrov <razor@blackwall.org> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://lore.kernel.org/r/eab2d69ba2f4c260aef62e4ff0d803e9f60c2c5d.1724414250.git.daniel@iogearbox.net Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
2024-08-27Merge branch 'tc-adjust-network-header-after-2nd-vlan-push'Paolo Abeni5-4/+54
Boris Sukholitko says: ==================== tc: adjust network header after 2nd vlan push <tldr> skb network header of the single-tagged vlan packet continues to point the vlan payload (e.g. IP) after second vlan tag is pushed by tc act_vlan. This causes problem at the dissector which expects double-tagged packet network header to point to the inner vlan. The fix is to adjust network header in tcf_act_vlan.c but requires refactoring of skb_vlan_push function. </tldr> Consider the following shell script snippet configuring TC rules on the veth interface: ip link add veth0 type veth peer veth1 ip link set veth0 up ip link set veth1 up tc qdisc add dev veth0 clsact tc filter add dev veth0 ingress pref 10 chain 0 flower \ num_of_vlans 2 cvlan_ethtype 0x800 action goto chain 5 tc filter add dev veth0 ingress pref 20 chain 0 flower \ num_of_vlans 1 action vlan push id 100 \ protocol 0x8100 action goto chain 5 tc filter add dev veth0 ingress pref 30 chain 5 flower \ num_of_vlans 2 cvlan_ethtype 0x800 action simple sdata "success" Sending double-tagged vlan packet with the IP payload inside: cat <<ENDS | text2pcap - - | tcpreplay -i veth1 - 0000 00 00 00 00 00 11 00 00 00 00 00 22 81 00 00 64 ..........."...d 0010 81 00 00 14 08 00 45 04 00 26 04 d2 00 00 7f 11 ......E..&...... 0020 18 ef 0a 00 00 01 14 00 00 02 00 00 00 00 00 12 ................ 0030 e1 c7 00 00 00 00 00 00 00 00 00 00 ............ ENDS will match rule 10, goto rule 30 in chain 5 and correctly emit "success" to the dmesg. OTOH, sending single-tagged vlan packet: cat <<ENDS | text2pcap - - | tcpreplay -i veth1 - 0000 00 00 00 00 00 11 00 00 00 00 00 22 81 00 00 14 ...........".... 0010 08 00 45 04 00 2a 04 d2 00 00 7f 11 18 eb 0a 00 ..E..*.......... 0020 00 01 14 00 00 02 00 00 00 00 00 16 e1 bf 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 ............ ENDS will match rule 20, will push the second vlan tag but will *not* match rule 30. IOW, the match at rule 30 fails if the second vlan was freshly pushed by the kernel. Lets look at __skb_flow_dissect working on the double-tagged vlan packet. Here is the relevant code from around net/core/flow_dissector.c:1277 copy-pasted here for convenience: if (dissector_vlan == FLOW_DISSECTOR_KEY_MAX && skb && skb_vlan_tag_present(skb)) { proto = skb->protocol; } else { vlan = __skb_header_pointer(skb, nhoff, sizeof(_vlan), data, hlen, &_vlan); if (!vlan) { fdret = FLOW_DISSECT_RET_OUT_BAD; break; } proto = vlan->h_vlan_encapsulated_proto; nhoff += sizeof(*vlan); } The "else" clause above gets the protocol of the encapsulated packet from the skb data at the network header location. printk debugging has showed that in the good double-tagged packet case proto is htons(0x800 == ETH_P_IP) as expected. However in the single-tagged packet case proto is garbage leading to the failure to match tc filter 30. proto is being set from the skb header pointed by nhoff parameter which is defined at the beginning of __skb_flow_dissect (net/core/flow_dissector.c:1055 in the current version): nhoff = skb_network_offset(skb); Therefore the culprit seems to be that the skb network offset is different between double-tagged packet received from the interface and single-tagged packet having its vlan tag pushed by TC. Lets look at the interesting points of the lifetime of the single/double tagged packets as they traverse our packet flow. Both of them will start at __netif_receive_skb_core where the first vlan tag will be stripped: if (eth_type_vlan(skb->protocol)) { skb = skb_vlan_untag(skb); if (unlikely(!skb)) goto out; } At this stage in double-tagged case skb->data points to the second vlan tag while in single-tagged case skb->data points to the network (eg. IP) header. Looking at TC vlan push action (net/sched/act_vlan.c) we have the following code at tcf_vlan_act (interesting points are in square brackets): if (skb_at_tc_ingress(skb)) [1] skb_push_rcsum(skb, skb->mac_len); .... case TCA_VLAN_ACT_PUSH: err = skb_vlan_push(skb, p->tcfv_push_proto, p->tcfv_push_vid | (p->tcfv_push_prio << VLAN_PRIO_SHIFT), 0); if (err) goto drop; break; .... out: if (skb_at_tc_ingress(skb)) [3] skb_pull_rcsum(skb, skb->mac_len); And skb_vlan_push (net/core/skbuff.c:6204) function does: err = __vlan_insert_tag(skb, skb->vlan_proto, skb_vlan_tag_get(skb)); if (err) return err; skb->protocol = skb->vlan_proto; [2] skb->mac_len += VLAN_HLEN; in the case of pushing the second tag. Lets look at what happens with skb->data of the single-tagged packet at each of the above points: 1. As a result of the skb_push_rcsum, skb->data is moved back to the start of the packet. 2. First VLAN tag is moved from the skb into packet buffer, skb->mac_len is incremented, skb->data still points to the start of the packet. 3. As a result of the skb_pull_rcsum, skb->data is moved forward by the modified skb->mac_len, thus pointing to the network header again. Then __skb_flow_dissect will get confused by having double-tagged vlan packet with the skb->data at the network header. The solution for the bug is to preserve "skb->data at second vlan header" semantics in the skb_vlan_push function. We do this by manipulating skb->network_header rather than skb->mac_len. skb_vlan_push callers are updated to do skb_reset_mac_len. More about the patch series: * patch 1 fixes skb_vlan_push and the callers * patch 2 adds ingress tc_actions test * patch 3 adds egress tc_actions test ==================== Link: https://patch.msgid.link/20240822103510.468293-1-boris.sukholitko@broadcom.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-08-27selftests: tc_actions: test egress 2nd vlan pushBoris Sukholitko1-1/+24
Add new test checking the correctness of inner vlan flushing to the skb data when outer vlan tag is added through act_vlan on egress. Signed-off-by: Boris Sukholitko <boris.sukholitko@broadcom.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-08-27selftests: tc_actions: test ingress 2nd vlan pushBoris Sukholitko1-1/+22
Add new test checking the correctness of inner vlan flushing to the skb data when outer vlan tag is added through act_vlan on ingress. Signed-off-by: Boris Sukholitko <boris.sukholitko@broadcom.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-08-27tc: adjust network header after 2nd vlan pushBoris Sukholitko4-3/+9
<tldr> skb network header of the single-tagged vlan packet continues to point the vlan payload (e.g. IP) after second vlan tag is pushed by tc act_vlan. This causes problem at the dissector which expects double-tagged packet network header to point to the inner vlan. The fix is to adjust network header in tcf_act_vlan.c but requires refactoring of skb_vlan_push function. </tldr> Consider the following shell script snippet configuring TC rules on the veth interface: ip link add veth0 type veth peer veth1 ip link set veth0 up ip link set veth1 up tc qdisc add dev veth0 clsact tc filter add dev veth0 ingress pref 10 chain 0 flower \ num_of_vlans 2 cvlan_ethtype 0x800 action goto chain 5 tc filter add dev veth0 ingress pref 20 chain 0 flower \ num_of_vlans 1 action vlan push id 100 \ protocol 0x8100 action goto chain 5 tc filter add dev veth0 ingress pref 30 chain 5 flower \ num_of_vlans 2 cvlan_ethtype 0x800 action simple sdata "success" Sending double-tagged vlan packet with the IP payload inside: cat <<ENDS | text2pcap - - | tcpreplay -i veth1 - 0000 00 00 00 00 00 11 00 00 00 00 00 22 81 00 00 64 ..........."...d 0010 81 00 00 14 08 00 45 04 00 26 04 d2 00 00 7f 11 ......E..&...... 0020 18 ef 0a 00 00 01 14 00 00 02 00 00 00 00 00 12 ................ 0030 e1 c7 00 00 00 00 00 00 00 00 00 00 ............ ENDS will match rule 10, goto rule 30 in chain 5 and correctly emit "success" to the dmesg. OTOH, sending single-tagged vlan packet: cat <<ENDS | text2pcap - - | tcpreplay -i veth1 - 0000 00 00 00 00 00 11 00 00 00 00 00 22 81 00 00 14 ...........".... 0010 08 00 45 04 00 2a 04 d2 00 00 7f 11 18 eb 0a 00 ..E..*.......... 0020 00 01 14 00 00 02 00 00 00 00 00 16 e1 bf 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 ............ ENDS will match rule 20, will push the second vlan tag but will *not* match rule 30. IOW, the match at rule 30 fails if the second vlan was freshly pushed by the kernel. Lets look at __skb_flow_dissect working on the double-tagged vlan packet. Here is the relevant code from around net/core/flow_dissector.c:1277 copy-pasted here for convenience: if (dissector_vlan == FLOW_DISSECTOR_KEY_MAX && skb && skb_vlan_tag_present(skb)) { proto = skb->protocol; } else { vlan = __skb_header_pointer(skb, nhoff, sizeof(_vlan), data, hlen, &_vlan); if (!vlan) { fdret = FLOW_DISSECT_RET_OUT_BAD; break; } proto = vlan->h_vlan_encapsulated_proto; nhoff += sizeof(*vlan); } The "else" clause above gets the protocol of the encapsulated packet from the skb data at the network header location. printk debugging has showed that in the good double-tagged packet case proto is htons(0x800 == ETH_P_IP) as expected. However in the single-tagged packet case proto is garbage leading to the failure to match tc filter 30. proto is being set from the skb header pointed by nhoff parameter which is defined at the beginning of __skb_flow_dissect (net/core/flow_dissector.c:1055 in the current version): nhoff = skb_network_offset(skb); Therefore the culprit seems to be that the skb network offset is different between double-tagged packet received from the interface and single-tagged packet having its vlan tag pushed by TC. Lets look at the interesting points of the lifetime of the single/double tagged packets as they traverse our packet flow. Both of them will start at __netif_receive_skb_core where the first vlan tag will be stripped: if (eth_type_vlan(skb->protocol)) { skb = skb_vlan_untag(skb); if (unlikely(!skb)) goto out; } At this stage in double-tagged case skb->data points to the second vlan tag while in single-tagged case skb->data points to the network (eg. IP) header. Looking at TC vlan push action (net/sched/act_vlan.c) we have the following code at tcf_vlan_act (interesting points are in square brackets): if (skb_at_tc_ingress(skb)) [1] skb_push_rcsum(skb, skb->mac_len); .... case TCA_VLAN_ACT_PUSH: err = skb_vlan_push(skb, p->tcfv_push_proto, p->tcfv_push_vid | (p->tcfv_push_prio << VLAN_PRIO_SHIFT), 0); if (err) goto drop; break; .... out: if (skb_at_tc_ingress(skb)) [3] skb_pull_rcsum(skb, skb->mac_len); And skb_vlan_push (net/core/skbuff.c:6204) function does: err = __vlan_insert_tag(skb, skb->vlan_proto, skb_vlan_tag_get(skb)); if (err) return err; skb->protocol = skb->vlan_proto; [2] skb->mac_len += VLAN_HLEN; in the case of pushing the second tag. Lets look at what happens with skb->data of the single-tagged packet at each of the above points: 1. As a result of the skb_push_rcsum, skb->data is moved back to the start of the packet. 2. First VLAN tag is moved from the skb into packet buffer, skb->mac_len is incremented, skb->data still points to the start of the packet. 3. As a result of the skb_pull_rcsum, skb->data is moved forward by the modified skb->mac_len, thus pointing to the network header again. Then __skb_flow_dissect will get confused by having double-tagged vlan packet with the skb->data at the network header. The solution for the bug is to preserve "skb->data at second vlan header" semantics in the skb_vlan_push function. We do this by manipulating skb->network_header rather than skb->mac_len. skb_vlan_push callers are updated to do skb_reset_mac_len. Signed-off-by: Boris Sukholitko <boris.sukholitko@broadcom.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-08-26Merge branch 'add-embedded-sync-feature-for-a-dpll-s-pin'Jakub Kicinski8-5/+417
Arkadiusz Kubalewski says: ==================== Add Embedded SYNC feature for a dpll's pin Introduce and allow DPLL subsystem users to get/set capabilities of Embedded SYNC on a dpll's pin. Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> ==================== Link: https://patch.msgid.link/20240822222513.255179-1-arkadiusz.kubalewski@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26ice: add callbacks for Embedded SYNC enablement on dpll pinsArkadiusz Kubalewski2-3/+221
Allow the user to get and set configuration of Embedded SYNC feature on the ice driver dpll pins. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20240822222513.255179-3-arkadiusz.kubalewski@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26dpll: add Embedded SYNC feature for a pinArkadiusz Kubalewski6-2/+196
Implement and document new pin attributes for providing Embedded SYNC capabilities to the DPLL subsystem users through a netlink pin-get do/dump messages. Allow the user to set Embedded SYNC frequency with pin-set do netlink message. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20240822222513.255179-2-arkadiusz.kubalewski@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26net: dpaa: reduce number of synchronize_net() callsXi Huang1-1/+2
In the function dpaa_napi_del(), we execute the netif_napi_del() for each cpu, which is actually a high overhead operation because each call to netif_napi_del() contains a synchronize_net(), i.e. an RCU operation. In fact, it is only necessary to call __netif_napi_del and use synchronize_net() once outside of the loop. This change is similar to commit 2543a6000e593a ("gro_cells: reduce number of synchronize_net() calls") and commit 5198d545dba8ad (" net: remove napi_hash_del() from driver-facing API") 5198d545db. Signed-off-by: Xi Huang <xuiagnh@gmail.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20240822072042.42750-1-xuiagnh@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26ipv6: avoid indirect calls for SOL_IP socket optionsEric Dumazet1-2/+2
ipv6_setsockopt() can directly call ip_setsockopt() instead of going through udp_prot.setsockopt() ipv6_getsockopt() can directly call ip_getsockopt() instead of going through udp_prot.getsockopt() These indirections predate git history, not sure why they were there. Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20240823140019.3727643-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26net/ipv4: fix macro definition sk_for_each_bound_bhashHongbo Li1-1/+1
The macro sk_for_each_bound_bhash accepts a parameter __sk, but it was not used, rather the sk2 is directly used, so we replace the sk2 with __sk in macro. Signed-off-by: Hongbo Li <lihongbo22@huawei.com> Link: https://patch.msgid.link/20240823070453.3327832-1-lihongbo22@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26tcp: avoid reusing FIN_WAIT2 when trying to find port in connect() processJason Xing1-0/+3
We found that one close-wait socket was reset by the other side due to a new connection reusing the same port which is beyond our expectation, so we have to investigate the underlying reason. The following experiment is conducted in the test environment. We limit the port range from 40000 to 40010 and delay the time to close() after receiving a fin from the active close side, which can help us easily reproduce like what happened in production. Here are three connections captured by tcpdump: 127.0.0.1.40002 > 127.0.0.1.9999: Flags [S], seq 2965525191 127.0.0.1.9999 > 127.0.0.1.40002: Flags [S.], seq 2769915070 127.0.0.1.40002 > 127.0.0.1.9999: Flags [.], ack 1 127.0.0.1.40002 > 127.0.0.1.9999: Flags [F.], seq 1, ack 1 // a few seconds later, within 60 seconds 127.0.0.1.40002 > 127.0.0.1.9999: Flags [S], seq 2965590730 127.0.0.1.9999 > 127.0.0.1.40002: Flags [.], ack 2 127.0.0.1.40002 > 127.0.0.1.9999: Flags [R], seq 2965525193 // later, very quickly 127.0.0.1.40002 > 127.0.0.1.9999: Flags [S], seq 2965590730 127.0.0.1.9999 > 127.0.0.1.40002: Flags [S.], seq 3120990805 127.0.0.1.40002 > 127.0.0.1.9999: Flags [.], ack 1 As we can see, the first flow is reset because: 1) client starts a new connection, I mean, the second one 2) client tries to find a suitable port which is a timewait socket (its state is timewait, substate is fin_wait2) 3) client occupies that timewait port to send a SYN 4) server finds a corresponding close-wait socket in ehash table, then replies with a challenge ack 5) client sends an RST to terminate this old close-wait socket. I don't think the port selection algo can choose a FIN_WAIT2 socket when we turn on tcp_tw_reuse because on the server side there remain unread data. In some cases, if one side haven't call close() yet, we should not consider it as expendable and treat it at will. Even though, sometimes, the server isn't able to call close() as soon as possible like what we expect, it can not be terminated easily, especially due to a second unrelated connection happening. After this patch, we can see the expected failure if we start a connection when all the ports are occupied in fin_wait2 state: "Ncat: Cannot assign requested address." Reported-by: Jade Dong <jadedong@tencent.com> Signed-off-by: Jason Xing <kernelxing@tencent.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20240823001152.31004-1-kerneljasonxing@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26Merge branch 'net-pse-pd-tps23881-reset-gpio-support'Jakub Kicinski2-0/+24
Kyle Swenson says: ==================== net: pse-pd: tps23881: Reset GPIO support On some boards, the TPS2388x's reset line (active low) is pulled low to keep the chip in reset until the SoC pulls the device out of reset. This series updates the device-tree binding for the tps23881 and then adds support for the reset gpio handling in the tps23881 driver. v1: https://lore.kernel.org/20240819190151.93253-1-kyle.swenson@est.tech ==================== Link: https://patch.msgid.link/20240822220100.3030184-1-kyle.swenson@est.tech Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26net: pse-pd: tps23881: Support reset-gpiosKyle Swenson1-0/+21
The TPS23880/1 has an active-low reset pin that some boards connect to the SoC to control when the TPS23880 is pulled out of reset. Add support for this via a reset-gpios property in the DTS. Signed-off-by: Kyle Swenson <kyle.swenson@est.tech> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20240822220100.3030184-3-kyle.swenson@est.tech Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26dt-bindings: pse: tps23881: add reset-gpiosKyle Swenson1-0/+3
The TPS23881 has an active-low reset pin that can be connected to an SoC. Document this with the device-tree binding. Signed-off-by: Kyle Swenson <kyle.swenson@est.tech> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20240822220100.3030184-2-kyle.swenson@est.tech Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26net: ag71xx: move clk_eth out of structRosen Penev1-4/+4
It's only used in one place. It doesn't need to be in the struct. Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20240822192758.141201-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26l2tp: avoid overriding sk->sk_user_dataCong Wang1-0/+3
Although commit 4a4cd70369f1 ("l2tp: don't set sk_user_data in tunnel socket") removed sk->sk_user_data usage, setup_udp_tunnel_sock() still touches sk->sk_user_data, this conflicts with sockmap which also leverages sk->sk_user_data to save psock. Restore this sk->sk_user_data check to avoid such conflicts. Fixes: 4a4cd70369f1 ("l2tp: don't set sk_user_data in tunnel socket") Reported-by: syzbot+8dbe3133b840c470da0e@syzkaller.appspotmail.com Cc: Tom Parkin <tparkin@katalix.com> Signed-off-by: Cong Wang <cong.wang@bytedance.com> Tested-by: James Chapman <jchapman@katalix.com> Reviewed-by: James Chapman <jchapman@katalix.com> Link: https://patch.msgid.link/20240822182544.378169-1-xiyou.wangcong@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26Merge branch 'net-xilinx-axienet-multicast-fixes-and-improvements'Jakub Kicinski2-21/+22
Sean Anderson says: ==================== net: xilinx: axienet: Multicast fixes and improvements This series has a few small patches improving the handling of multicast addresses. In particular, it makes the driver a whole lot less spammy, and adjusts things so we aren't in promiscuous mode when we have more than four multicast addresses (a common occurance on modern systems). As the hardware has a 4-entry CAM, the ideal method would be to "pack" multiple addresses into one CAM entry. Something like: entry.address = address[0] | address[1]; entry.mask = ~(address[0] ^ address[1]); Which would make the entry match both addresses (along with some others that would need to be filtered in software). Mapping addresses to entries in an efficient way is a bit tricky. If anyone knows of an in-tree example of something like this, I'd be glad to hear about it. ==================== Link: https://patch.msgid.link/20240822154059.1066595-1-sean.anderson@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26net: xilinx: axienet: Support IFF_ALLMULTISean Anderson2-14/+22
Add support for IFF_ALLMULTI by configuring a single filter to match the multicast address bit. This allows us to keep promiscuous mode disabled, even when we have more than four multicast addresses. An even better solution would be to "pack" addresses into the available CAM registers, but that can wait for a future series. Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240822154059.1066595-6-sean.anderson@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26net: xilinx: axienet: Don't set IFF_PROMISC in ndev->flagsSean Anderson1-5/+0
Contrary to the comment, we don't have to inform the net subsystem. Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240822154059.1066595-5-sean.anderson@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26net: xilinx: axienet: Don't print if we go into promiscuous modeSean Anderson1-2/+0
A message about being in promiscuous mode is printed every time each additional multicast address beyond four is added. Suppress this message like is done in other drivers. Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240822154059.1066595-4-sean.anderson@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26Merge branch 'some-modifications-to-optimize-code-readability'Jakub Kicinski3-7/+6
Li Zetao says: ==================== Some modifications to optimize code readability This patchset is mainly optimized for readability in contexts where size needs to be determined. By using min() or max(), or even directly removing redundant judgments (such as the 5th patch), the code is more consistent with the context. ==================== Link: https://patch.msgid.link/20240822133908.1042240-1-lizetao1@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26tipc: use min() to simplify the codeLi Zetao1-1/+1
When calculating size of own domain based on number of peers, the result should be less than MAX_MON_DOMAIN, so using min() here is very semantic. Signed-off-by: Li Zetao <lizetao1@huawei.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240822133908.1042240-8-lizetao1@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26ipv6: mcast: use min() to simplify the codeLi Zetao1-2/+3
When coping sockaddr in ip6_mc_msfget(), the time of copies depends on the minimum value between sl_count and gf_numsrc. Using min() here is very semantic. Signed-off-by: Li Zetao <lizetao1@huawei.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240822133908.1042240-7-lizetao1@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26net: caif: use max() to simplify the codeLi Zetao1-4/+2
When processing the tail append of sk buffer, the final length needs to be determined based on expectlen and addlen. Using max() here can increase the readability of the code. Signed-off-by: Li Zetao <lizetao1@huawei.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240822133908.1042240-4-lizetao1@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26Merge branch 'net-header-and-core-spelling-corrections'Jakub Kicinski43-89/+93
Simon Horman says: ==================== net: header and core spelling corrections This patchset addresses a number of spelling errors in comments in Networking files under include/, and files in net/core/. Spelling problems are as flagged by codespell. It aims to provide patches that can be accepted directly into net-next. And splits patches up based on maintainer boundaries: many things feed directly into net-next. This is a complex process and I apologise for any errors. I also plan to address, via separate patches, spelling errors in other files in the same directories, for files whose changes typically go through trees other than net-next (which feed into net-next). ==================== Link: https://patch.msgid.link/20240822-net-spell-v1-0-3a98971ce2d2@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26net: Correct spelling in net/coreSimon Horman9-20/+20
Correct spelling in net/core. As reported by codespell. Signed-off-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240822-net-spell-v1-13-3a98971ce2d2@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26net: Correct spelling in headersSimon Horman19-36/+36
Correct spelling in Networking headers. As reported by codespell. Signed-off-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240822-net-spell-v1-12-3a98971ce2d2@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26x25: Correct spelling in x25.hSimon Horman1-1/+1
Correct spelling in x25.h As reported by codespell. Signed-off-by: Simon Horman <horms@kernel.org> Reviewed-by: Martin Schiller <ms@dev.tdt.de> Link: https://patch.msgid.link/20240822-net-spell-v1-11-3a98971ce2d2@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26sctp: Correct spelling in headersSimon Horman2-11/+11
Correct spelling in sctp.h and structs.h. As reported by codespell. Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: Simon Horman <horms@kernel.org> Acked-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/20240822-net-spell-v1-10-3a98971ce2d2@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26net: sched: Correct spelling in headersSimon Horman2-5/+5
Correct spelling in pkt_cls.h and red.h. As reported by codespell. Cc: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240822-net-spell-v1-9-3a98971ce2d2@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26NFC: Correct spelling in headersSimon Horman2-5/+5
Correct spelling in NFC headers. As reported by codespell. Signed-off-by: Simon Horman <horms@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20240822-net-spell-v1-8-3a98971ce2d2@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26netlabel: Correct spelling in netlabel.hSimon Horman1-1/+1
Correct spelling in netlabel.h. As reported by codespell. Cc: Paul Moore <paul@paul-moore.com> Signed-off-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240822-net-spell-v1-7-3a98971ce2d2@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26net: qualcomm: rmnet: Correct spelling in if_rmnet.hSimon Horman1-1/+1
Correct spelling in if_rmnet.h As reported by codespell. Cc: Sean Tranchetti <quic_stranche@quicinc.com> Signed-off-by: Simon Horman <horms@kernel.org> Reviewed-by: Subash Abhinov Kasiviswanathan <quic_subashab@quicinc.com> Link: https://patch.msgid.link/20240822-net-spell-v1-6-3a98971ce2d2@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26bonding: Correct spelling in headersSimon Horman2-2/+5
Correct spelling in bond_3ad.h and bond_alb.h. As reported by codespell. Cc: Jay Vosburgh <jv@jvosburgh.net> Cc: Andy Gospodarek <andy@greyhouse.net> Signed-off-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240822-net-spell-v1-5-3a98971ce2d2@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26ipv6: Correct spelling in ipv6.hSimon Horman1-2/+2
Correct spelling in ip_tunnels.h As reported by codespell. Cc: David Ahern <dsahern@kernel.org> Signed-off-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240822-net-spell-v1-4-3a98971ce2d2@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26ip_tunnel: Correct spelling in ip_tunnels.hSimon Horman1-1/+1
Correct spelling in ip_tunnels.h As reported by codespell. Cc: David Ahern <dsahern@kernel.org> Signed-off-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240822-net-spell-v1-3-3a98971ce2d2@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26s390/iucv: Correct spelling in iucv.hSimon Horman1-1/+1
Correct spelling in iucv.h As reported by codespell. Cc: Alexandra Winter <wintera@linux.ibm.com> Cc: Thorsten Winkler <twinkler@linux.ibm.com> Signed-off-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240822-net-spell-v1-2-3a98971ce2d2@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26packet: Correct spelling in if_packet.hSimon Horman1-3/+4
Correct spelling in if_packet.h As reported by codespell. Signed-off-by: Simon Horman <horms@kernel.org> Acked-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20240822-net-spell-v1-1-3a98971ce2d2@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26Merge branch 'add-support-for-icssg-pa_stats'Jakub Kicinski6-83/+160
MD Danish Anwar says: ==================== Add support for ICSSG PA_STATS This series adds support for PA_STATS. Previously this series was a standalone patch adding documentation for PA_STATS in dt-bindings file ti,pruss.yaml. v1 https://lore.kernel.org/all/20240430121915.1561359-1-danishanwar@ti.com/ v2 https://lore.kernel.org/all/20240529115149.630273-1-danishanwar@ti.com/ v3 https://lore.kernel.org/all/20240625153319.795665-1-danishanwar@ti.com/ v4 https://lore.kernel.org/all/20240729113226.2905928-1-danishanwar@ti.com/ v5 https://lore.kernel.org/all/20240814092033.2984734-1-danishanwar@ti.com/ v6 https://lore.kernel.org/all/20240820091657.4068304-1-danishanwar@ti.com/ ==================== Link: https://patch.msgid.link/20240822122652.1071801-1-danishanwar@ti.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26net: ti: icssg-prueth: Add support for PA StatsMD Danish Anwar5-83/+140
Add support for dumping PA stats registers via ethtool. Firmware maintained stats are stored at PA Stats registers. Also modify emac_get_strings() API to use ethtool_puts(). This commit also maintains consistency between miig_stats and pa_stats by - renaming the array icssg_all_stats to icssg_all_miig_stats - renaming the structure icssg_stats to icssg_miig_stats - renaming ICSSG_STATS() to ICSSG_MIIG_STATS() - changing order of stats related data structures and arrays so that data structures of a certain stats type is clubbed together. Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Link: https://patch.msgid.link/20240822122652.1071801-3-danishanwar@ti.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26dt-bindings: soc: ti: pruss: Add documentation for PA_STATS supportMD Danish Anwar1-0/+20
Add documentation for pa-stats node which is syscon regmap for PA_STATS registers. This will be used to dump statistics maintained by ICSSG firmware. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Roger Quadros <rogerq@kernel.org> Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Link: https://patch.msgid.link/20240822122652.1071801-2-danishanwar@ti.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26Merge branch 'add-alcd-support-to-cable-testing-interface'Jakub Kicinski6-16/+173
Oleksij Rempel says: ==================== Add ALCD Support to Cable Testing Interface This patch series introduces support for Active Link Cable Diagnostics (ALCD) in the ethtool cable testing interface and the DP83TD510 PHY driver. Why ALCD? On a 10BaseT1L interface, TDR (Time Domain Reflectometry) is not possible if the link partner is active - TDR will fail in these cases because it requires interrupting the link. Since the link is active, we already know the cable is functioning, so instead of using TDR, we can use ALCD. ALCD lets us measure cable length without disrupting the active link, which is crucial in environments where network uptime is important. It provides a way to gather diagnostic data without the need for downtime. What's in this series: - Extended the ethtool cable testing interface to specify the source of diagnostic results (TDR or ALCD). - Updated the DP83TD510 PHY driver to use ALCD when the link is active, ensuring we can still get cable length info without dropping the connection. ==================== Link: https://patch.msgid.link/20240822120703.1393130-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26phy: dp83td510: Utilize ALCD for cable length measurement when link is activeOleksij Rempel1-6/+113
In industrial environments where 10BaseT1L PHYs are replacing existing field bus systems like CAN, it's often essential to retain the existing cable infrastructure. After installation, collecting metrics such as cable length is crucial for assessing the quality of the infrastructure. Traditionally, TDR (Time Domain Reflectometry) is used for this purpose. However, TDR requires interrupting the link, and if the link partner remains active, the TDR measurement will fail. Unlike multi-pair systems, where TDR can be attempted during the MDI-X switching window, 10BaseT1L systems face greater challenges. The TDR sequence on 10BaseT1L is longer and coincides with uninterrupted autonegotiation pulses, making TDR impossible when the link partner is active. The DP83TD510 PHY provides an alternative through ALCD (Active Link Cable Diagnostics), which allows for cable length measurement without disrupting an active link. Since a live link indicates no short or open cable states, ALCD can be used effectively to gather cable length information. Enhance the dp83td510 driver by: - Leveraging ALCD to measure cable length when the link is active. - Bypassing TDR when a link is detected, as ALCD provides the required information without disruption. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20240822120703.1393130-4-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26ethtool: Add support for specifying information source in cable test resultsOleksij Rempel2-10/+38
Enhance the ethtool cable test interface by introducing the ability to specify the source of the diagnostic information for cable test results. This is particularly useful for PHYs that offer multiple diagnostic methods, such as Time Domain Reflectometry (TDR) and Active Link Cable Diagnostic (ALCD). Key changes: - Added `ethnl_cable_test_result_with_src` and `ethnl_cable_test_fault_length_with_src` functions to allow specifying the information source when reporting cable test results. - Updated existing `ethnl_cable_test_result` and `ethnl_cable_test_fault_length` functions to use TDR as the default source, ensuring backward compatibility. - Modified the UAPI to support these new attributes, enabling drivers to provide more detailed diagnostic information. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20240822120703.1393130-3-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26ethtool: Extend cable testing interface with result source informationOleksij Rempel3-0/+22
Extend the ethtool netlink cable testing interface by adding support for specifying the source of cable testing results. This allows users to differentiate between results obtained through different diagnostic methods. For example, some TI 10BaseT1L PHYs provide two variants of cable diagnostics: Time Domain Reflectometry (TDR) and Active Link Cable Diagnostic (ALCD). By introducing `ETHTOOL_A_CABLE_RESULT_SRC` and `ETHTOOL_A_CABLE_FAULT_LENGTH_SRC` attributes, this update enables drivers to indicate whether the result was derived from TDR or ALCD, improving the clarity and utility of diagnostic information. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20240822120703.1393130-2-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26net: netconsole: selftests: Create a new netconsole selftestBreno Leitao4-1/+243
Adds a selftest that creates two virtual interfaces, assigns one to a new namespace, and assigns IP addresses to both. It listens on the destination interface using socat and configures a dynamic target on netconsole, pointing to the destination IP address. The test then checks if the message was received properly on the destination interface. Signed-off-by: Breno Leitao <leitao@debian.org> Acked-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20240822095652.3806208-1-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26Merge branch 'netconsole-populate-dynamic-entry-even-if-netpoll-fails'Jakub Kicinski2-9/+21
Breno Leitao says: ==================== netconsole: Populate dynamic entry even if netpoll fails The current implementation of netconsole removes the entry and fails entirely if netpoll fails to initialize. This approach is suboptimal, as it prevents reconfiguration or re-enabling of the target through configfs. While this issue might seem minor if it were rare, it actually occurs frequently when the network module is configured as a loadable module. In such cases, the network is unavailable when netconsole initializes, causing netpoll to fail. This failure forces users to reconfigure the target from scratch, discarding any settings provided via the command line. The proposed change would keep the target available in configfs, albeit in a disabled state. This modification allows users to adjust settings or simply re-enable the target once the network module has loaded, providing a more flexible and user-friendly solution. v2: https://lore.kernel.org/20240819103616.2260006-1-leitao@debian.org v1: https://lore.kernel.org/20240809161935.3129104-1-leitao@debian.org ==================== Link: https://patch.msgid.link/20240822111051.179850-1-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26net: netconsole: Populate dynamic entry even if netpoll failsBreno Leitao1-4/+11
Currently, netconsole discards targets that fail during initialization, causing two issues: 1) Inconsistency between target list and configfs entries * user pass cmdline0, cmdline1. If cmdline0 fails, then cmdline1 becomes cmdline0 in configfs. 2) Inability to manage failed targets from userspace * If user pass a target that fails with netpoll (interface not loaded at netcons initialization time, such as interface is a module), then the target will not exist in the configfs, so, user cannot re-enable or modify it from userspace. Failed targets are now added to the target list and configfs, but remain disabled until manually enabled or reconfigured. This change does not change the behaviour if CONFIG_NETCONSOLE_DYNAMIC is not set. CC: Aijay Adams <aijay@meta.com> Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20240822111051.179850-3-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26netpoll: Ensure clean state on setup failuresBreno Leitao1-5/+10
Modify netpoll_setup() and __netpoll_setup() to ensure that the netpoll structure (np) is left in a clean state if setup fails for any reason. This prevents carrying over misconfigured fields in case of partial setup success. Key changes: - np->dev is now set only after successful setup, ensuring it's always NULL if netpoll is not configured or if netpoll_setup() fails. - np->local_ip is zeroed if netpoll setup doesn't complete successfully. - Added DEBUG_NET_WARN_ON_ONCE() checks to catch unexpected states. - Reordered some operations in __netpoll_setup() for better logical flow. These changes improve the reliability of netpoll configuration, since it assures that the structure is fully initialized or totally unset. Suggested-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20240822111051.179850-2-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Powered by cgit, Gruvboxed by Blaster4385.