- 10 Oct, 2023 13 commits
-
-
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: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20231006115822.144152-1-o.rempel@pengutronix.deSigned-off-by: Paolo Abeni <pabeni@redhat.com>
-
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: Paolo Abeni <pabeni@redhat.com>
-
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 <morleyd@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-
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: 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 <morleyd@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-
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 <kuba@kernel.org>
-
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: Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
No longer needed to define type for subset attributes. Remove those. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Link: https://lore.kernel.org/r/20231006114436.1725425-3-jiri@resnulli.usSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Link: https://lore.kernel.org/r/20231006114436.1725425-2-jiri@resnulli.usSigned-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 expect `app_name` to be NUL-terminated: dev_info(&oct->pci_dev->dev, "Running %s (%llu Hz)\n", app_name, CVM_CAST64(cs->corefreq)); ... and it seems NUL-padding is not required, let's opt for strscpy(). For `oct->boardinfo.name/serial_number` let's opt for strscpy() as well since it is expected to be NUL-terminated and does not require NUL-padding as `oct` is zero-initialized in octeon_device.c +707: | buf = vzalloc(size); | if (!buf) | return NULL; | | oct = (struct octeon_device *)buf; Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] 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/20231005-strncpy-drivers-net-ethernet-cavium-liquidio-octeon_device-c-v1-1-9a207cef9438@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. NUL-padding is not required as rep_cfg is memset to 0: | memset(&rep_cfg, 0, sizeof(rep_cfg)); 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/20231005-strncpy-drivers-net-ethernet-cavium-liquidio-lio_vf_rep-c-v1-1-92123a747780@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 know `fw_type` must be NUL-terminated based on use here: | static bool fw_type_is_auto(void) | { | return strncmp(fw_type, LIO_FW_NAME_TYPE_AUTO, | sizeof(LIO_FW_NAME_TYPE_AUTO)) == 0; | } ...and here | module_param_string(fw_type, fw_type, sizeof(fw_type), 0444); Let's opt to NUL-pad the destination buffer as well so that we maintain the same exact behavior that `strncpy` provided here. A suitable replacement is `strscpy_pad` due to the fact that it guarantees both NUL-termination and NUL-padding on the destination buffer. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] 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/20231005-strncpy-drivers-net-ethernet-cavium-liquidio-lio_main-c-v1-1-663e3f1d8f99@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. NUL-padding is not required as drvinfo is memset to 0: | memset(drvinfo, 0, sizeof(struct ethtool_drvinfo)); 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/20231005-strncpy-drivers-net-ethernet-cavium-liquidio-lio_ethtool-c-v1-1-ab565ab4d197@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. A suitable replacement is strscpy() [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. bcm_enet_get_drvinfo() already uses strscpy(), let's match it's implementation: | static void bcm_enet_get_drvinfo(struct net_device *netdev, | struct ethtool_drvinfo *drvinfo) | { | strscpy(drvinfo->driver, bcm_enet_driver_name, sizeof(drvinfo->driver)); | strscpy(drvinfo->bus_info, "bcm63xx", sizeof(drvinfo->bus_info)); | } Note that now bcm_enet_get_drvinfo() and bcm_enetsw_get_drvinfo() do the exact same thing. 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/20231005-strncpy-drivers-net-ethernet-broadcom-bcm63xx_enet-c-v1-1-6823b3c3c443@google.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
- 08 Oct, 2023 1 commit
-
-
Florian Fainelli authored
The driver gained a .ndo_poll_controller() at a time where the TX cleaning process was always done from NAPI which makes this unnecessary. See commit ac3d9dd0 ("netpoll: make ndo_poll_controller() optional") for more background. Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 06 Oct, 2023 26 commits
-
-
Eric Dumazet authored
Exit early if the list is empty. Some applications using TCP zerocopy are calling recvmsg( ... MSG_ERRQUEUE) and hit this case quite often, probably because busy polling only deals with sk_receive_queue. Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20231005114504.642589-1-edumazet@google.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Merge tag 'wireless-next-2023-10-06' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.7 The first pull request for v6.7, with both stack and driver changes. We have a big change how locking is handled in cfg80211 and mac80211 which removes several locks and hopefully simplifies the locking overall. In drivers rtw89 got MCC support and smaller features to other active drivers but nothing out of ordinary. Major changes: cfg80211 - remove wdev mutex, use the wiphy mutex instead - annotate iftype_data pointer with sparse - first kunit tests, for element defrag - remove unused scan_width support mac80211 - major locking rework, remove several locks like sta_mtx, key_mtx etc. and use the wiphy mutex instead - remove unused shifted rate support - support antenna control in frame injection (requires driver support) - convert RX_DROP_UNUSABLE to more detailed reason codes rtw89 - TDMA-based multi-channel concurrency (MCC) support iwlwifi - support set_antenna() operation - support frame injection antenna control ath12k - WCN7850: enable 320 MHz channels in 6 GHz band - WCN7850: hardware rfkill support - WCN7850: enable IEEE80211_HW_SINGLE_SCAN_ON_ALL_BANDS to make scan faster ath11k - add chip id board name while searching board-2.bin * tag 'wireless-next-2023-10-06' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (272 commits) wifi: rtlwifi: remove unreachable code in rtl92d_dm_check_edca_turbo() wifi: rtw89: debug: txpwr table supports Wi-Fi 7 chips wifi: rtw89: debug: show txpwr table according to chip gen wifi: rtw89: phy: set TX power RU limit according to chip gen wifi: rtw89: phy: set TX power limit according to chip gen wifi: rtw89: phy: set TX power offset according to chip gen wifi: rtw89: phy: set TX power by rate according to chip gen wifi: rtw89: mac: get TX power control register according to chip gen wifi: rtlwifi: use unsigned long for rtl_bssid_entry timestamp wifi: rtlwifi: fix EDCA limit set by BT coexistence wifi: rt2x00: fix MT7620 low RSSI issue wifi: rtw89: refine bandwidth 160MHz uplink OFDMA performance wifi: rtw89: refine uplink trigger based control mechanism wifi: rtw89: 8851b: update TX power tables to R34 wifi: rtw89: 8852b: update TX power tables to R35 wifi: rtw89: 8852c: update TX power tables to R67 wifi: rtw89: regd: configure Thailand in regulation type wifi: mac80211: add back SPDX identifier wifi: mac80211: fix ieee80211_drop_unencrypted_mgmt return type/value wifi: rtlwifi: cleanup few rtlxxxx_set_hw_reg() routines ... ==================== Link: https://lore.kernel.org/r/87jzrz6bvw.fsf@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Giulio Benetti authored
This patch adds the BCM5221 PHY support by reusing brcm_fet_*() callbacks and adding quirks for BCM5221 when needed. Cc: Jim Reinhart <jimr@tekvox.com> Cc: James Autry <jautry@tekvox.com> Cc: Matthew Maron <matthewm@tekvox.com> Signed-off-by: Giulio Benetti <giulio.benetti+tekvox@benettiengineering.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20231005182915.153815-1-giulio.benetti@benettiengineering.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== i40e: House-keeping and clean-up Ivan Vecera says: The series makes some house-keeping tasks on i40e driver: Patch 1: Removes unnecessary back pointer from i40e_hw Patch 2: Moves I40E_MASK macro to i40e_register.h where is used Patch 3: Refactors I40E_MDIO_CLAUSE* to use the common macro Patch 4: Add header dependencies to <linux/avf/virtchnl.h> Patch 5: Simplifies memory alloction functions Patch 6: Moves mem alloc structures to i40e_alloc.h Patch 7: Splits i40e_osdep.h to i40e_debug.h and i40e_io.h Patch 8: Removes circular header deps, fixes and cleans headers Patch 9: Moves DDP specific macros and structs to i40e_ddp.c * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: i40e: Move DDP specific macros and structures to i40e_ddp.c i40e: Remove circular header dependencies and fix headers i40e: Split i40e_osdep.h i40e: Move memory allocation structures to i40e_alloc.h i40e: Simplify memory allocation functions virtchnl: Add header dependencies i40e: Refactor I40E_MDIO_CLAUSE* macros i40e: Move I40E_MASK macro to i40e_register.h i40e: Remove back pointer from i40e_hw structure ==================== Link: https://lore.kernel.org/r/20231005162850.3218594-1-anthony.l.nguyen@intel.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 expect netdev->name to be NUL-terminated based on its use with format strings and dev_info(): | dev_info(&adapter->pdev->dev, | "%s link is up %d Mbps %s\n", | netdev->name, adapter->link_speed, | adapter->link_duplex == FULL_DUPLEX ? | "full duplex" : "half duplex"); Furthermore, NUL-padding is not required as netdev is already zero-initialized through alloc_etherdev(). 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/20231005-strncpy-drivers-net-ethernet-atheros-atlx-atl2-c-v1-1-493f113ebfc7@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. A suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. It should be noted that there doesn't currently exist a bug here as DRV_NAME is a small string literal which means no overread bugs are present. Also to note, other ethernet drivers are using strscpy in a similar pattern: | dec/tulip/tulip_core.c | 861: strscpy(info->driver, DRV_NAME, sizeof(info->driver)); | | 8390/ax88796.c | 582: strscpy(info->driver, DRV_NAME, sizeof(info->driver)); | | dec/tulip/dmfe.c | 1077: strscpy(info->driver, DRV_NAME, sizeof(info->driver)); | | 8390/etherh.c | 558: strscpy(info->driver, DRV_NAME, sizeof(info->driver)); 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> Reviewed-by: Lukasz Stelmach <l.stelmach@samsung.com> Link: https://lore.kernel.org/r/20231005-strncpy-drivers-net-ethernet-asix-ax88796c_ioctl-c-v1-1-6fafdc38b170@google.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Linus Walleij authored
As we don't specify the MTU in the driver, the framework will fall back to 1500 bytes and this doesn't work very well when we try to attach a DSA switch: eth1: mtu greater than device maximum ixp4xx_eth c800a000.ethernet eth1: error -22 setting MTU to 1504 to include DSA overhead After locating an out-of-tree patch in OpenWrt I found suitable code to set the MTU on the interface and ported it and updated it. Now the MTU gets set properly. Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20231005-ixp4xx-eth-mtu-v4-1-08c66ed0bc69@linaro.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Harini Katakam authored
Since there's no alternate driver, change this entry from obsolete to orphan. Signed-off-by: Harini Katakam <harini.katakam@amd.com> Link: https://lore.kernel.org/r/20231005131039.25881-1-harini.katakam@amd.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Merge tag 'linux-can-next-for-6.7-20231005' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2023-10-05 The first patch is by Miquel Raynal and fixes a comment in the sja1000 driver. Vincent Mailhol contributes 2 patches that fix W=1 compiler warnings in the etas_es58x driver. Jiapeng Chong's patch removes an unneeded NULL pointer check before dev_put() in the CAN raw protocol. A patch by Justin Stittreplaces a strncpy() by strscpy() in the peak_pci sja1000 driver. The next 5 patches are by me and fix the can_restart() handler and replace BUG_ON()s in the CAN dev helpers with proper error handling. The last 27 patches are also by me and target the at91_can driver. First a new helper function is introduced, the at91_can driver is cleaned up and updated to use the rx-offload helper. * tag 'linux-can-next-for-6.7-20231005' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: (37 commits) can: at91_can: switch to rx-offload implementation can: at91_can: at91_alloc_can_err_skb() introduce new function can: at91_can: at91_irq_err_line(): send error counters with state change can: at91_can: at91_irq_err_line(): make use of can_change_state() and can_bus_off() can: at91_can: at91_irq_err_line(): take reg_sr into account for bus off can: at91_can: at91_irq_err_line(): make use of can_state_get_by_berr_counter() can: at91_can: at91_irq_err(): rename to at91_irq_err_line() can: at91_can: at91_irq_err_frame(): move next to at91_irq_err() can: at91_can: at91_irq_err_frame(): call directly from IRQ handler can: at91_can: at91_poll_err(): increase stats even if no quota left or OOM can: at91_can: at91_poll_err(): fold in at91_poll_err_frame() can: at91_can: add CAN transceiver support can: at91_can: at91_open(): forward request_irq()'s return value in case or an error can: at91_can: at91_chip_start(): don't disable IRQs twice can: at91_can: at91_set_bittiming(): demote register output to debug level can: at91_can: rename struct at91_priv::{tx_next,tx_echo} to {tx_head,tx_tail} can: at91_can: at91_setup_mailboxes(): update comments can: at91_can: add more register definitions can: at91_can: MCR Register: convert to FIELD_PREP() can: at91_can: MSR Register: convert to FIELD_PREP() ... ==================== Link: https://lore.kernel.org/r/20231005195812.549776-1-mkl@pengutronix.deSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Johannes Berg authored
Resolve several conflicts, mostly between changes/fixes in wireless and the locking rework in wireless-next. One of the conflicts actually shows a bug in wireless that we'll want to fix separately. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Kalle Valo <kvalo@kernel.org>
-
Sascha Hauer authored
This implements the led_hw_* hooks to support hardware blinking LEDs on the DP83867 phy. The driver supports all LED modes that have a corresponding TRIGGER_NETDEV_* define. Error and collision do not have a TRIGGER_NETDEV_* define, so these modes are currently not supported. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> #TQMa8MxML/MBa8Mx Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kees Cook authored
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct flow_action_entry. Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: netdev@vger.kernel.org Link: https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci [1] Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kees Cook authored
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct packet_fanout. Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Willem de Bruijn <willemb@google.com> Cc: Anqi Shen <amy.saq@antgroup.com> Cc: netdev@vger.kernel.org Link: https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci [1] Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Chuck points out that we should use the uapi-header property when generating the guard. Otherwise we may generate the same guard as another file in the tree. Tested-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Petr Machata says: ==================== mlxsw: Control the order of blocks in ACL region Amit Cohen writes: For 12 key blocks in the A-TCAM, rules are split into two records, which constitute two lookups. The two records are linked using a "large entry key ID". Due to a Spectrum-4 hardware issue, KVD entries that correspond to key blocks 0 to 5 of 12 key blocks will be placed in the same KVD pipe if they only differ in their "large entry key ID", as it is ignored. This results in a reduced scale, we can insert less than 20k filters and get an error: $ tc -b flower.batch RTNETLINK answers: Input/output error We have an error talking to the kernel To reduce the probability of this issue, we can place key blocks with high entropy in blocks 0 to 5. The idea is to place blocks that are often changed in blocks 0 to 5, for example, key blocks that match on IPv4 addresses or the LSBs of IPv6 addresses. Such placement will reduce the probability of these blocks to be same. Mark several blocks with 'high_entropy' flag and place them in blocks 0 to 5. Note that the list of the blocks is just a suggestion, I will verify it with architects. Currently, there is a one loop that chooses which blocks should be used for a given list of elements and fills the blocks - when a block is chosen, it fills it in the region. To be able to control the order of the blocks, separate between searching blocks and filling them. Several pre-changes are required. Patch set overview: Patch #1 marks several blocks with 'high_entropy' flag. Patches #2-#4 prepare the code for filling blocks at the end of the search. Patch #5 changes the loop to just choose the blocks and fill the blocks at the end. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Amit Cohen authored
The previous patches prepared the code to allow separating between choosing blocks and filling blocks. Do not add blocks as part of the loop that chooses them. When all the required blocks are set in the bitmap 'chosen_blocks_bm', start filling blocks. Iterate over the bitmap twice - first add only blocks that are marked with 'high_entropy' flag. Then, fill the rest of the blocks. The idea is to place key blocks with high entropy in blocks 0 to 5. See more details in previous patches. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Amit Cohen authored
Currently, mlxsw_afk_picker() chooses which blocks will be used for a given list of elements, and fills the blocks during the searching - when a key block is found with most hits, it adds it and removes the elements from the count of hits. This should be changed as we want to be able to choose which blocks will be placed in blocks 0 to 5. To separate between choosing blocks and filling blocks, several pre-changes are required. Currently, the indication of whether all elements were found in the chosen blocks is by the structure 'key_info->elusage'. This structure is updated when block is filled as part of mlxsw_afk_picker_key_info_add(). A following patch will call this function only after choosing all the blocks. Add a bitmap called 'elusage_chosen' to store which elements were chosen in the chosen blocks. Change the condition in the loop to check elements that were chosen, not elements that were already filled in the blocks. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Amit Cohen authored
Currently, mlxsw_afk_picker() chooses which blocks will be used for a given list of elements, and fills the blocks during the searching - when a key block is found with most hits, it adds it and removes the elements from the count of hits. This should be changed as we want to be able to choose which blocks will be placed in blocks 0 to 5. To separate between choosing blocks and filling blocks, several pre-changes are required. During the search, the structure 'mlxsw_afk_picker' is used per block, it contains how many elements from the required list appear in the block. When a block is chosen and filled, this bitmap of elements is cleaned. To be able to fill the blocks at the end, add a bitmap called 'chosen_element' as part of picker. When a block is chosen, copy the 'element' bitmap to it. Use the new bitmap as part of mlxsw_afk_picker_key_info_add(). So later, when filling the block will be done at the end of the searching, we will use the copied bitmap that contains the elements that should be used in the block. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Amit Cohen authored
Currently, mlxsw_afk_picker() chooses which blocks will be used for a given list of elements, and fills the blocks during the searching - when a key block is found with most hits, it adds it and removes the elements from the count of hits. This should be changed as we want to be able to choose which blocks will be placed in blocks 0 to 5. To separate between choosing blocks and filling blocks, several pre-changes are required. The indexes of the chosen blocks should be saved, so then the relevant blocks will be filled at the end of search. Allocate a bitmap for chosen blocks, when a block is found with most hits, set the relevant bit in the bitmap. This bitmap will be used in a following patch. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Amit Cohen authored
For 12 key blocks in the A-TCAM, rules are split into two records, which constitute two lookups. The two records are linked using a "large entry key ID". Due to a Spectrum-4 hardware issue, KVD entries that correspond to key blocks 0 to 5 of 12 key blocks A-TCAM entries will be placed in the same KVD pipe if they only differ in their "large entry key ID", as it is ignored. This results in a reduced scale. To reduce the probability of this issue, we can place key blocks with high entropy in blocks 0 to 5. The idea is to place blocks that are changed often in blocks 0 to 5, for example, key blocks that match on IPv4 addresses or the LSBs of IPv6 addresses. Such placement will reduce the probability of these blocks to be same. Mark several blocks with 'high_entropy' flag, so later we will take into account this flag and place them in blocks 0 to 5. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Edward Cree says: ==================== sfc: conntrack offload for tunnels This series adds support for offloading TC flower rules which require both connection tracking and tunnel decapsulation. Depending on the match keys required, the left-hand-side rule may go in either the Outer Rule table or the Action Rule table. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Edward Cree authored
When a foreign LHS rule (TC rule from a tunnel netdev which requests conntrack lookup) matches on inner headers or enc_key_id, these matches cannot be performed by the Outer Rule table, as the keys are only available after the tunnel type has been identified (by the OR lookup) and the rest of the headers parsed accordingly. Offload such rules with an Action Rule, using the LOOKUP_CONTROL section of the AR response to specify the conntrack and/or recirculation actions, combined with an Outer Rule which performs only the usual Encap Match duties. This processing flow, as it requires two AR lookups per packet, is less performant than OR-CT-AR, so only use it where necessary. Reviewed-by: Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com> Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Edward Cree authored
There were a few places where no extack error message was set, or the extack was not forwarded to callees, potentially resulting in a return of -EOPNOTSUPP with no additional information. Make sure to populate the error message in these cases. In practice this does us no good as TC indirect block callbacks don't come with an extack to fill in; but maybe they will someday and when debugging it's possible to provide a fake extack and emit its message to the console. Reviewed-by: Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com> Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Edward Cree authored
Normally, if a TC filter on a tunnel netdev does not match on any encap fields, we decline to offload it, as it cannot meet our requirement for a <sip,dip,dport> tuple for the encap match. However, if the rule has a nonzero chain_index, then for a packet to reach the rule, it must already have matched a LHS rule which will have included an encap match and determined the tunnel type, so in that case we can offload the right-hand-side rule. Reviewed-by: Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com> Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Edward Cree authored
Allow a tunnel netdevice (such as a vxlan) to offload conntrack lookups, in much the same way as efx netdevs. To ensure this rule does not overlap with other tunnel rules on the same sip,dip,dport tuple, register a pseudo encap match of a new type (EFX_TC_EM_PSEUDO_OR), which unlike PSEUDO_MASK may only be referenced once (because an actual Outer Rule in hardware exists, although its fw_id is not recorded in the encap match entry). Reviewed-by: Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com> Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kees Cook authored
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct nh_group. Cc: David Ahern <dsahern@kernel.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: netdev@vger.kernel.org Link: https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci [1] Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-