- 19 Oct, 2023 23 commits
-
-
Gan Yi Fang authored
The datatype of rx_coalesce_usecs is u32, always larger or equal to zero. Previous checking does not include value 0, this patch removes the checking to handle the value 0. This change in behaviour making the value of 0 cause an error is not a problem because 0 is out of range of rx_coalesce_usecs. Signed-off-by:
Gan Yi Fang <yi.fang.gan@intel.com> Link: https://lore.kernel.org/r/20231018030802.741923-1-yi.fang.gan@intel.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Jakub Kicinski authored
There seems to be no docs for the concept of multiple RSS contexts and how to configure it. I had to explain it three times recently, the last one being the charm, document it. Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Reviewed-by:
Simon Horman <horms@kernel.org> Reviewed-by:
Edward Cree <ecree.xilinx@gmail.com> Link: https://lore.kernel.org/r/20231018010758.2382742-1-kuba@kernel.orgSigned-off-by:
-
Paolo Abeni authored
Yoshihiro Shimoda says: ==================== rswitch: Add PM ops This patch is based on the latest net-next.git / next branch. After applied this patch with the following patches, the system can enter/exit Suspend to Idle without any error: https://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git/commit/?h=next&id=aa4c0bbf820ddb9dd8105a403aa12df57b9e5129 https://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git/commit/?h=next&id=1a5361189b7acac15b9b086b2300a11b7aa84c06 ==================== Link: https://lore.kernel.org/r/20231017113402.849735-1-yoshihiro.shimoda.uh@renesas.comSigned-off-by:
-
Yoshihiro Shimoda authored
Add PM ops for Suspend to Idle. When the system suspended, the Ethernet Serdes's clock will be stopped. So, this driver needs to re-initialize the Ethernet Serdes by phy_init() in renesas_eth_sw_resume(). Otherwise, timeout happened in phy_power_on(). Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by:
-
Yoshihiro Shimoda authored
Array index should not be negative, so modify the condition of rswitch_for_each_enabled_port_continue_reverse() macro, and then use unsigned int instead. Signed-off-by:
-
Jakub Kicinski authored
Jacob Keller says: ==================== Intel Wired LAN Driver Updates 2023-10-17 This series contains cleanups for all the Intel drivers relating to their use of format specifiers and the use of strncpy. Jesse fixes various -Wformat warnings across all the Intel networking, including various cases where a "%s" string format specifier is preferred, and using kasprintf instead of snprintf. Justin replaces all of the uses of the now deprecated strncpy with a more modern string function, primarily strscpy. ==================== Link: https://lore.kernel.org/r/20231017190411.2199743-1-jacob.e.keller@intel.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. We expect netdev->name to be NUL-terminated based on its use with format strings: | if (q_vector->rx.ring && q_vector->tx.ring) | sprintf(q_vector->name, "%s-TxRx-%u", netdev->name, Furthermore, we do not need NUL-padding as netdev is already zero-allocated: | netdev = alloc_etherdev_mq(sizeof(struct igc_adapter), | IGC_MAX_TX_QUEUES); ... alloc_etherdev() -> alloc_etherdev_mq() -> alloc_etherdev_mqs() -> alloc_netdev_mqs() ... | p = kvzalloc(alloc_size, GFP_KERNEL_ACCOUNT | __GFP_RETRY_MAYFAIL); 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> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Link: https://lore.kernel.org/r/20231017190411.2199743-10-jacob.e.keller@intel.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. We expect netdev->name to be NUL-terminated based on its usage with `strlen` and format strings: | if (strlen(netdev->name) < (IFNAMSIZ - 5)) { | sprintf(adapter->tx_ring->name, "%s-tx-0", netdev->name); Moreover, we do not need NUL-padding as netdev is already zero-allocated: | netdev = alloc_etherdev(sizeof(struct igbvf_adapter)); ... alloc_etherdev() -> alloc_etherdev_mq() -> alloc_etherdev_mqs() -> alloc_netdev_mqs() ... | p = kvzalloc(alloc_size, GFP_KERNEL_ACCOUNT | __GFP_RETRY_MAYFAIL); 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 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 see that netdev->name is expected to be NUL-terminated based on its usage with format strings: | sprintf(q_vector->name, "%s-TxRx-%u", netdev->name, | q_vector->rx.ring->queue_index); Furthermore, NUL-padding is not required as netdev is already zero-allocated: | netdev = alloc_etherdev_mq(sizeof(struct igb_adapter), | IGB_MAX_TX_QUEUES); ... alloc_etherdev_mq() -> alloc_etherdev_mqs() -> alloc_netdev_mqs() ... | p = kvzalloc(alloc_size, GFP_KERNEL_ACCOUNT | __GFP_RETRY_MAYFAIL); 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 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. Moreover, `strncat` shouldn't really be used either as per fortify-string.h: * Do not use this function. While FORTIFY_SOURCE tries to avoid * read and write overflows, this is only possible when the sizes * of @p and @q are known to the compiler. Prefer building the * string with formatting, via scnprintf() or similar. Instead, use `scnprintf` with "%s%s" format string. This code is now more readable and robust. 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. A suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. Other implementations of .*get_drvinfo also use strscpy so this patch brings fm10k_get_drvinfo in line as well: igb/igb_ethtool.c +851 static void igb_get_drvinfo(struct net_device *netdev, igbvf/ethtool.c 167:static void igbvf_get_drvinfo(struct net_device *netdev, i40e/i40e_ethtool.c 1999:static void i40e_get_drvinfo(struct net_device *netdev, e1000/e1000_ethtool.c 529:static void e1000_get_drvinfo(struct net_device *netdev, ixgbevf/ethtool.c 211:static void ixgbevf_get_drvinfo(struct net_device *netdev, 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. We can see that netdev->name is expected to be NUL-terminated based on it's usage with format strings: | pr_info("%s NIC Link is Down\n", | netdev->name); A suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. This is in line with other uses of strscpy on netdev->name: $ rg "strscpy\(netdev\->name.*pci.*" drivers/net/ethernet/intel/e1000e/netdev.c 7455: strscpy(netdev->name, pci_name(pdev), sizeof(netdev->name)); drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 10839: strscpy(netdev->name, pci_name(pdev), sizeof(netdev->name)); 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. The "...-1" pattern makes it evident that netdev->name is expected to be NUL-terminated. Meanwhile, it seems NUL-padding is not required due to alloc_etherdev zero-allocating 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. This is in line with other uses of strscpy on netdev->name: $ rg "strscpy\(netdev\->name.*pci.*" drivers/net/ethernet/intel/e1000e/netdev.c 7455: strscpy(netdev->name, pci_name(pdev), sizeof(netdev->name)); drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 10839: strscpy(netdev->name, pci_name(pdev), sizeof(netdev->name)); 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:
-
Jesse Brandeburg authored
Get ahead of the game and fix all the -Wformat=2 noted warnings in the intel drivers directory. There are one set of i40e and iavf warnings I couldn't figure out how to fix because the driver is already using vsnprintf without an explicit "const char *" format string. Tested with both gcc-12 and clang-15. I found gcc-12 runs clean after this series but clang-15 is a little worried about the vsnprintf lines. summary of warnings: drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c:148:34: warning: format string is not a string literal [-Wformat-nonliteral] drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c:1416:24: warning: format string is not a string literal (potentially insecure) [-Wformat-security] drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c:1416:24: note: treat the string as an argument to avoid this drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c:1421:6: warning: format string is not a string literal (potentially insecure) [-Wformat-security] drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c:1421:6: note: treat the string as an argument to avoid this drivers/net/ethernet/intel/igc/igc_ethtool.c:776:24: warning: format string is not a string literal (potentially insecure) [-Wformat-security] drivers/net/ethernet/intel/igc/igc_ethtool.c:776:24: note: treat the string as an argument to avoid this drivers/net/ethernet/intel/igc/igc_ethtool.c:779:6: warning: format string is not a string literal (potentially insecure) [-Wformat-security] drivers/net/ethernet/intel/igc/igc_ethtool.c:779:6: note: treat the string as an argument to avoid this drivers/net/ethernet/intel/iavf/iavf_ethtool.c:199:34: warning: format string is not a string literal [-Wformat-nonliteral] drivers/net/ethernet/intel/igb/igb_ethtool.c:2360:6: warning: format string is not a string literal (potentially insecure) [-Wformat-security] drivers/net/ethernet/intel/igb/igb_ethtool.c:2360:6: note: treat the string as an argument to avoid this drivers/net/ethernet/intel/igb/igb_ethtool.c:2363:6: warning: format string is not a string literal (potentially insecure) [-Wformat-security] drivers/net/ethernet/intel/igb/igb_ethtool.c:2363:6: note: treat the string as an argument to avoid this drivers/net/ethernet/intel/i40e/i40e_ethtool.c:208:34: warning: format string is not a string literal [-Wformat-nonliteral] drivers/net/ethernet/intel/i40e/i40e_ethtool.c:2515:23: warning: format string is not a string literal (potentially insecure) [-Wformat-security] drivers/net/ethernet/intel/i40e/i40e_ethtool.c:2515:23: note: treat the string as an argument to avoid this drivers/net/ethernet/intel/i40e/i40e_ethtool.c:2519:23: warning: format string is not a string literal (potentially insecure) [-Wformat-security] drivers/net/ethernet/intel/i40e/i40e_ethtool.c:2519:23: note: treat the string as an argument to avoid this drivers/net/ethernet/intel/ice/ice_ethtool.c:1064:6: warning: format string is not a string literal (potentially insecure) [-Wformat-security] drivers/net/ethernet/intel/ice/ice_ethtool.c:1064:6: note: treat the string as an argument to avoid this drivers/net/ethernet/intel/ice/ice_ethtool.c:1084:6: warning: format string is not a string literal (potentially insecure) [-Wformat-security] drivers/net/ethernet/intel/ice/ice_ethtool.c:1084:6: note: treat the string as an argument to avoid this drivers/net/ethernet/intel/ice/ice_ethtool.c:1100:24: warning: format string is not a string literal (potentially insecure) [-Wformat-security] drivers/net/ethernet/intel/ice/ice_ethtool.c:1100:24: note: treat the string as an argument to avoid this Suggested-by:
Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by:
Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by:
-
Jesse Brandeburg authored
Fix -Wformat-truncated warnings to complete the intel directories' W=1 clean efforts. The W=1 recently got enhanced with a few new flags and this brought up some new warnings. Switch to using kasprintf() when possible so we always allocate the right length strings. summary of warnings: drivers/net/ethernet/intel/iavf/iavf_virtchnl.c:1425:60: warning: ‘%s’ directive output may be truncated writing 4 bytes into a region of size between 1 and 11 [-Wformat-truncation=] drivers/net/ethernet/intel/iavf/iavf_virtchnl.c:1425:17: note: ‘snprintf’ output between 7 and 17 bytes into a destination of size 13 drivers/net/ethernet/intel/ice/ice_ptp.c:43:27: warning: ‘%s’ directive output may be truncated writing up to 479 bytes into a region of size 64 [-Wformat-truncation=] drivers/net/ethernet/intel/ice/ice_ptp.c:42:17: note: ‘snprintf’ output between 1 and 480 bytes into a destination of size 64 drivers/net/ethernet/intel/igb/igb_main.c:3092:53: warning: ‘%d’ directive output may be truncated writing between 1 and 5 bytes into a region of size between 1 and 13 [-Wformat-truncation=] drivers/net/ethernet/intel/igb/igb_main.c:3092:34: note: directive argument in the range [0, 65535] drivers/net/ethernet/intel/igb/igb_main.c:3092:34: note: directive argument in the range [0, 65535] drivers/net/ethernet/intel/igb/igb_main.c:3090:25: note: ‘snprintf’ output between 23 and 43 bytes into a destination of size 32 Suggested-by:
-
Jakub Kicinski authored
Pedro Tammela says: ==================== selftests: tc-testing: fixes for kselftest While playing around with TuxSuite, we noticed a couple of things were broken for strict CI/automated builds. We had a script that didn't make into the kselftest tarball and a couple of missing Kconfig knobs in our minimal config. ==================== Link: https://lore.kernel.org/r/20231017152309.3196320-1-pctammela@mojatatu.comSigned-off-by:
-
Pedro Tammela authored
Some taprio tests need auxiliary scripts to wait for workqueue events to process. Move them to a dedicated folder in order to package them for the kselftests tarball. Acked-by:
Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
Pedro Tammela <pctammela@mojatatu.com> Link: https://lore.kernel.org/r/20231017152309.3196320-3-pctammela@mojatatu.comSigned-off-by:
-
Pedro Tammela authored
Make sure CI builds using just tc-testing/config can run all tdc tests. Some tests were broken because of missing knobs. Acked-by:
-
Jiawen Wu authored
Since PBA info can be read from lspci, delete txgbe_read_pba_string() and the prints. In addition, delete the redundant MAC address printing. Signed-off-by:
Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20231017100635.154967-1-jiawenwu@trustnetic.comSigned-off-by:
-
Jakub Kicinski authored
Alexander Stein says: ==================== net: fec: Fix device_get_match_data usage this is v2 adressing the regression introduced by commit b0377116 ("net: ethernet: Use device_get_match_data()"). You could also remove the (!dev_info) case for Coldfire as this platform has no quirks. But IMHO this should be kept as long as Coldfire platform data is supported. ==================== Link: https://lore.kernel.org/r/20231017063419.925266-1-alexander.stein@ew.tq-group.comSigned-off-by:
-
Alexander Stein authored
All i.MX platforms (non-Coldfire) use DT nowadays, so their platform ID entries can be removed. Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231017063419.925266-3-alexander.stein@ew.tq-group.comSigned-off-by:
-
Alexander Stein authored
device_get_match_data() expects that of_device_id->data points to actual fec_devinfo data, not a platform_device_id entry. Fix this by adjusting OF device data pointers to their corresponding structs. enum imx_fec_type is now unused and can be removed. Fixes: b0377116 ("net: ethernet: Use device_get_match_data()") Signed-off-by:
-
Muhammad Muzammil authored
iosm_ipc_chnl_cfg.h: Fixed typo iosm_ipc_imem_ops.h: Fixed typo iosm_ipc_mux.h: Fixed typo iosm_ipc_pm.h: Fixed typo iosm_ipc_port.h: Fixed typo iosm_ipc_trace.h: Fixed typo Signed-off-by:
Muhammad Muzammil <m.muzzammilashraf@gmail.com> Reviewed-by:
-
- 18 Oct, 2023 17 commits
-
-
Phil Sutter authored
Assume that caller's 'to' offset really represents an upper boundary for the pattern search, so patterns extending past this offset are to be rejected. The old behaviour also was kind of inconsistent when it comes to fragmentation (or otherwise non-linear skbs): If the pattern started in between 'to' and 'from' offsets but extended to the next fragment, it was not found if 'to' offset was still within the current fragment. Test the new behaviour in a kselftest using iptables' string match. Suggested-by:
Pablo Neira Ayuso <pablo@netfilter.org> Fixes: f72b948d ("[NET]: skb_find_text ignores to argument") Signed-off-by:
Phil Sutter <phil@nwl.cc> Reviewed-by:
Florian Westphal <fw@strlen.de> Reviewed-by:
David S. Miller <davem@davemloft.net>
-
https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-nextDavid S. Miller authored
Florian Westphal says: ==================== netfilter next pull request 2023-10-18 This series contains initial netfilter skb drop_reason support, from myself. First few patches fix up a few spots to make sure we won't trip when followup patches embed error numbers in the upper bits (we already do this in some places). Then, nftables and bridge netfilter get converted to call kfree_skb_reason directly to let tooling pinpoint exact location of packet drops, rather than the existing NF_DROP catchall in nf_hook_slow(). I would like to eventually convert all netfilter modules, but as some callers cannot deal with NF_STOLEN (notably act_ct), more preparation work is needed for this. Last patch gets rid of an ugly 'de-const' cast in nftables. ==================== Signed-off-by: -
David S. Miller authored
Paul Greenwalt says: ==================== ethtool: Add link mode maps for forced speeds The following patch set was initially a part of [1]. As the purpose of the original series was to add the support of the new hardware to the intel ice driver, the refactoring of advertised link modes mapping was extracted to a new set. The patch set adds a common mechanism for mapping Ethtool forced speeds with Ethtool supported link modes, which can be used in drivers code. [1] https://lore.kernel.org/netdev/20230823180633.2450617-1-pawel.chmielewski@intel.com Changelog: v4->v5: Separated ethtool and qede changes into two patches, fixed indentation, and moved ethtool_forced_speed_maps_init() from ioctl.c to ethtool.h v3->v4: Moved the macro for setting fields into the common header file v2->v3: Fixed whitespaces, added missing line at end of file v1->v2: Fixed formatting, typo, moved declaration of iterator to loop line. ==================== Signed-off-by:
-
Pawel Chmielewski authored
Refactor ice_get_link_ksettings to using forced speed to link modes mapping. Suggested-by : Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by:
Pawel Chmielewski <pawel.chmielewski@intel.com> Signed-off-by:
Paul Greenwalt <paul.greenwalt@intel.com> Reviewed-by:
-
Paul Greenwalt authored
Refactor qede_forced_speed_maps_init() to use commen implementation ethtool_forced_speed_maps_init(). The qede driver was compile tested only. Reviewed-by:
-
Paul Greenwalt authored
The need to map Ethtool forced speeds to Ethtool supported link modes is common among drivers. To support this, add a common structure for forced speed maps and a function to init them. This is solution was originally introduced in commit 1d4e4ecc ("qede: populate supported link modes maps on module init") for qede driver. ethtool_forced_speed_maps_init() should be called during driver init with an array of struct ethtool_forced_speed_map to populate the mapping. Definitions for maps themselves are left in the driver code, as the sets of supported link modes may vary between the devices. Suggested-by:
-
Florian Westphal authored
The set backend using this already has to work around this via ugly cast, don't spread this pattern. Signed-off-by: -
Florian Westphal authored
errno is 0 because these hooks are called from prerouting and forward. There is no socket that the errno would ever be propagated to. Other netfilter modules (e.g. nf_nat, conntrack, ...) can be converted in a similar way. Signed-off-by: -
Florian Westphal authored
net_dropmonitor blames core.c:nf_hook_slow. Add NF_DROP_REASON() helper and use it in nft_do_chain(). The helper releases the skb, so exact drop location becomes available. Calling code will observe the NF_STOLEN verdict instead. Adjust nf_hook_slow so we can embed an erro value wih NF_STOLEN verdicts, just like we do for NF_DROP. After this, drop in nftables can be pinpointed to a drop due to a rule or the chain policy. Signed-off-by: -
Florian Westphal authored
Same as previous change: we need to mask out the non-verdict bits, as upcoming patches may embed an errno value in NF_STOLEN verdicts too. NF_DROP could already do this, but not all called functions do this. Checks that only test ret vs NF_ACCEPT are fine, the 'errno parts' are always 0 for those. Signed-off-by: -
Florian Westphal authored
This function calls helpers that can return nf-verdicts, but then those get converted to -1/0 as thats what the caller expects. Theoretically NF_DROP could have an errno number set in the upper 24 bits of the return value. Or any of those helpers could return NF_STOLEN, which would result in use-after-free. This is fine as-is, the called functions don't do this yet. But its better to avoid possible future problems if the upcoming patchset to add NF_DROP_REASON() support gains further users, so remove the 0/-1 translation from the picture and pass the verdicts down to the caller. Signed-off-by: -
Florian Westphal authored
nftables trace infra must mask out the non-verdict bit parts of the return value, else followup changes that 'return errno << 8 | NF_STOLEN' will cause breakage. Signed-off-by: -
Florian Westphal authored
These checks assume that the caller only returns NF_DROP without any errno embedded in the upper bits. This is fine right now, but followup patches will start to propagate such errors to allow kfree_skb_drop_reason() in the called functions, those would then indicate 'errno << 8 | NF_STOLEN'. To not break things we have to mask those parts out. Signed-off-by: -
David S. Miller authored
Jiri Pirko says: ==================== devlink: fix a deadlock when taking devlink instance lock while holding RTNL lock devlink_port_fill() may be called sometimes with RTNL lock held. When putting the nested port function devlink instance attrs, current code takes nested devlink instance lock. In that case lock ordering is wrong. Patch #1 is a dependency of patch #2. Patch #2 converts the peernet2id_alloc() call to rely in RCU so it could called without devlink instance lock. Patch #3 takes device reference for devlink instance making sure that device does not disappear before devlink_release() is called. Patch #4 benefits from the preparations done in patches #2 and #3 and removes the problematic nested devlink lock aquisition. Patched #5-#7 improve documentation to reflect this issue so it is avoided in the future. ==================== Signed-off-by: -
Jiri Pirko authored
Add a documentation for devlink_rel_nested_in_notify() describing the devlink instance locking consequences. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
-
Jiri Pirko authored
Add a note describing the locking order of taking RTNL lock with devlink instance lock. Signed-off-by:
-
Jiri Pirko authored
Add a part talking about nested devlink instances describing the helpers and locking ordering. Signed-off-by:
-
