aboutsummaryrefslogtreecommitdiffstatshomepage
AgeCommit message (Collapse)AuthorFilesLines
2022-10-27net: broadcom: bcm4908_enet: update TX stats after actual transmissionRafał Miłecki1-4/+8
Queueing packets doesn't guarantee their transmission. Update TX stats after hardware confirms consuming submitted data. This also fixes a possible race and NULL dereference. bcm4908_enet_start_xmit() could try to access skb after freeing it in the bcm4908_enet_poll_tx(). Reported-by: Florian Fainelli <f.fainelli@gmail.com> Fixes: 4feffeadbcb2e ("net: broadcom: bcm4908enet: add BCM4908 controller driver") Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20221027112430.8696-1-zajec5@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-27Merge branch 'ip-rework-the-fix-for-dflt-addr-selection-for-connected-nexthop'Jakub Kicinski3-4/+4
Nicolas Dichtel says: ==================== ip: rework the fix for dflt addr selection for connected nexthop" This series reworks the fix that is reverted in the second commit. As Julian explained, nhc_scope is related to nhc_gw, it's not the scope of the route. ==================== Link: https://lore.kernel.org/r/20221020100952.8748-1-nicolas.dichtel@6wind.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-27nh: fix scope used to find saddr when adding non gw nhNicolas Dichtel1-1/+1
As explained by Julian, fib_nh_scope is related to fib_nh_gw4, but fib_info_update_nhc_saddr() needs the scope of the route, which is the scope "before" fib_nh_scope, ie fib_nh_scope - 1. This patch fixes the problem described in commit 747c14307214 ("ip: fix dflt addr selection for connected nexthop"). Fixes: 597cfe4fc339 ("nexthop: Add support for IPv4 nexthops") Link: https://lore.kernel.org/netdev/6c8a44ba-c2d5-cdf-c5c7-5baf97cba38@ssi.bg/ Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Reviewed-by: Julian Anastasov <ja@ssi.bg> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-27Revert "ip: fix dflt addr selection for connected nexthop"Nicolas Dichtel1-1/+1
This reverts commit 747c14307214b55dbd8250e1ab44cad8305756f1. As explained by Julian, nhc_scope is related to nhc_gw, not to the route. Revert the original patch. The initial problem is fixed differently in the next commit. Link: https://lore.kernel.org/netdev/6c8a44ba-c2d5-cdf-c5c7-5baf97cba38@ssi.bg/ Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Reviewed-by: Julian Anastasov <ja@ssi.bg> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-27Revert "ip: fix triggering of 'icmp redirect'"Nicolas Dichtel1-2/+2
This reverts commit eb55dc09b5dd040232d5de32812cc83001a23da6. The patch that introduces this bug is reverted right after this one. Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Reviewed-by: Julian Anastasov <ja@ssi.bg> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-27genetlink: limit the use of validation workarounds to old opsJakub Kicinski1-0/+2
During review of previous change another thing came up - we should limit the use of validation workarounds to old commands. Don't list the workarounds one by one, as we're rejecting all existing ones. We can deal with the masking in the unlikely event that new flag is added. Link: https://lore.kernel.org/all/6ba9f727e555fd376623a298d5d305ad408c3d47.camel@sipsolutions.net/ Link: https://lore.kernel.org/r/20221026001524.1892202-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-27net/mlx5: DR, Remove the buddy used_listYevgeny Kliteynik4-42/+13
No need to have the used_list - we don't need to keep track of the used chunks, we only need to know the amount of used memory. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-10-27net/mlx5: DR, Keep track of hot ICM chunks in an array instead of listYevgeny Kliteynik4-22/+71
When ICM chunk is freed, it might still be accessed by HW until we do sync with HW. This sync is expensive operation, so we don't do it often. Instead, when the chunk is freed, it is moved to the buddy's "hot memory" list. Once sync is done, we traverse the hot list and finally free all the chunks. It appears that traversing a long list takes unusually long time due to cache misses on many entries, which causes a big "hiccup" during rule insertion. This patch deals with this issue the following way: - Move hot chunks list from buddy to pool, so that the pool will keep track of all its hot memory. - Replace the list with pre-allocated array on the memory pool struct, and store only the information that is needed to later free this chunk in its buddy allocator. This cost additional memory for the array that is dynamically allocated, but it allows not to save long list of hot chunks, so at peak times it actually saves memory due to the fact that each array entry is much smaller than the chunk struct. This way an overhead of traversing the long list is virtually removed: the loop of freeing hot chunks takes ~27 msec instead of ~70 msec, where most of it are the actual freeing activities. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-10-27net/mlx5: DR, Lower sync threshold for ICM hot memoryYevgeny Kliteynik1-2/+4
Instead of hiding the math in the code, define a value that sets the fraction of allowed hot memory of ICM pool. Set the threshold for sync of ICM hot chunks to 1/4 of the pool instead of 1/2 of the pool. Although we will have more syncs, each sync will be shorter and will help with insertion rate stability. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-10-27net/mlx5: DR, Allocate htbl from its own slab allocatorYevgeny Kliteynik4-4/+36
SW steering allocates/frees lots of htbl structs. Create a separate kmem_cache and allocate htbls from this allocator. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-10-27net/mlx5: DR, Allocate icm_chunks from their own slab allocatorYevgeny Kliteynik3-3/+24
SW steering allocates/frees lots of icm_chunk structs. To make this more efficiently, create a separate kmem_cache and allocate these chunks from this allocator. By doing this we observe that the alloc/free "hiccups" frequency has become much lower, which allows for a more steady rule insersion rate. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-10-27net/mlx5: DR, Manage STE send info objects in poolYevgeny Kliteynik4-19/+173
Instead of allocating/freeing send info objects dynamically, manage them in pool. The number of send info objects doesn't depend on rules, so after pre-populating the pool with an initial batch of send info objects, the pool is not expected to grow. This way we save alloc/free during writing STEs to ICM, which can sometimes take up to 40msec. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-10-27net/mlx5: DR, In rehash write the line in the entry immediatelyYevgeny Kliteynik1-0/+9
Don't wait for the whole table to be ready - write each row immediately. This way we save allocations of the ste_send_info structure and improve performance. Signed-off-by: Erez Shitrit <erezsh@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-10-27net/mlx5: DR, Handle domain memory resources init/uninit separatelyYevgeny Kliteynik1-18/+37
Handle creation/destruction of all the domain's memory pools and other memory-related fields in a separate init/uninit functions. This simplifies error flow and allows cleaner addition of new pools. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-10-27net/mlx5: DR, Initialize chunk's ste_arrays at chunk creationYevgeny Kliteynik1-21/+4
Rather than cleaning the corresponding chunk's section of ste_arrays on chunk deletion, initialize these areas upon chunk creation. Chunk destruction tend to come in large batches (during pool syncing). To reduce the "hiccup" in such cases, moving ste_arrays init from chunk destruction to initialization. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-10-27net/mlx5: DR, For short chains of STEs, avoid allocating ste_arr dynamicallyYevgeny Kliteynik1-13/+27
While creating rule, ste_arr is an array that is allocated at the start of the function and freed at the end. This memory allocation can sometimes lead to "hiccups" of up to 10ms. However, the common use case is short chains of STEs. For such cases, we can use a local buffer on stack instead. Changes in v2: Use small local array for short rules, allocate dynamically for long rules Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-10-27net/mlx5: DR, Remove unneeded argument from dr_icm_chunk_destroyYevgeny Kliteynik1-6/+5
Remove an argument that can be extracted in the function. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-10-27net/mlx5: DR, Check device state when polling CQYevgeny Kliteynik1-1/+9
Calling fast teardown as part of the normal unloading caused a problem with SW steering - SW steering still needs to clear its tables, write to ICM and poll for completions. When teardown has been done, SW steering keeps polling the CQ forever, because nobody flushes it. This patch fixes the issue by checking the device state in cases where no CQE was returned. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-10-27net/mlx5: DR, Fix the SMFS sync_steering for fast teardownYevgeny Kliteynik1-0/+7
If sync happens when the device is in fast teardown, just bail and don't do anything, because the PCI device is not there any more. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-10-27net/mlx5: DR, In destroy flow, free resources even if FW command failedYevgeny Kliteynik1-1/+1
Otherwise resources will never be freed and refcount will not be decreased. Signed-off-by: Chris Mi <cmi@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2022-10-27net: bcmsysport: Indicate MAC is in charge of PHY PMFlorian Fainelli1-0/+3
Avoid the PHY library call unnecessarily into the suspend/resume functions by setting phydev->mac_managed_pm to true. The SYSTEMPORT driver essentially does exactly what mdio_bus_phy_resume() does by calling phy_resume(). Fixes: fba863b81604 ("net: phy: make PHY PM ops a no-op if MAC driver manages PHY PM") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20221025234201.2549360-1-f.fainelli@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-27skbuff: Proactively round up to kmalloc bucket sizeKees Cook1-26/+26
Instead of discovering the kmalloc bucket size _after_ allocation, round up proactively so the allocation is explicitly made for the full size, allowing the compiler to correctly reason about the resulting size of the buffer through the existing __alloc_size() hint. This will allow for kernels built with CONFIG_UBSAN_BOUNDS or the coming dynamic bounds checking under CONFIG_FORTIFY_SOURCE to gain back the __alloc_size() hints that were temporarily reverted in commit 93dd04ab0b2b ("slab: remove __alloc_size attribute from __kmalloc_track_caller") 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 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: David Rientjes <rientjes@google.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> Link: https://patchwork.kernel.org/project/netdevbpf/patch/20221021234713.you.031-kees@kernel.org/ Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20221025223811.up.360-kees@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-27Merge branch 'net-ipa-don-t-use-fixed-table-sizes'Paolo Abeni14-113/+123
Alex Elder says: ==================== net: ipa: don't use fixed table sizes Currently, routing and filter tables are assumed to have a fixed size for all platforms. In fact, these tables can support many more entries than what has been assumed; the only limitation is the size of the IPA-resident memory regions that contain them. This series rearranges things so that the size of the table is determined from the memory region size defined in configuration data, rather than assuming it is fixed. This will required for IPA versions 5.0+, where the number of entries in a routing table is larger. ==================== Link: https://lore.kernel.org/r/20221025195143.255934-1-elder@linaro.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-27net: ipa: determine filter table size from memory regionAlex Elder4-18/+15
Currently we assume that any filter table contains a fixed number of entries. Like routing tables, the number of entries in a filter table is limited only by the size of the IPA-local memory region used to hold the table. Stop assuming that a filter table has exactly 14 entries. Instead, determine the number of entries in a routing table by dividing its memory region size by the size of an entry. (Note that the first "entry" in a filter table contains an endpoint bitmap.) Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-27net: ipa: don't assume 8 modem routing table entriesAlex Elder13-77/+88
Currently all platforms are assumed allot 8 routing table entries for use by the modem. Instead, add a new configuration data entry that defines the number of modem routing table entries, and record that in the IPA structure. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-27net: ipa: determine route table size from memory regionAlex Elder3-21/+13
Currently we assume that any routing table contains a fixed number of entries. The number of entries in a routing table can actually vary, depending only on the size of the IPA-local memory region used to hold the table. Stop assuming that a routing table has exactly 15 entries. Instead, determine the number of entries in a routing table by dividing its memory region size by the size of an entry. The number of entries is computed early, when ipa_table_mem_valid() is called by ipa_table_init(). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-27net: ipa: record the route table size in the IPA structureAlex Elder2-7/+17
The non-hashed routing tables for IPv4 and IPv6 will be the same size. And if supported, the hashed routing tables will be the same size as the non-hashed tables. Record the size (number of entries) of all routing tables in the IPA structure. For now, initialize this field using IPA_ROUTE_TABLE_MAX, and just do so when the first route table is validated. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-27can: j1939: transport: j1939_session_skb_drop_old(): spin_unlock_irqrestore() before kfree_skb()Yang Yingliang1-1/+3
It is not allowed to call kfree_skb() from hardware interrupt context or with interrupts being disabled. The skb is unlinked from the queue, so it can be freed after spin_unlock_irqrestore(). Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/all/20221027091237.2290111-1-yangyingliang@huawei.com Cc: stable@vger.kernel.org [mkl: adjust subject] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-10-27eth: fealnx: delete the driver for Myson MTD-800Jakub Kicinski5-1966/+0
The git history for this driver seems to be completely automated / tree wide changes. I can't find any boards or systems which would use this chip. Google search shows pictures of towel warmers and no networking products. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/20221025184254.1717982-1-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-27ice: Add support Flex RXDMichal Jaron6-2/+111
Add new VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC flag, opcode VIRTCHNL_OP_GET_SUPPORTED_RXDIDS and add member rxdid in struct virtchnl_rxq_info to support AVF Flex RXD extension. Add support to allow VF to query flexible descriptor RXDIDs supported by DDP package and configure Rx queues with selected RXDID for IAVF. Add code to allow VIRTCHNL_OP_GET_SUPPORTED_RXDIDS message to be processed. Add necessary macros for registers. Signed-off-by: Leyi Rong <leyi.rong@intel.com> Signed-off-by: Xu Ting <ting.xu@intel.com> Signed-off-by: Michal Jaron <michalx.jaron@intel.com> Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com> Tested-by: Maxime Coquelin <maxime.coquelin@redhat.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://lore.kernel.org/r/20221025161252.1952939-1-jacob.e.keller@intel.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-27net: broadcom: bcm4908_enet: use build_skb()Rafał Miłecki1-17/+36
RX code can be more efficient with the build_skb(). Allocating actual SKB around eth packet buffer - right before passing it up - results in a better cache usage. Without RPS (echo 0 > rps_cpus) BCM4908 NAT masq performance "jumps" between two speeds: ~900 Mbps and 940 Mbps (it's a 4 CPUs SoC). This change bumps the lower speed from 905 Mb/s to 918 Mb/s (tested using single stream iperf 2.0.5 traffic). There are more optimizations to consider. One obvious to try is GRO however as BCM4908 doesn't do hw csum is may actually lower performance. Sometimes. Some early testing: ┌─────────────────────────────────┬─────────────────────┬────────────────────┐ │ │ netif_receive_skb() │ napi_gro_receive() │ ├─────────────────────────────────┼─────────────────────┼────────────────────┤ │ netdev_alloc_skb() │ 905 Mb/s │ 892 Mb/s │ │ napi_alloc_frag() + build_skb() │ 918 Mb/s │ 917 Mb/s │ └─────────────────────────────────┴─────────────────────┴────────────────────┘ Another ideas: 1. napi_build_skb() 2. skb_copy_from_linear_data() for small packets Those need proper testing first though. That can be done later. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Link: https://lore.kernel.org/r/20221025132245.22871-1-zajec5@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-27net: ehea: fix possible memory leak in ehea_register_port()Yang Yingliang1-0/+1
If of_device_register() returns error, the of node and the name allocated in dev_set_name() is leaked, call put_device() to give up the reference that was set in device_initialize(), so that of node is put in logical_port_release() and the name is freed in kobject_cleanup(). Fixes: 1acf2318dd13 ("ehea: dynamic add / remove port") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20221025130011.1071357-1-yangyingliang@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-27net: dp83822: Print the SOR1 strap statusFabio Estevam1-0/+2
During the bring-up of the Ethernet PHY, it is very useful to see the bootstrap status information, as it can help identifying hardware bootstrap mistakes. Allow printing the SOR1 register, which contains the strap status to ease the bring-up. Signed-off-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20221025120109.779337-1-festevam@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-27bond: Disable TLS features indicationTariq Toukan3-34/+1
Bond agnostically interacts with TLS device-offload requests via the .ndo_sk_get_lower_dev operation. Return value is true iff bond guarantees fixed mapping between the TLS connection and a lower netdev. Due to this nature, the bond TLS device offload features are not explicitly controllable in the bond layer. As of today, these are read-only values based on the evaluation of bond_sk_check(). However, this indication might be incorrect and misleading, when the feature bits are "fixed" by some dependency features. For example, NETIF_F_HW_TLS_TX/RX are forcefully cleared in case the corresponding checksum offload is disabled. But in fact the bond ability to still offload TLS connections to the lower device is not hurt. This means that these bits can not be trusted, and hence better become unused. This patch revives some old discussion [1] and proposes a much simpler solution: Clear the bond's TLS features bits. Everyone should stop reading them. [1] https://lore.kernel.org/netdev/20210526095747.22446-1-tariqt@nvidia.com/ Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Link: https://lore.kernel.org/r/20221025105300.4718-1-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-27Merge branch 'openvswitch-syzbot-splat-fix-and-introduce-selftest'Paolo Abeni6-1/+586
Aaron Conole says: ==================== openvswitch: syzbot splat fix and introduce selftest Syzbot recently caught a splat when dropping features from openvswitch datapaths that are in-use. The WARN() call is definitely too large a hammer for the situation, so change to pr_warn. Second patch in the series introduces a new selftest suite which can help show that an issue is fixed. This change might be more suited to net-next tree, so it has been separated out as an additional patch and can be either applied to either tree based on preference. ==================== Link: https://lore.kernel.org/r/20221025105018.466157-1-aconole@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-27selftests: add openvswitch selftest suiteAaron Conole5-0/+584
Previous commit resolves a WARN splat that can be difficult to reproduce, but with the ovs-dpctl.py utility, it can be trivial. Introduce a test case which creates a DP, and then downgrades the feature set. This will include a utility 'ovs-dpctl.py' that can be extended to do additional tests and diagnostics. Signed-off-by: Aaron Conole <aconole@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-27openvswitch: switch from WARN to pr_warnAaron Conole1-1/+2
As noted by Paolo Abeni, pr_warn doesn't generate any splat and can still preserve the warning to the user that feature downgrade occurred. We likely cannot introduce other kinds of checks / enforcement here because syzbot can generate different genl versions to the datapath. Reported-by: syzbot+31cde0bef4bbf8ba2d86@syzkaller.appspotmail.com Fixes: 44da5ae5fbea ("openvswitch: Drop user features if old user space attempted to create datapath") Cc: Thomas Graf <tgraf@suug.ch> Signed-off-by: Aaron Conole <aconole@redhat.com> Acked-by: Ilya Maximets <i.maximets@ovn.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-27net: stmmac: remove duplicate dma queue channel macrosJunxiao Chang2-18/+7
It doesn't need extra macros for queue 0 & 4. Same macro could be used for all 8 queues. Related queue/channel functions could be combined together. Original macro which has two same parameters is unsafe macro and might have potential side effects. Each MTL RxQ DMA channel mask is 4 bits, so using (0xf << chan) instead of GENMASK(x + 3, x) to avoid unsafe macro. Signed-off-by: Junxiao Chang <junxiao.chang@intel.com> Link: https://lore.kernel.org/r/20221025081747.1884926-1-junxiao.chang@intel.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-10-27Merge patch series "R-Car CAN-FD fixes"Marc Kleine-Budde1-13/+11
Biju Das <biju.das.jz@bp.renesas.com> says: This patch series fixes the below issues in R-Car CAN-FD driver. 1) Race condition in CAN driver under heavy CAN load condition with both channels enabled results in IRQ storm on global FIFO receive IRQ line. 2) Add channel specific TX interrupts handling for RZ/G2L SoC as it has separate IRQ lines for each TX. changes since v1: https://lore.kernel.org/all/20221022081503.1051257-1-biju.das.jz@bp.renesas.com * Added check for IRQ active and enabled before handling the IRQ on a particular channel. Link: https://lore.kernel.org/all/20221025155657.1426948-1-biju.das.jz@bp.renesas.com [mkl: adjust message, add link, take only patches 1 + 2, upstream 3 via can-next] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-10-27can: rcar_canfd: fix channel specific IRQ handling for RZ/G2LBiju Das1-11/+7
RZ/G2L has separate channel specific IRQs for transmit and error interrupts. But the IRQ handler processes both channels, even if there no interrupt occurred on one of the channels. This patch fixes the issue by passing a channel specific context parameter instead of global one for the IRQ register and the IRQ handler, it just handles the channel which is triggered the interrupt. Fixes: 76e9353a80e9 ("can: rcar_canfd: Add support for RZ/G2L family") Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/all/20221025155657.1426948-3-biju.das.jz@bp.renesas.com Cc: stable@vger.kernel.org [mkl: adjust commit message] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-10-27can: rcar_canfd: rcar_canfd_handle_global_receive(): fix IRQ storm on global FIFO receiveBiju Das1-2/+4
We are seeing an IRQ storm on the global receive IRQ line under heavy CAN bus load conditions with both CAN channels enabled. Conditions: The global receive IRQ line is shared between can0 and can1, either of the channels can trigger interrupt while the other channel's IRQ line is disabled (RFIE). When global a receive IRQ interrupt occurs, we mask the interrupt in the IRQ handler. Clearing and unmasking of the interrupt is happening in rx_poll(). There is a race condition where rx_poll() unmasks the interrupt, but the next IRQ handler does not mask the IRQ due to NAPIF_STATE_MISSED flag (e.g.: can0 RX FIFO interrupt is disabled and can1 is triggering RX interrupt, the delay in rx_poll() processing results in setting NAPIF_STATE_MISSED flag) leading to an IRQ storm. This patch fixes the issue by checking IRQ active and enabled before handling the IRQ on a particular channel. Fixes: dd3bd23eb438 ("can: rcar_canfd: Add Renesas R-Car CAN FD driver") Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/all/20221025155657.1426948-2-biju.das.jz@bp.renesas.com Cc: stable@vger.kernel.org [mkl: adjust commit message] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-10-27can: kvaser_usb: Fix possible completions during init_completionAnssi Hannula2-4/+4
kvaser_usb uses completions to signal when a response event is received for outgoing commands. However, it uses init_completion() to reinitialize the start_comp and stop_comp completions before sending the start/stop commands. In case the device sends the corresponding response just before the actual command is sent, complete() may be called concurrently with init_completion() which is not safe. This might be triggerable even with a properly functioning device by stopping the interface (CMD_STOP_CHIP) just after it goes bus-off (which also causes the driver to send CMD_STOP_CHIP when restart-ms is off), but that was not tested. Fix the issue by using reinit_completion() instead. Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices") Tested-by: Jimmy Assarsson <extja@kvaser.com> Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://lore.kernel.org/all/20221010185237.319219-2-extja@kvaser.com Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-10-26selftests: tc-testing: Add matchJSON to tdcVictor Nogueira1-7/+118
This allows the use of a matchJSON field in tests to match against JSON output from the command under test, if that command outputs JSON. You specify what you want to match against as a JSON array or object in the test's matchJSON field. You can leave out any fields you don't want to match against that are present in the output and they will be skipped. An example matchJSON value would look like this: "matchJSON": [ { "Value": { "neighIP": { "family": 4, "addr": "AQIDBA==", "width": 32 }, "nsflags": 142, "ncflags": 0, "LLADDR": "ESIzRFVm" } } ] The real output from the command under test might have some extra fields that we don't care about for matching, and since we didn't include them in our matchJSON value, those fields will not be attempted to be matched. If everything we included above has the same values as the real command output, the test will pass. The matchJSON field's type must be the same as the command output's type, otherwise the test will fail. So if the command outputs an array, then the value of matchJSON must also be an array. If matchJSON is an array, it must not contain more elements than the command output's array, otherwise the test will fail. Signed-off-by: Jeremy Carter <jeremy@mojatatu.com> Signed-off-by: Victor Nogueira <victor@mojatatu.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Link: https://lore.kernel.org/r/20221024111603.2185410-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-26net: ethernet: ave: Fix MAC to be in charge of PHY PMKunihiko Hayashi1-0/+6
The phylib callback is called after MAC driver's own resume callback is called. For AVE driver, after resuming immediately, PHY state machine is in PHY_NOLINK because there is a time lag from link-down to link-up due to autoneg. The result is WARN_ON() dump in mdio_bus_phy_resume(). Since ave_resume() itself calls phy_resume(), AVE driver should manage PHY PM. To indicate that MAC driver manages PHY PM, set phydev->mac_managed_pm to true to avoid the unnecessary phylib call and add missing phy_init_hw() to ave_resume(). Suggested-by: Heiner Kallweit <hkallweit1@gmail.com> Fixes: fba863b81604 ("net: phy: make PHY PM ops a no-op if MAC driver manages PHY PM") Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/20221024072227.24769-1-hayashi.kunihiko@socionext.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-26net: ethernet: ave: Remove duplicate phy_resume() callsKunihiko Hayashi1-6/+0
ave_open() in ave_resume() executes __phy_resume() via phy_start(), so no need to call phy_resume() explicitly. Remove it. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/20221024072314.24969-1-hayashi.kunihiko@socionext.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-26net: fec: limit register access on i.MX6ULJuergen Borleis1-2/+44
Using 'ethtool -d […]' on an i.MX6UL leads to a kernel crash: Unhandled fault: external abort on non-linefetch (0x1008) at […] due to this SoC has less registers in its FEC implementation compared to other i.MX6 variants. Thus, a run-time decision is required to avoid access to non-existing registers. Fixes: a51d3ab50702 ("net: fec: use a more proper compatible string for i.MX6UL type device") Signed-off-by: Juergen Borleis <jbe@pengutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20221024080552.21004-1-jbe@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-26Merge tag 'linux-can-fixes-for-6.1-20221025' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-canJakub Kicinski2-4/+9
Marc Kleine-Budde says: ==================== pull-request: can 2022-10-25 The 1st patch adds a missing cleanup call in the error path of the probe function in mpc5xxx glue code for the mscan driver. The 2nd patch adds a missing cleanup call in the error path of the probe function of the mcp251x driver. * tag 'linux-can-fixes-for-6.1-20221025' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: can: mcp251x: mcp251x_can_probe(): add missing unregister_candev() in error path can: mscan: mpc5xxx: mpc5xxx_can_probe(): add missing put_clock() in error path ==================== Link: https://lore.kernel.org/r/20221026075520.1502520-1-mkl@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-26net/rds: remove variable total_copiedColin Ian King1-2/+0
Variable total_copied is just being incremented and it's never used anywhere else. The variable and the increment are redundant so remove it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20221024135046.2159523-1-colin.i.king@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-26phylink: require valid state argument to phylink_validate_mask_caps()Jakub Kicinski1-3/+2
state is deferenced earlier in the function, the NULL check is pointless. Since we don't have any crash reports presumably it's safe to assume state is not NULL. Fixes: f392a1846489 ("net: phylink: provide phylink_validate_mask_caps() helper") Reviewed-by: Sean Anderson <sean.anderson@seco.com> Link: https://lore.kernel.org/r/20221025185126.1720553-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-26mptcp: fix tracking issue in mptcp_subflow_create_socket()Eric Dumazet1-0/+2
My recent patch missed that mptcp_subflow_create_socket() was creating a 'kernel' socket, then converted it to 'user' socket. Fixes: 0cafd77dcd03 ("net: add a refcount tracker for kernel sockets") Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Matthieu Baerts <matthieu.baerts@tessares.net> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Link: https://lore.kernel.org/r/20221025180546.652251-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.