- 12 Oct, 2023 2 commits
-
-
Justin Stitt authored
`strncpy` is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. We expect `irqname` to be NUL-terminated based on its use with of_irq_get_byname() -> of_property_match_string() wherein it is used with a format string and a `strcmp`: | pr_debug("comparing %s with %s\n", string, p); | if (strcmp(string, p) == 0) | return i; /* Found it; return index */ NUL-padding is not required as is evident by other assignments to `irqname` which do not NUL-pad: | if (port->flags & MVPP2_F_DT_COMPAT) | snprintf(irqname, sizeof(irqname), "tx-cpu%d", i); | else | snprintf(irqname, sizeof(irqname), "hif%d", i); Considering the above, a suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90Signed-off-by:Justin Stitt <justinstitt@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20231010-strncpy-drivers-net-ethernet-marvell-mvpp2-mvpp2_main-c-v1-1-51be96ad0324@google.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Justin Stitt authored
`strncpy` is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. We can see that linfo->lmac_type is expected to be NUL-terminated based on the `... - 1`'s present in the current code. Presumably making room for a NUL-byte at the end of the buffer. Considering the above, a suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. Let's also prefer the more idiomatic strscpy usage of (dest, src, sizeof(dest)) rather than (dest, src, SOME_LEN). Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90Signed-off-by:
-
- 11 Oct, 2023 26 commits
-
-
Jakub Kicinski authored
Jiri added more careful handling of output of the code generator to avoid wiping out existing files in commit f65f305a ("tools: ynl-gen: use temporary file for rendering") Make use of the -o option in the Makefiles, it is already used by ynl-regen.sh. Link: https://lore.kernel.org/r/20231010202714.4045168-1-kuba@kernel.orgSigned-off-by:
-
Jiri Pirko authored
There is no good reason to specify the version for new protocols. Forbid it in genetlink schema. If the future proves me wrong, this restriction could be easily lifted. Move the version definition in between legacy properties in genetlink-legacy. Suggested-by:
Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20231010074810.191177-1-jiri@resnulli.usSigned-off-by:
-
Jakub Kicinski authored
Jijie Shao says: ==================== add vf fault detect support for HNS3 ethernet driver ==================== Link: https://lore.kernel.org/r/20231007031215.1067758-1-shaojijie@huawei.comSigned-off-by:
-
Jie Wang authored
Currently hns3 driver supports vf fault detect feature. Several ras caused by VF resources don't need to do PF function reset for recovery. The driver only needs to reset the specified VF. So this patch adds process in ras module. New process will get detailed information about ras and do the most correct measures based on these accurate information. Signed-off-by:
Jie Wang <wangjie125@huawei.com> Signed-off-by:
Jijie Shao <shaojijie@huawei.com> Link: https://lore.kernel.org/r/20231007031215.1067758-3-shaojijie@huawei.comSigned-off-by:
-
Jie Wang authored
Currently hns3 driver is designed to support VF fault detect feature in new hardwares. For code compatibility, vf fault detect cap bit is added to the driver. Signed-off-by:
-
David S. Miller authored
Willem de Bruijn says: ==================== add skb_segment kunit coverage As discussed at netconf last week. Some kernel code is exercised in many different ways. skb_segment is a prime example. This ~350 line function has 49 different patches in git blame with 28 different authors. When making a change, e.g., to fix a bug in one specific use case, it is hard to establish through analysis alone that the change does not break the many other paths through the code. It is impractical to exercise all code paths through regression testing from userspace. Add the minimal infrastructure needed to add KUnit tests to networking, and add code coverage for this function. Patch 1 adds the infra and the first simple test case: a linear skb Patch 2 adds variants with frags[] Patch 3 adds variants with frag_list skbs ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Willem de Bruijn authored
Expand the test with these variants that use skb frag_list: - GSO_TEST_FRAG_LIST: frag_skb length is gso_size - GSO_TEST_FRAG_LIST_PURE: same, data exclusively in frag skbs - GSO_TEST_FRAG_LIST_NON_UNIFORM: frag_skb length may vary - GSO_TEST_GSO_BY_FRAGS: frag_skb length defines gso_size, i.e., segs may have varying sizes. Signed-off-by:Willem de Bruijn <willemb@google.com> Reviewed-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
Willem de Bruijn authored
Expand the test with variants - GSO_TEST_NO_GSO: payload size less than or equal to gso_size - GSO_TEST_FRAGS: payload in both linear and page frags - GSO_TEST_FRAGS_PURE: payload exclusively in page frags - GSO_TEST_GSO_PARTIAL: produce one gso segment of multiple of gso_size, plus optionally one non-gso trailer segment Define a test struct that encodes the input gso skb and output segs. Input in terms of linear and fragment lengths. Output as length of each segment. Signed-off-by: -
Willem de Bruijn authored
Add unit testing for skb segment. This function is exercised by many different code paths, such as GSO_PARTIAL or GSO_BY_FRAGS, linear (with or without head_frag), frags or frag_list skbs, etc. It is infeasible to manually run tests that cover all code paths when making changes. The long and complex function also makes it hard to establish through analysis alone that a patch has no unintended side-effects. Add code coverage through kunit regression testing. Introduce kunit infrastructure for tests under net/core, and add this first test. This first skb_segment test exercises a simple case: a linear skb. Follow-on patches will parametrize the test and add more variants. Tested: Built and ran the test with make ARCH=um mrproper ./tools/testing/kunit/kunit.py run \ --kconfig_add CONFIG_NET=y \ --kconfig_add CONFIG_DEBUG_KERNEL=y \ --kconfig_add CONFIG_DEBUG_INFO=y \ --kconfig_add=CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y \ net_core_gso Signed-off-by: -
Yajun Deng authored
Although there is a kfree_skb_reason() helper function that can be used to find the reason why this skb is dropped, but most callers didn't increase one of rx_dropped, tx_dropped, rx_nohandler and rx_otherhost_dropped. For the users, people are more concerned about why the dropped in ip is increasing. Introduce netdev_core_stats_inc() for trace the caller of dev_core_stats_*_inc(). Also, add __code to netdev_core_stats_alloc(), as it's called with small probability. And add noinline make sure netdev_core_stats_inc was never inlined. Signed-off-by:
Yajun Deng <yajun.deng@linux.dev> Suggested-by:
Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
David S. Miller authored
Russell King says: ==================== net: dsa: remove validate method These three patches remove DSA's phylink .validate method which becomes unnecessary once the last two drivers provide phylink capabilities, which this patch set adds. Both of these are best guesses. ==================== Signed-off-by: -
Russell King (Oracle) authored
As all drivers now provide phylink capabilities (including MAC), the if() condition in dsa_port_phylink_validate() will always be true. We will always use the generic validator, which phylink will call itself if the .validate method isn't populated. Thus, there is now no need to implement the .validate method, so this implementation can be removed. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by:
Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by:
-
Russell King (Oracle) authored
Add phylink capabilities for dsa_loop, which I believe being a software construct means that it supports essentially all interface types and all speeds. Signed-off-by:
-
Russell King (Oracle) authored
Add phylink capabilities for vsc73xx. Although this switch driver does populates the .adjust_link method, dsa_slave_phy_setup() will still be used to create phylink instances for the LAN ports, although phylink won't be used for shared links. There are two different classes of switch - 5+1 and 8 port. The 5+1 port switches uses port indicies 0-4 for the user interfaces and 6 for the CPU port. The 8 port is confusing - some comments in the driver imply that port index 7 is used, but the driver actually still uses 6, so that is what we go with. Also, there appear to be no DTs in the kernel tree that are using the 8 port variety. It also looks like port 5 is always skipped. The switch supports 10M, 100M and 1G speeds. It is not clear whether all these speeds are supported on the CPU interface. It also looks like symmetric pause is supported, whether asymmetric pause is as well is unclear. However, it looks like the pause configuration is entirely static, and doesn't depend on negotiation results. So, let's do the best effort we can based on the information found in the driver when creating vsc73xx_phylink_get_caps(). Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
-
Sonia Sharma authored
The switch statement in netvsc_send_completion() is incorrectly validating the length of incoming network packets by falling through to the next case. Avoid the fallthrough. Instead break after a case match and then process the complete() call. The current code has not caused any known failures. But nonetheless, the code should be corrected as a different ordering of the switch cases might cause a length check to fail when it should not. Signed-off-by:
Sonia Sharma <sonia.sharma@linux.microsoft.com> Reviewed-by:
Simon Horman <horms@kernel.org> Signed-off-by:
-
David S. Miller authored
Heng Qi says: ==================== virtio-net: Fix and update interrupt moderation The setting of virtio coalescing parameters involves all-queues and per queue, so we must be careful to synchronize the two. Regarding napi_tx switching, this patch set is not only compatible with the previous way of using tx-frames to switch napi_tx, but also improves the user experience when setting interrupt parameters. This patch set has been tested and was part of the previous netdim patch set[1] and is now being split to be rolled out in steps. [1] https://lore.kernel.org/all/20230811065512.22190-1-hengqi@linux.alibaba.com/ --- v2->v3: 1. Fix a tiny comment. v1->v2: 1. Fix some minor comments and add ack tags. ==================== Signed-off-by:
-
Heng Qi authored
Update a comment because virtio-net now supports both VIRTIO_NET_F_NOTF_COAL and VIRTIO_NET_F_VQ_NOTF_COAL. Signed-off-by:
Heng Qi <hengqi@linux.alibaba.com> Acked-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
-
Heng Qi authored
According to the definition of virtqueue coalescing spec[1]: Upon disabling and re-enabling a transmit virtqueue, the device MUST set the coalescing parameters of the virtqueue to those configured through the VIRTIO_NET_CTRL_NOTF_COAL_TX_SET command, or, if the driver did not set any TX coalescing parameters, to 0. Upon disabling and re-enabling a receive virtqueue, the device MUST set the coalescing parameters of the virtqueue to those configured through the VIRTIO_NET_CTRL_NOTF_COAL_RX_SET command, or, if the driver did not set any RX coalescing parameters, to 0. We need to add this setting for vq resize (ethtool -G) where vq_reset happens. [1] https://lists.oasis-open.org/archives/virtio-dev/202303/msg00415.html Fixes: 394bd877 ("virtio_net: support per queue interrupt coalesce command") Cc: Gavin Li <gavinl@nvidia.com> Signed-off-by:
-
Heng Qi authored
When the user sets a non-zero coalescing parameter to 0 for a specific virtqueue, it does not work as expected, so let's fix this. Fixes: 394bd877 ("virtio_net: support per queue interrupt coalesce command") Reported-by:
Xiaoming Zhao <zxm377917@alibaba-inc.com> Cc: Gavin Li <gavinl@nvidia.com> Signed-off-by:
-
Heng Qi authored
When using .set_coalesce interface to set all queue coalescing parameters, we need to update both per-queue and global save values. Fixes: 394bd877 ("virtio_net: support per queue interrupt coalesce command") Cc: Gavin Li <gavinl@nvidia.com> Signed-off-by:
-
Heng Qi authored
Since virtio-net allows switching napi_tx for per txq, we have to get the specific txq's result now. Fixes: 394bd877 ("virtio_net: support per queue interrupt coalesce command") Cc: Gavin Li <gavinl@nvidia.com> Signed-off-by:
-
Heng Qi authored
Background: 1. Commit 0c465be1 ("virtio_net: ethtool tx napi configuration") uses tx-frames to toggle napi_tx (0 off and 1 on) if notification coalescing is not supported. 2. Commit 31c03aef ("virtio_net: enable napi_tx by default") enables napi_tx for all txqs by default. Status: When virtio-net supports notification coalescing, after initialization, tx-frames is 0 and napi_tx is true. Problem: When the user only wants to set rx coalescing params using ethtool -C eth0 rx-usecs 10, or ethtool -Q eth0 queue_mask 0x1 -C rx-usecs 10, these cmds will carry tx-frames as 0, causing the napi_tx switching condition is satisfied. Then the user gets: netlink error: Device or resource busy. The same happens when trying to set rx-frames, adaptive_rx, adaptive_tx... How to fix: When notification coalescing feature is negotiated, initially make the value of tx-frames to be consistent with napi_tx. For compatibility with the past, it is still supported to use tx-frames to toggle napi_tx. Reported-by:
-
Justin Stitt authored
`strncpy` is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. ethtool_sprintf() is designed specifically for get_strings() usage. Let's replace strncpy in favor of this more robust and easier to understand interface. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90Signed-off-by:
Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20231009-strncpy-drivers-net-dsa-realtek-rtl8365mb-c-v1-1-0537fe9fb08c@google.comSigned-off-by:
-
Justin Stitt authored
`strncpy` is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. ethtool_sprintf() is designed specifically for get_strings() usage. Let's replace strncpy in favor of this more robust and easier to understand interface. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90Signed-off-by:
-
Justin Stitt authored
`strncpy` is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. ethtool_sprintf() is designed specifically for get_strings() usage. Let's replace strncpy in favor of this more robust and easier to understand interface. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90Signed-off-by:
-
Arnd Bergmann authored
After the cops driver is removed, ipddp is now the only CONFIG_DEV_APPLETALK but as far as I can tell, this also has no users and can be removed, making appletalk support purely based on ethertalk, using ethernet hardware. Link: https://lore.kernel.org/netdev/e490dd0c-a65d-4acf-89c6-c06cb48ec880@app.fastmail.com/ Link: https://lore.kernel.org/netdev/9cac4fbd-9557-b0b8-54fa-93f0290a6fb8@schmorgal.com/ Cc: Doug Brown <doug@schmorgal.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20231009141139.1766345-1-arnd@kernel.orgSigned-off-by:
-
- 10 Oct, 2023 12 commits
-
-
Rob Herring authored
It is not necessary to call of_match_device() in probe. If we made it to probe, then we've already successfully matched. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Paolo Abeni <pabeni@redhat.com>
-
Paolo Abeni authored
Petr Machata says: ==================== mlxsw: Fix -Wformat-truncation warnings Ido Schimmel writes: Commit 6d4ab2e9 ("extrawarn: enable format and stringop overflow warnings in W=1") enabled format warnings as part of W=1 builds, resulting in two new warnings in mlxsw. Fix both and target at net-next as the warnings are not indicative of actual bugs. ==================== Link: https://lore.kernel.org/r/cover.1696600763.git.petrm@nvidia.comSigned-off-by:
-
Ido Schimmel authored
Ethtool stats strings cannot be longer than 32 characters ('ETH_GSTRING_LEN'), including the terminating null byte. The format string '%.29s_%.1d' can exceed this limitation if the per-TC counter name exceeds 28 characters. Together with the underscore, the two digits of the TC (bounded at 16) and the terminating null byte, more than 32 characters will be used. Fix this by bounding the counter name at 28 characters which suppresses the following build warning [1]. This does not affect ethtool output since the longest counter name does not exceed this limitation. [1] drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c: In function ‘mlxsw_sp_port_get_strings’: drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c:622:58: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=] 622 | snprintf(*p, ETH_GSTRING_LEN, "%.29s_%.1d", | ^ In function ‘mlxsw_sp_port_get_tc_strings’, inlined from ‘mlxsw_sp_port_get_strings’ at drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c:677:4: drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c:622:17: note: ‘snprintf’ output between 3 and 33 bytes into a destination of size 32 622 | snprintf(*p, ETH_GSTRING_LEN, "%.29s_%.1d", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 623 | mlxsw_sp_port_hw_tc_stats[i].str, tc); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c: In function ‘mlxsw_sp_port_get_strings’: drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c:622:58: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=] 622 | snprintf(*p, ETH_GSTRING_LEN, "%.29s_%.1d", | ^ In function ‘mlxsw_sp_port_get_tc_strings’, inlined from ‘mlxsw_sp_port_get_strings’ at drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c:677:4: drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c:622:17: note: ‘snprintf’ output between 3 and 33 bytes into a destination of size 32 622 | snprintf(*p, ETH_GSTRING_LEN, "%.29s_%.1d", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 623 | mlxsw_sp_port_hw_tc_stats[i].str, tc); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by:Ido Schimmel <idosch@nvidia.com> Reviewed-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
-
Ido Schimmel authored
The name of a thermal zone device cannot be longer than 19 characters ('THERMAL_NAME_LENGTH - 1'). The format string 'mlxsw-lc%d-gearbox%d' can exceed this limitation if the maximum number of line cards and the maximum number of gearboxes on each line card cannot be represented using a single digit. This is not the case with current systems nor future ones. Therefore, increase the size of the result buffer beyond 'THERMAL_NAME_LENGTH' and suppress the following build warning [1]. If this limitation is ever exceeded, we will know about it since the thermal core validates the thermal device's name during registration. [1] drivers/net/ethernet/mellanox/mlxsw/core_thermal.c: In function ‘mlxsw_thermal_gearboxes_init.constprop’: drivers/net/ethernet/mellanox/mlxsw/core_thermal.c:543:71: error: ‘%d’ directive output may be truncated writing between 1 and 3 bytes into a region of size between 1 and 3 [-Werror=format-truncation=] 543 | snprintf(tz_name, sizeof(tz_name), "mlxsw-lc%d-gearbox%d", | ^~ In function ‘mlxsw_thermal_gearbox_tz_init’, inlined from ‘mlxsw_thermal_gearboxes_init.constprop’ at drivers/net/ethernet/mellanox/mlxsw/core_thermal.c:611:9: drivers/net/ethernet/mellanox/mlxsw/core_thermal.c:543:52: note: directive argument in the range [1, 255] 543 | snprintf(tz_name, sizeof(tz_name), "mlxsw-lc%d-gearbox%d", | ^~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/mellanox/mlxsw/core_thermal.c:543:17: note: ‘snprintf’ output between 19 and 23 bytes into a destination of size 20 543 | snprintf(tz_name, sizeof(tz_name), "mlxsw-lc%d-gearbox%d", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 544 | gearbox_tz->slot_index, gearbox_tz->module + 1); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: -
Oleksij Rempel authored
Address an issue in ksz9477_acl_move_entries() where, in the scenario (src_idx == dst_idx), ksz9477_validate_and_get_src_count() returns 0, leading to usage of uninitialized src_count and dst_count variables, which causes undesired behavior as it attempts to move ACL entries around. Fixes: 002841be ("net: dsa: microchip: Add partial ACL support for ksz9477 switches") Reported-by:
Dan Carpenter <dan.carpenter@linaro.org> Suggested-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by:
-
Paolo Abeni authored
David Morley says: ==================== tcp: save flowlabel and use for receiver repathing This patch series stores the last received ipv6 flowlabel. This last received flowlabel is then used to help decide whether a packet is likely an RTO retransmit or the result of a TLP. This new information is used to better inform the flowlabel change decision for data receivers. ==================== Link: https://lore.kernel.org/r/20231006011841.3558307-1-morleyd.kernel@gmail.comSigned-off-by:
-
David Morley authored
This commit changes the data receiver repath behavior to occur after receiving a single duplicate. This can help recover ACK connectivity quicker if a TLP was sent along a nonworking path. For instance, consider the case where we have an initially nonworking forward path and reverse path and subsequently switch to only working forward paths. Before this patch we would have the following behavior. +---------+--------+--------+----------+----------+----------+ | Event | For FL | Rev FL | FP Works | RP Works | Data Del | +---------+--------+--------+----------+----------+----------+ | Initial | A | 1 | N | N | 0 | +---------+--------+--------+----------+----------+----------+ | TLP | A | 1 | N | N | 0 | +---------+--------+--------+----------+----------+----------+ | RTO 1 | B | 1 | Y | N | 1 | +---------+--------+--------+----------+----------+----------+ | RTO 2 | C | 1 | Y | N | 2 | +---------+--------+--------+----------+----------+----------+ | RTO 3 | D | 2 | Y | Y | 3 | +---------+--------+--------+----------+----------+----------+ This patch gets rid of at least RTO 3, avoiding additional unnecessary repaths of a working forward path to a (potentially) nonworking one. In addition, this commit changes the behavior to avoid repathing upon rx of duplicate data if the local endpoint is in CA_Loss (in which case the RTOs will already be changing the outgoing flowlabel). Signed-off-by:
David Morley <morleyd@google.com> Signed-off-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
Yuchung Cheng <ycheng@google.com> Tested-by:
-
David Morley authored
In order to better estimate whether a data packet has been retransmitted or is the result of a TLP, we save the last received ipv6 flowlabel. To make space for this field we resize the "ato" field in inet_connection_sock as the current value of TCP_DELACK_MAX can be fully contained in 8 bits and add a compile_time_assert ensuring this field is the required size. v2: addressed kernel bot feedback about dccp_delack_timer() v3: addressed build error introduced by commit bbf80d71 ("tcp: derive delack_max from rto_min") Signed-off-by:
-
Jakub Kicinski authored
The code supports dumps with no input attributes currently thru a combination of special-casing and luck. Clean up the handling of ops with no inputs. Create empty Structs, and skip printing of empty types. This makes dos with no inputs work. Tested-by:
Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Link: https://lore.kernel.org/r/20231006135032.3328523-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Jiri Pirko says: ==================== tools: ynl-gen: lift type requirement for attribute subsets Remove the requirement from schema files to specify the "type" for attribute subsets and adjust existing schema files. ==================== Link: https://lore.kernel.org/r/20231006114436.1725425-1-jiri@resnulli.usSigned-off-by:
-
Jiri Pirko authored
No longer needed to define type for subset attributes. Remove those. Signed-off-by:
-
Jiri Pirko authored
In case an attribute is used in a subset, the type has to be currently specified. As the attribute is already defined in the original set, this is a redundant information in yaml file, moreover, may lead to inconsistencies. Example: attribute-sets: ... name: pin enum-name: dpll_a_pin attributes: ... - name: parent-id type: u32 ... - name: pin-parent-device subset-of: pin attributes: - name: parent-id type: u32 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Remove the requirement from schema files to specify the "type" for attribute subsets. Signed-off-by:
-
