- 22 Aug, 2023 9 commits
-
-
Justin Stitt authored
Use `strscpy_pad` over `strncpy` for NUL-terminated strings. We can also drop the + 1 from `NFT_OSF_MAXGENRELEN + 1` since `strscpy` will guarantee NUL-termination. Signed-off-by:
Justin Stitt <justinstitt@google.com> Signed-off-by:
Florian Westphal <fw@strlen.de>
-
Justin Stitt authored
Prefer `strscpy_pad` over `strncpy`. Signed-off-by:
-
Justin Stitt authored
Prefer `strscpy_pad` over `strncpy`. Signed-off-by:
-
Justin Stitt authored
Use `strscpy_pad` instead of `strncpy`. Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by:
-
GONG, Ruiqi authored
As suggested by Kees[1], replace the old-style 0-element array members of multiple structs in ebtables.h with modern C99 flexible array. [1]: https://lore.kernel.org/all/5E8E0F9C-EE3F-4B0D-B827-DC47397E2A4A@kernel.org/ [ fw@strlen.de: keep struct ebt_entry_target as-is, causes compiler warning: "variable sized type 'struct ebt_entry_target' not at the end of a struct or class is a GNU extension" ] Link: https://github.com/KSPP/linux/issues/21Signed-off-by:
GONG, Ruiqi <gongruiqi1@huawei.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
GONG, Ruiqi authored
When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ‘fortify_memcpy_chk’, inlined from ‘size_entry_mwt’ at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to ‘__read_overflow2_field’ declared with attribute warning: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror=attribute-warning] 592 | __read_overflow2_field(q_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The compiler is complaining: memcpy(&offsets[1], &entry->watchers_offset, sizeof(offsets) - sizeof(offsets[0])); where memcpy reads beyong &entry->watchers_offset to copy {watchers,target,next}_offset altogether into offsets[]. Silence the warning by wrapping these three up via struct_group(). Signed-off-by:Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by:
-
Zhengchao Shao authored
When the ifdown function in the dst_ops structure is referenced, the input parameter 'how' is always true. In the current implementation of the ifdown interface, ip6_dst_ifdown does not use the input parameter 'how', xfrm6_dst_ifdown and xfrm4_dst_ifdown functions use the input parameter 'unregister'. But false judgment on 'unregister' in xfrm6_dst_ifdown and xfrm4_dst_ifdown is false, so remove the input parameter 'how' in ifdown function. Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by:
Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20230821084104.3812233-1-shaozhengchao@huawei.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
GONG, Ruiqi authored
The following message shows up when compiling with W=1: In function ‘fortify_memcpy_chk’, inlined from ‘alx_get_ethtool_stats’ at drivers/net/ethernet/atheros/alx/ethtool.c:297:2: ./include/linux/fortify-string.h:592:4: error: call to ‘__read_overflow2_field’ declared with attribute warning: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror=attribute-warning] 592 | __read_overflow2_field(q_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In order to get alx stats altogether, alx_get_ethtool_stats() reads beyond hw->stats.rx_ok. Fix this warning by directly copying hw->stats, and refactor the unnecessarily complicated BUILD_BUG_ON btw. Signed-off-by: -
Daniel Golle authored
When switching from 10GBase-R/5GBase-R/USXGMII to one of the interface modes provided by mtk-pcs-lynxi we need to make sure to always perform a full configuration of the PHYA. Implement pcs_disable op which resets the stored interface mode to PHY_INTERFACE_MODE_NA to trigger a full reconfiguration once the LynxI PCS driver had previously been deselected in favor of another PCS driver such as the to-be-added driver for the USXGMII PCS found in MT7988. Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/f23d1a60d2c9d2fb72e32dcb0eaa5f7e867a3d68.1692327891.git.daniel@makrotopia.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
- 21 Aug, 2023 4 commits
-
-
Jakub Kicinski authored
This reverts commit cb39c357. Patch was applied to hastily, the problem is already fixed in Alex's vfio tree: https://lore.kernel.org/all/20230821112237.105872b5.alex.williamson@redhat.com/Signed-off-by:
-
Yang Li authored
Fix some kernel-doc comments to silence the warnings: drivers/net/ethernet/amd/pds_core/auxbus.c:18: warning: Function parameter or member 'pf' not described in 'pds_client_register' drivers/net/ethernet/amd/pds_core/auxbus.c:18: warning: Excess function parameter 'pf_pdev' description in 'pds_client_register' drivers/net/ethernet/amd/pds_core/auxbus.c:58: warning: Function parameter or member 'pf' not described in 'pds_client_unregister' drivers/net/ethernet/amd/pds_core/auxbus.c:58: warning: Excess function parameter 'pf_pdev' description in 'pds_client_unregister' Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
sk_getsockopt() runs locklessly. This means sk->sk_lingertime can be read while other threads are changing its value. Other reads also happen without socket lock being held, and must be annotated. Remove preprocessor logic using BITS_PER_LONG, compilers are smart enough to figure this by themselves. v2: fixed a clang W=1 (-Wtautological-constant-out-of-range-compare) warning (Jakub) Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Hangbin Liu authored
Add extack info for IPv4 address add/delete, which would be useful for users to understand the problem without having to read kernel code. No extack message for the ifa_local checking in __inet_insert_ifa() as it has been checked in find_matching_ifa(). Suggested-by:
Ido Schimmel <idosch@idosch.org> Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
-
- 20 Aug, 2023 12 commits
-
-
Furong Xu authored
1. XGMAC Core does not have hash_filter definition, it uses vlhash(VLAN Hash Filtering) instead, skip hash_filter when XGMAC. 2. Show exact size of Hash Table instead of raw register value. 3. Show full description of safety features defined by Synopsys Databook. 4. When safety feature is configured with no parity, or ECC only, keep FSM Parity Checking disabled. Signed-off-by:
Furong Xu <0x1207@gmail.com> Reviewed-by:
-
David S. Miller authored
Hangbin Liu says: ==================== ipv6: update route when delete source address Currently, when remove an address, the IPv6 route will not remove the prefer source address when the address is bond to other device. Fix this issue and add related tests as Ido and David suggested. ==================== Signed-off-by: -
Hangbin Liu authored
Add a test case for IPv6 source address delete. As David suggested, add tests: - Single device using src address - Two devices with the same source address - VRF with single device using src address - VRF with two devices using src address As Ido points out, in IPv6, the preferred source address is looked up in the same VRF as the first nexthop device. This will give us similar results to IPv4 if the route is installed in the same VRF as the nexthop device, but not when the nexthop device is enslaved to a different VRF. So add tests: - src address and nexthop dev in same VR - src address and nexthop device in different VRF The link local address delete logic is different from the global address. It should only affect the associate device it bonds to. So add tests cases for link local address testing. Here is the test result: IPv6 delete address route tests Single device using src address TEST: Prefsrc removed when src address removed on other device [ OK ] Two devices with the same source address TEST: Prefsrc not removed when src address exist on other device [ OK ] TEST: Prefsrc removed when src address removed on all devices [ OK ] VRF with single device using src address TEST: Prefsrc removed when src address removed on other device [ OK ] VRF with two devices using src address TEST: Prefsrc not removed when src address exist on other device [ OK ] TEST: Prefsrc removed when src address removed on all devices [ OK ] src address and nexthop dev in same VRF TEST: Prefsrc removed from VRF when source address deleted [ OK ] TEST: Prefsrc in default VRF not removed [ OK ] TEST: Prefsrc not removed from VRF when source address exist [ OK ] TEST: Prefsrc in default VRF removed [ OK ] src address and nexthop device in different VRF TEST: Prefsrc not removed from VRF when nexthop dev in diff VRF [ OK ] TEST: Prefsrc not removed in default VRF [ OK ] TEST: Prefsrc removed from VRF when nexthop dev in diff VRF [ OK ] TEST: Prefsrc removed in default VRF [ OK ] Table ID 0 TEST: Prefsrc removed from default VRF when source address deleted [ OK ] Link local source route TEST: Prefsrc not removed when delete ll addr from other dev [ OK ] TEST: Prefsrc removed when delete ll addr [ OK ] TEST: Prefsrc not removed when delete ll addr from other dev [ OK ] TEST: Prefsrc removed even ll addr still exist on other dev [ OK ] Tests passed: 19 Tests failed: 0 Suggested-by: -
Hangbin Liu authored
After deleting an IPv6 address on an interface and cleaning up the related preferred source entries, it is important to ensure that all routes associated with the deleted address are properly cleared. The current implementation of rt6_remove_prefsrc() only checks the preferred source addresses bound to the current device. However, there may be routes that are bound to other devices but still utilize the same preferred source address. To address this issue, it is necessary to also delete entries that are bound to other interfaces but share the same source address with the current device. Failure to delete these entries would leave routes that are bound to the deleted address unclear. Here is an example reproducer (I have omitted unrelated routes): + ip link add dummy1 type dummy + ip link add dummy2 type dummy + ip link set dummy1 up + ip link set dummy2 up + ip addr add 1:2:3:4::5/64 dev dummy1 + ip route add 7:7:7:0::1 dev dummy1 src 1:2:3:4::5 + ip route add 7:7:7:0::2 dev dummy2 src 1:2:3:4::5 + ip -6 route show 1:2:3:4::/64 dev dummy1 proto kernel metric 256 pref medium 7:7:7::1 dev dummy1 src 1:2:3:4::5 metric 1024 pref medium 7:7:7::2 dev dummy2 src 1:2:3:4::5 metric 1024 pref medium + ip addr del 1:2:3:4::5/64 dev dummy1 + ip -6 route show 7:7:7::1 dev dummy1 metric 1024 pref medium 7:7:7::2 dev dummy2 src 1:2:3:4::5 metric 1024 pref medium As Ido reminds, in IPv6, the preferred source address is looked up in the same VRF as the first nexthop device, which is different with IPv4. So, while removing the device checking, we also need to add an ipv6_chk_addr() check to make sure the address does not exist on the other devices of the rt nexthop device's VRF. After fix: + ip addr del 1:2:3:4::5/64 dev dummy1 + ip -6 route show 7:7:7::1 dev dummy1 metric 1024 pref medium 7:7:7::2 dev dummy2 metric 1024 pref medium Reported-by:
Thomas Haller <thaller@redhat.com> Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2170513Reviewed-by:
-
Hangbin Liu authored
As the initial commit 1a017276 ("selftests: Add VRF route leaking tests") said, the IPv6 MTU test fails as source address selection picking ::1. Every time we run the selftest this one report failed. There seems not much meaning to keep reporting a failure for 3 years that no one plan to fix/update. Let't just skip this one first. We can add it back when the issue fixed. Signed-off-by:
-
Patrick Rohr authored
addrconf_prefix_rcv returned early without releasing the inet6_dev pointer when the PIO lifetime is less than accept_ra_min_lft. Fixes: 5027d54a ("net: change accept_ra_min_rtr_lft to affect all RA lifetimes") Cc: Maciej Żenczykowski <maze@google.com> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: David Ahern <dsahern@kernel.org> Cc: Simon Horman <horms@kernel.org> Reviewed-by:
Maciej Żenczykowski <maze@google.com> Signed-off-by:
Patrick Rohr <prohr@google.com> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
-
Eric Dumazet authored
Setting IP_RECVERR and IPV6_RECVERR options to zero currently purges the socket error queue, which was probably not expected for zerocopy and tx_timestamp users. I discovered this issue while preparing commit 6b5f43ea ("inet: move inet->recverr to inet->inet_flags"), I presume this change does not need to be backported to stable kernels. Add skb_errqueue_purge() helper to purge error messages only. Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
David S. Miller authored
Ruan Jinjie says: ==================== net: Return PTR_ERR() for fixed_phy_register() fixed_phy_register() returns not only -EIO or -ENODEV, but also -EPROBE_DEFER, -EINVAL and -EBUSY. The Best practice is to return these error codes with PTR_ERR(). ==================== Signed-off-by: -
Ruan Jinjie authored
fixed_phy_register() returns -EPROBE_DEFER, -EINVAL and -EBUSY, etc, in addition to -EIO. The Best practice is to return these error codes with PTR_ERR(). Signed-off-by:
Ruan Jinjie <ruanjinjie@huawei.com> Signed-off-by:
-
Ruan Jinjie authored
fixed_phy_register() returns -EPROBE_DEFER, -EINVAL and -EBUSY, etc, in addition to -ENODEV. The Best practice is to return these error codes with PTR_ERR(). Signed-off-by:
Doug Berger <opendmb@gmail.com> Signed-off-by:
-
Ruan Jinjie authored
fixed_phy_register() returns -EPROBE_DEFER, -EINVAL and -EBUSY, etc, in addition to -ENODEV. The best practice is to return these error codes with PTR_ERR(). Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Russell King (Oracle) authored
The user ports use RSGMII, but we don't have that, and DT doesn't specify a phy interface mode, so phylib defaults to GMII. These support 1G, 100M and 10M with flow control. It is unknown whether asymetric pause is supported at all speeds. The CPU port uses MII/GMII/RGMII/REVMII by hardware pin strapping, and support speeds specific to each, with full duplex only supported in some modes. Flow control may be supported again by hardware pin strapping, and theoretically is readable through a register but no information is given in the datasheet for that. So, we do a best efforts - and be lenient. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
- 19 Aug, 2023 15 commits
-
-
David S. Miller authored
Ruan Jinjie says: ==================== net: Update and fix return value check for vcap_get_rule() As Simon Horman suggests, update vcap_get_rule() to always return an ERR_PTR() and update the error detection conditions to use IS_ERR(), which would be more cleaner. So se IS_ERR() to update the return value and fix the issue in lan966x_ptp_add_trap(). Changes in v2: - Update vcap_get_rule() to always return an ERR_PTR(). - Update the return value fix in lan966x_ptp_add_trap(). - Update the return value check in sparx5_tc_free_rule_resources(). ==================== Reviewed-by:
-
Ruan Jinjie authored
As Simon Horman suggests, update vcap_get_rule() to always return an ERR_PTR() and update the error detection conditions to use IS_ERR(), so use IS_ERR() to check the return value. Signed-off-by:
-
Ruan Jinjie authored
As Simon Horman suggests, update vcap_get_rule() to always return an ERR_PTR() and update the error detection conditions to use IS_ERR(), so use IS_ERR() to fix the return value issue. Fixes: 72df3489 ("net: lan966x: Add ptp trap rules") Signed-off-by:
-
Ruan Jinjie authored
As Simon Horman suggests, update vcap_get_rule() to always return an ERR_PTR() and update the error detection conditions to use IS_ERR(), which would be more cleaner in this case. Signed-off-by:
-
Russell King (Oracle) authored
xgene_mdio_status is declared static, and is only written once by the driver. It appears to have been this way since the driver was first added to the kernel tree. No other users can be found, so let's remove it. Signed-off-by:
-
Jiri Pirko authored
Currently any error during render leads to output an empty file. That is quite annoying when using tools/net/ynl/ynl-regen.sh which git greps files with content of "YNL-GEN.." and therefore ignores empty files. So once you fail to regen, you have to checkout the file. Avoid that by rendering to a temporary file first, only at the end copy the content to the actual destination. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
-
Kurt Kanzenbach authored
All captured timestamps should be corrected by PHY, MAC and CDC introduced latency/errors. The CDC correction is already used. Enable MAC propagation delay correction as well which is available since commit 26cfb838 ("net: stmmac: correct MAC propagation delay"). Before: |ptp4l[390.458]: rms 7 max 21 freq +177 +/- 14 delay 357 +/- 1 After: |ptp4l[620.012]: rms 7 max 20 freq +195 +/- 14 delay 345 +/- 1 Tested on Intel Elkhart Lake. Signed-off-by:
Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by:
Johannes Zink <j.zink@pengutronix.de> Signed-off-by:
-
Eric Dumazet authored
skb_queue_purge() and __skb_queue_purge() become wrappers around the new generic functions. New SKB_DROP_REASON_QUEUE_PURGE drop reason is added, but users can start adding more specific reasons. Signed-off-by:
-
David S. Miller authored
Guangguan Wang says: ==================== net/smc: several features's implementation for smc v2.1 This patch set implement several new features in SMC v2.1(https:// www.ibm.com/support/pages/node/7009315), including vendor unique experimental options, max connections per lgr negotiation, max links per lgr negotiation. v1 - v2: - rename field fce_v20 to fce_v2_base in struct smc_clc_first_contact_ext_v2x - use smc_get_clc_first_contact_ext in smc_connect _rdma_v2_prepare - adding comment about field vendor_oui in struct smc_clc_msg_smcd - remove comment about SMC_CONN_PER_LGR_MAX in smc_ clc_srv_v2x_features_validate - rename smc_clc_clnt_v2x_features_validate RFC v2 - v1: - more description in commit message - modify SMC_CONN_PER_LGR_xxx and SMC_LINKS_ADD_LNK_xxx macro defination and usage - rename field release_ver to release_nr - remove redundant release version check in client - explicitly set the rc value in smc_llc_cli/srv_add_link RFC v1 - RFC v2: - Remove ini pointer NULL check and fix code style in smc_clc_send_confirm_accept. - Optimize the max_conns check in smc_clc_xxx_v2x_features_validate. ==================== Signed-off-by: -
Guangguan Wang authored
Add SMC_NLA_LGR_R_V2_MAX_CONNS and SMC_NLA_LGR_R_V2_MAX_LINKS to SMCR v2 linkgroup netlink attribute SMC_NLA_LGR_R_V2 for linkgroup's detail info showing. Signed-off-by:
Guangguan Wang <guangguan.wang@linux.alibaba.com> Reviewed-by:
Jan Karcher <jaka@linux.ibm.com> Signed-off-by:
-
Guangguan Wang authored
Support max links per lgr negotiation in clc handshake for SMCR v2.1, which is one of smc v2.1 features. Server makes decision for the final value of max links based on the client preferred max links and self-preferred max links. Here use the minimum value of the client preferred max links and server preferred max links. Client Server Proposal(max links(client preferred)) --------------------------------------> Accept(max links(accepted value)) accepted value=min(client preferred, server preferred) <------------------------------------- Confirm(max links(accepted value)) -------------------------------------> Signed-off-by:Tony Lu <tonylu@linux.alibaba.com> Reviewed-by:
-
Guangguan Wang authored
Support max connections per lgr negotiation for SMCR v2.1, which is one of smc v2.1 features. Server makes decision for the final value of max conns based on the client preferred max conns and self-preferred max conns. Here use the minimum value of client preferred max conns and server preferred max conns. Client Server Proposal(max conns(client preferred)) ------------------------------------> Accept(max conns(accepted value)) accepted value=min(client preferred, server preferred) <----------------------------------- Confirm(max conns(accepted value)) -----------------------------------> Signed-off-by: -
Guangguan Wang authored
Support SMC v2.x features validate for SMC v2.1. This is the frame code for SMC v2.x features validate, and will take effects only when the negotiated release version is v2.1 or later. For Server, v2.x features' validation should be done in smc_clc_srv_ v2x_features_validate when receiving v2.1 or later CLC Proposal Message, such as max conns, max links negotiation, the decision of the final value of max conns and max links should be made in this function. And final check for server when receiving v2.1 or later CLC Confirm Message should be done in smc_clc_v2x_features_confirm_check. For client, v2.x features' validation should be done in smc_clc_clnt_ v2x_features_validate when receiving v2.1 or later CLC Accept Message, for example, the decision to accpt the accepted value or to decline should be made in this function. Signed-off-by:
-
Guangguan Wang authored
Add vendor unique experimental options area in clc handshake. In clc accept and confirm msg, vendor unique experimental options use the 16-Bytes reserved field, which defined in struct smc_clc_fce_gid_ext in previous version. Because of the struct smc_clc_first_contact_ext is widely used and limit the scope of modification, this patch moves the 16-Bytes reserved field out of struct smc_clc_fce_gid_ext, and followed with the struct smc_clc_first_contact_ext in a new struct names struct smc_clc_first_contact_ext_v2x. For SMC-R first connection, in previous version, the struct smc_clc_ first_contact_ext and the 16-Bytes reserved field has already been included in clc accept and confirm msg. Thus, this patch use struct smc_clc_first_contact_ext_v2x instead of the struct smc_clc_first_ contact_ext and the 16-Bytes reserved field in SMC-R clc accept and confirm msg is compatible with previous version. For SMC-D first connection, in previous version, only the struct smc_ clc_first_contact_ext is included in clc accept and confirm msg, and the 16-Bytes reserved field is not included. Thus, when the negotiated smc release version is the version before v2.1, we still use struct smc_clc_first_contact_ext for compatible consideration. If the negotiated smc release version is v2.1 or later, use struct smc_clc_first_contact_ ext_v2x instead. Signed-off-by:
-
Guangguan Wang authored
Support smc release version negotiation in clc handshake based on SMC v2, where no negotiation process for different releases, but for different versions. The latest smc release version was updated to v2.1. And currently there are two release versions of SMCv2, v2.0 and v2.1. In the release version negotiation, client sends the preferred release version by CLC Proposal Message, server makes decision for which release version to use based on the client preferred release version and self-supported release version (here choose the minimum release version of the client preferred and server latest supported), then the decision returns to client by CLC Accept Message. Client confirms the decision by CLC Confirm Message. Client Server Proposal(preferred release version) ------------------------------------> Accept(accpeted release version) min(client preferred, server latest supported) <------------------------------------ Confirm(accpeted release version) ------------------------------------> Signed-off-by:
-
