- Jan 20, 2021
-
-
Alexander Lobakin authored
container_of() macro hides a local variable '__mptr' inside. This becomes a problem when several container_of() are nested in each other within single line or plain macros. As C preprocessor doesn't support generating random variable names, the sole solution is to avoid defining macros that consist only of container_of() calls, or they will self-shadow '__mptr' each time: In file included from ./include/linux/bitmap.h:10, from drivers/net/phy/phy_device.c:12: drivers/net/phy/phy_device.c: In function ‘phy_device_release’: ./include/linux/kernel.h:693:8: warning: declaration of ‘__mptr’ shadows a previous local [-Wshadow] 693 | void *__mptr = (void *)(ptr); \ | ^~~~~~ ./include/linux/phy.h:647:26: note: in expansion of macro ‘container_of’ 647 | #define to_phy_device(d) container_of(to_mdio_device(d), \ | ^~~~~~~~~~~~ ./include/linux/mdio.h:52:27: note: in expansion of macro ‘container_of’ 52 | #define to_mdio_device(d) container_of(d, struct mdio_device, dev) | ^~~~~~~~~~~~ ./include/linux/phy.h:647:39: note: in expansion of macro ‘to_mdio_device’ 647 | #define to_phy_device(d) container_of(to_mdio_device(d), \ | ^~~~~~~~~~~~~~ drivers/net/phy/phy_device.c:217:8: note: in expansion of macro ‘to_phy_device’ 217 | kfree(to_phy_device(dev)); | ^~~~~~~~~~~~~ ./include/linux/kernel.h:693:8: note: shadowed declaration is here 693 | void *__mptr = (void *)(ptr); \ | ^~~~~~ ./include/linux/phy.h:647:26: note: in expansion of macro ‘container_of’ 647 | #define to_phy_device(d) container_of(to_mdio_device(d), \ | ^~~~~~~~~~~~ drivers/net/phy/phy_device.c:217:8: note: in expansion of macro ‘to_phy_device’ 217 | kfree(to_phy_device(dev)); | ^~~~~~~~~~~~~ As they are declared in header files, these warnings are highly repetitive and very annoying (along with the one from linux/pci.h). Convert the related macros from linux/{mdio,phy}.h to static inlines to avoid self-shadowing and potentially improve bug-catching. No functional changes implied. Signed-off-by:
Alexander Lobakin <alobakin@pm.me> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20210116161246.67075-1-alobakin@pm.me Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Yunjian Wang authored
Currently the driver doesn't drop a packet which can't be sent by tun (e.g bad packet). In this case, the driver will always process the same packet lead to the tx queue stuck. To fix this issue: 1. in the case of persistent failure (e.g bad packet), the driver can skip this descriptor by ignoring the error. 2. in the case of transient failure (e.g -ENOBUFS, -EAGAIN and -ENOMEM), the driver schedules the worker to try again. Signed-off-by:
Yunjian Wang <wangyunjian@huawei.com> Acked-by:
Jason Wang <jasowang@redhat.com> Acked-by:
Willem de Bruijn <willemb@google.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Link: https://lore.kernel.org/r/1610685980-38608-1-git-send-email-wangyunjian@huawei.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
- Jan 19, 2021
-
-
Tom Rix authored
When DEBUG is defined this error occurs drivers/net/ethernet/hisilicon/hns/hns_enet.c:1505:36: error: ‘struct net_device’ has no member named ‘ae_handle’; did you mean ‘rx_handler’? assert(skb->queue_mapping < ndev->ae_handle->q_num); ^~~~~~~~~ ae_handle is an element of struct hns_nic_priv, so change ndev to priv. Signed-off-by:
Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20210117191044.533725-1-trix@redhat.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Tom Rix authored
When DEBUG is defined this error occurs drivers/net/arcnet/com20020_cs.c:70:15: error: ‘com20020_REG_W_ADDR_HI’ undeclared (first use in this function); did you mean ‘COM20020_REG_W_ADDR_HI’? ioaddr, com20020_REG_W_ADDR_HI); ^~~~~~~~~~~~~~~~~~~~~~ From reviewing the context, the suggestion is what is meant. Signed-off-by:
Tom Rix <trix@redhat.com> Acked-by:
Joe Perches <joe@perches.com> Link: https://lore.kernel.org/r/20210117181519.527625-1-trix@redhat.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Tariq Toukan says: ==================== TLS device offload for Bond This series opens TX and RX TLS device offload for bond interfaces. This allows bond interfaces to benefit from capable lower devices. We add a new ndo_sk_get_lower_dev() to be used to get the lower dev that corresponds to a given socket. The TLS module uses it to interact directly with the lowest device in chain, and invoke the control operations in tlsdev_ops. This means that the bond interface doesn't have his own struct tlsdev_ops instance and derived logic/callbacks. To keep simple track of the HW and SW TLS contexts, we bind each socket to a specific lower device for the socket's whole lifetime. This is logically valid (and similar to the SW kTLS behavior) in the following bond configuration, so we restrict the offload support to it: ((mode == balance-xor) or (mode == 802.3ad)) and xmit_hash_policy == layer3+4. In this design, TLS TX/RX offload feature flags of the bond device are independent from the lower devices. They reflect the current features state, but are not directly controllable. This is because the bond driver is bypassed by the call to ndo_sk_get_lower_dev(), without him knowing who the caller is. The bond TLS feature flags are set/cleared only according to the configuration of the mode and xmit_hash_policy. Bypass is true only for the control flow. Packets in fast path still go through the bond logic. The design here differs from the xfrm/ipsec offload, where the bond driver has his own copy of struct xfrmdev_ops and callbacks. ==================== Link: https://lore.kernel.org/r/20210117145949.8632-1-tariqt@nvidia.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Tariq Toukan authored
In the tls_dev_event handler, ignore tlsdev_ops requirement for bond interfaces, they do not exist as the interaction is done directly with the lower device. Also, make the validate function pass when it's called with the upper bond interface. Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Reviewed-by:
Boris Pismenny <borisp@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Tariq Toukan authored
Do not call the tls_dev_ops of upper devices. Instead, ask them for the proper lowest device and communicate with it directly. Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Reviewed-by:
Boris Pismenny <borisp@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Tariq Toukan authored
Following the description in previous patch (for TX): As the bond interface is being bypassed by the TLS module, interacting directly against the lower devs, there is no way for the bond interface to disable its device offload capabilities, as long as the mode/policy config allows it. Hence, the feature flag is not directly controllable, but just reflects the offload status based on the logic under bond_sk_check(). Here we just declare RX device offload support, and expose it via the NETIF_F_HW_TLS_RX flag. Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Reviewed-by:
Boris Pismenny <borisp@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Tariq Toukan authored
Implement TLS TX device offload for bonding interfaces. This allows kTLS sockets running on a bond to benefit from the device offload on capable lower devices. To allow a simple and fast maintenance of the TLS context in SW and lower devices, we bind the TLS socket to a specific lower dev. To achieve a behavior similar to SW kTLS, we support only balance-xor and 802.3ad modes, with xmit_hash_policy=layer3+4. This is enforced in bond_sk_check(), done in a previous patch. For the above configuration, the SW implementation keeps picking the same exact lower dev for all the socket's SKBs. The device offload behaves similarly, making the decision once at the connection creation. Per socket, the TLS module should work directly with the lowest netdev in chain, to call the tls_dev_ops operations. As the bond interface is being bypassed by the TLS module, interacting directly against the lower devs, there is no way for the bond interface to disable its device offload capabilities, as long as the mode/policy config allows it. Hence, the feature flag is not directly controllable, but just reflects the current offload status based on the logic under bond_sk_check(). Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Reviewed-by:
Boris Pismenny <borisp@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Tariq Toukan authored
In preparation for more cases that call netdev_update_features(). While here, move the features logic to the stage where struct bond is already updated, and pass it as the only parameter to function bond_set_xfrm_features(). Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Reviewed-by:
Boris Pismenny <borisp@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Tariq Toukan authored
Add ndo_sk_get_lower_dev() implementation for bond interfaces. Support only for the cases where the socket's and SKBs' hash yields identical value for the whole connection lifetime. Here we restrict it to L3+4 sockets only, with xmit_hash_policy==LAYER34 and bond modes xor/802.3ad. Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Reviewed-by:
Boris Pismenny <borisp@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Tariq Toukan authored
Hash logic on L3 will be used in a downstream patch for one more use case. Take it to a function for a better code reuse. Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Reviewed-by:
Boris Pismenny <borisp@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Tariq Toukan authored
ndo_sk_get_lower_dev returns the lower netdev that corresponds to a given socket. Additionally, we implement a helper netdev_sk_get_lowest_dev() to get the lowest one in chain. Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Reviewed-by:
Boris Pismenny <borisp@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'ql_alloc_net_req_rsp_queues()' GFP_KERNEL can be used because it is only called from 'ql_alloc_mem_resources()' which already calls 'ql_alloc_buffer_queues()' which uses GFP_KERNEL. (see below) When memory is allocated in 'ql_alloc_buffer_queues()' GFP_KERNEL can be used because this flag is already used just a few line above. When memory is allocated in 'ql_alloc_small_buffers()' GFP_KERNEL can be used because it is only called from 'ql_alloc_mem_resources()' which already calls 'ql_alloc_buffer_queues()' which uses GFP_KERNEL. (see above) When memory is allocated in 'ql_alloc_mem_resources()' GFP_KERNEL can be used because this function already calls 'ql_alloc_buffer_queues()' which uses GFP_KERNEL. (see above) While at it, use 'dma_set_mask_and_coherent()' instead of 'dma_set_mask()/ dma_set_coherent_mask()' in order to slightly simplify code. @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/20210117081542.560021-1-christophe.jaillet@wanadoo.fr Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Cong Wang authored
tcf_action_init_1() loads tc action modules automatically with request_module() after parsing the tc action names, and it drops RTNL lock and re-holds it before and after request_module(). This causes a lot of troubles, as discovered by syzbot, because we can be in the middle of batch initializations when we create an array of tc actions. One of the problem is deadlock: CPU 0 CPU 1 rtnl_lock(); for (...) { tcf_action_init_1(); -> rtnl_unlock(); -> request_module(); rtnl_lock(); for (...) { tcf_action_init_1(); -> tcf_idr_check_alloc(); // Insert one action into idr, // but it is not committed until // tcf_idr_insert_many(), then drop // the RTNL lock in the _next_ // iteration -> rtnl_unlock(); -> rtnl_lock(); -> a_o->init(); -> tcf_idr_check_alloc(); // Now waiting for the same index // to be committed -> request_module(); -> rtnl_lock() // Now waiting for RTNL lock } rtnl_unlock(); } rtnl_unlock(); This is not easy to solve, we can move the request_module() before this loop and pre-load all the modules we need for this netlink message and then do the rest initializations. So the loop breaks down to two now: for (i = 1; i <= TCA_ACT_MAX_PRIO && tb[i]; i++) { struct tc_action_ops *a_o; a_o = tc_action_load_ops(name, tb[i]...); ops[i - 1] = a_o; } for (i = 1; i <= TCA_ACT_MAX_PRIO && tb[i]; i++) { act = tcf_action_init_1(ops[i - 1]...); } Although this looks serious, it only has been reported by syzbot, so it seems hard to trigger this by humans. And given the size of this patch, I'd suggest to make it to net-next and not to backport to stable. This patch has been tested by syzbot and tested with tdc.py by me. Fixes: 0fedc63f ("net_sched: commit action insertions together") Reported-and-tested-by:
<syzbot+82752bc5331601cf4899@syzkaller.appspotmail.com> Reported-and-tested-by:
<syzbot+b3b63b6bff456bd95294@syzkaller.appspotmail.com> Reported-by:
<syzbot+ba67b12b1ca729912834@syzkaller.appspotmail.com> Cc: Jiri Pirko <jiri@resnulli.us> Signed-off-by:
Cong Wang <cong.wang@bytedance.com> Tested-by:
Jamal Hadi Salim <jhs@mojatatu.com> Acked-by:
Jamal Hadi Salim <jhs@mojatatu.com> Link: https://lore.kernel.org/r/20210117005657.14810-1-xiyou.wangcong@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Tom Rix authored
Defining DEBUG should only be done in development. So remove DEBUG. Signed-off-by:
Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20210115235346.289611-1-trix@redhat.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Xin Long says: ==================== net: make udp tunnel devices support fraglist Like GRE device, UDP tunnel devices should also support fraglist, so that some protocol (like SCTP) HW GSO that requires NETIF_F_FRAGLIST in the dev can work. Especially when the lower device support both NETIF_F_GSO_UDP_TUNNEL and NETIF_F_GSO_SCTP. ==================== Link: https://lore.kernel.org/r/cover.1610704037.git.lucien.xin@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Xin Long authored
Like vxlan and geneve, bareudp also needs this dev feature to support some protocol's HW GSO. Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Xin Long authored
Some protocol HW GSO requires fraglist supported by the device, like SCTP. Without NETIF_F_FRAGLIST set in the dev features of geneve, it would have to do SW GSO before the packets enter the driver, even when the geneve dev and lower dev (like veth) both have the feature of NETIF_F_GSO_SCTP. So this patch is to add it for geneve. Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Xin Long authored
Some protocol HW GSO requires fraglist supported by the device, like SCTP. Without NETIF_F_FRAGLIST set in the dev features of vxlan, it would have to do SW GSO before the packets enter the driver, even when the vxlan dev and lower dev (like veth) both have the feature of NETIF_F_GSO_SCTP. So this patch is to add it for vxlan. Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Andrea Parri (Microsoft) authored
For additional robustness in the face of Hyper-V errors or malicious behavior, validate all values that originate from packets that Hyper-V has sent to the guest. Ensure that invalid values cannot cause indexing off the end of an array, or subvert an existing validation via integer overflow. Ensure that outgoing packets do not have any leftover guest memory that has not been zeroed out. Reported-by:
Juan Vazquez <juvazq@microsoft.com> Signed-off-by:
Andrea Parri (Microsoft) <parri.andrea@gmail.com> Link: https://lore.kernel.org/r/20210114202628.119541-1-parri.andrea@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Menglong Dong authored
Replace some checks for ETH_P_8021Q and ETH_P_8021AD with eth_type_vlan(). Signed-off-by:
Menglong Dong <dong.menglong@zte.com.cn> Acked-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Link: https://lore.kernel.org/r/20210117080950.122761-1-dong.menglong@zte.com.cn Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Alex Elder says: ==================== net: ipa: interconnect improvements The main outcome of this series is to allow the number of interconnects used by the IPA to differ from the three that are implemented now. With this series in place, any number of interconnects can now be used, all specified in the configuration data for a specific platform. A few minor interconnect-related cleanups are implemented as well. ==================== Link: https://lore.kernel.org/r/20210115125050.20555-1-elder@linaro.org Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Alex Elder authored
Currently we assume that the IPA hardware has exactly three interconnects. But that won't be guaranteed for all platforms, so allow any number of interconnects to be specified in the configuration data. For each platform, define an array of interconnect data entries (still associated with the IPA clock structure), and record the number of entries initialized in that array. Loop over all entries in this array when initializing, enabling, disabling, or tearing down the set of interconnects. With this change we no longer need the ipa_interconnect_id enumerated type, so get rid of it. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Alex Elder authored
Pass an the address of an IPA interconnect structure and its configuration data to ipa_interconnect_init_one() and have that function initialize all the structure's fields. Change the function to simply return an error code. Introduce ipa_interconnect_exit_one() to encapsulate the cleanup of an IPA interconnect structure. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Alex Elder authored
Add the name to the configuration data for each interconnect. Use this information rather than a constant string during initialization. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Alex Elder authored
Add fields in the ipa_interconnect structure to hold the average and peak bandwidth values for the interconnect. Pass the configuring data for interconnects to ipa_interconnect_init() so these values can be recorded, and use them when enabling the interconnects. There's no longer any need to keep a copy of the interconnect data after initialization. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Alex Elder authored
Rather than having separate pointers for the memory, imem, and config interconnect paths, maintain an array of ipa_interconnect structures each of which contains a pointer to a path. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Alex Elder authored
If disabling interconnects fails there's not a lot we can do. The only two callers of ipa_interconnect_disable() ignore the return value, so just give the function a void return type. Print an error message if disabling any of the interconnects is not successful. Return (and print) only the first error seen. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Alex Elder authored
Use "bandwidth" rather than "rate" in describing the average and peak values to use for IPA interconnects. They should have been named that way to begin with. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
- Jan 17, 2021
-
-
Jakub Kicinski authored
Xin Long says: ==================== net: fix the features flag in sctp_gso_segment Patch 1/2 is to improve the code in skb_segment(), and it is needed by Patch 2/2. ==================== Link: https://lore.kernel.org/r/cover.1610703289.git.lucien.xin@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Xin Long authored
It makes more sense to clear NETIF_F_SG instead of set it when calling skb_segment() in sctp_gso_segment(), since SCTP GSO is using head_skb's fraglist, of which all frags are linear skbs. This will make SCTP GSO code more understandable. Suggested-by:
Alexander Duyck <alexander.duyck@gmail.com> Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Xin Long authored
After commit 89319d38 ("net: Add frag_list support to skb_segment"), it goes to process frag_list when !hsize in skb_segment(). However, when using skb frag_list, sg normally should not be set. In this case, hsize will be set with len right before !hsize check, then it won't go to frag_list processing code. So the right thing to do is move the hsize check to the else block, so that it won't affect the !hsize check for frag_list processing. v1->v2: - change to do "hsize <= 0" check instead of "!hsize", and also move "hsize < 0" into else block, to save some cycles, as Alex suggested. Signed-off-by:
Xin Long <lucien.xin@gmail.com> Reviewed-by:
Alexander Duyck <alexanderduyck@fb.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
vulab authored
fix semicolon.cocci warnings: drivers/net/ethernet/mscc/ocelot_net.c:460:2-3: Unneeded semicolon Signed-off-by:
Xu Wang <vulab@iscas.ac.cn> Link: https://lore.kernel.org/r/20210115095544.33164-1-vulab@iscas.ac.cn Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Raju Rangoju authored
Enable interrupt based Tx completions to improve latency for T5. The consumer index (CIDX) will now come via interrupts so that Tx SKBs can be freed up sooner in Rx path. Also, enforce CIDX flush threshold override (CIDXFTHRESHO) to improve latency for slow traffic. This ensures that the interrupt is generated immediately whenever hardware catches up with driver (i.e. CIDX == PIDX is reached), which is often the case for slow traffic. Signed-off-by:
Raju Rangoju <rajur@chelsio.com> Link: https://lore.kernel.org/r/20210115102059.6846-1-rajur@chelsio.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Lee Jones says: ==================== Rid W=1 warnings in Ethernet This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. v2: - Squashed IBM patches - Fixed real issue in SMSC - Added Andrew's Reviewed-by tags on remainder ==================== Link: https://lore.kernel.org/r/20210115200905.3470941-1-lee.jones@linaro.org Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/net/ethernet/toshiba/spider_net.c:263: warning: Function parameter or member 'hwdescr' not described in 'spider_net_get_descr_status' drivers/net/ethernet/toshiba/spider_net.c:263: warning: Excess function parameter 'descr' description in 'spider_net_get_descr_status' drivers/net/ethernet/toshiba/spider_net.c:554: warning: Function parameter or member 'netdev' not described in 'spider_net_get_multicast_hash' drivers/net/ethernet/toshiba/spider_net.c:902: warning: Function parameter or member 't' not described in 'spider_net_cleanup_tx_ring' drivers/net/ethernet/toshiba/spider_net.c:902: warning: Excess function parameter 'card' description in 'spider_net_cleanup_tx_ring' drivers/net/ethernet/toshiba/spider_net.c:1074: warning: Function parameter or member 'card' not described in 'spider_net_resync_head_ptr' drivers/net/ethernet/toshiba/spider_net.c:1234: warning: Function parameter or member 'napi' not described in 'spider_net_poll' drivers/net/ethernet/toshiba/spider_net.c:1234: warning: Excess function parameter 'netdev' description in 'spider_net_poll' drivers/net/ethernet/toshiba/spider_net.c:1278: warning: Function parameter or member 'p' not described in 'spider_net_set_mac' drivers/net/ethernet/toshiba/spider_net.c:1278: warning: Excess function parameter 'ptr' description in 'spider_net_set_mac' drivers/net/ethernet/toshiba/spider_net.c:1350: warning: Function parameter or member 'error_reg1' not described in 'spider_net_handle_error_irq' drivers/net/ethernet/toshiba/spider_net.c:1350: warning: Function parameter or member 'error_reg2' not described in 'spider_net_handle_error_irq' drivers/net/ethernet/toshiba/spider_net.c:1968: warning: Function parameter or member 't' not described in 'spider_net_link_phy' drivers/net/ethernet/toshiba/spider_net.c:1968: warning: Excess function parameter 'data' description in 'spider_net_link_phy' drivers/net/ethernet/toshiba/spider_net.c:2149: warning: Function parameter or member 'work' not described in 'spider_net_tx_timeout_task' drivers/net/ethernet/toshiba/spider_net.c:2149: warning: Excess function parameter 'data' description in 'spider_net_tx_timeout_task' drivers/net/ethernet/toshiba/spider_net.c:2182: warning: Function parameter or member 'txqueue' not described in 'spider_net_tx_timeout' Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/net/ethernet/toshiba/ps3_gelic_net.c:1107: warning: Function parameter or member 'irq' not described in 'gelic_card_interrupt' drivers/net/ethernet/toshiba/ps3_gelic_net.c:1107: warning: Function parameter or member 'ptr' not described in 'gelic_card_interrupt' drivers/net/ethernet/toshiba/ps3_gelic_net.c:1407: warning: Function parameter or member 'txqueue' not described in 'gelic_net_tx_timeout' drivers/net/ethernet/toshiba/ps3_gelic_net.c:1439: warning: Function parameter or member 'napi' not described in 'gelic_ether_setup_netdev_ops' drivers/net/ethernet/toshiba/ps3_gelic_net.c:1639: warning: Function parameter or member 'dev' not described in 'ps3_gelic_driver_probe' drivers/net/ethernet/toshiba/ps3_gelic_net.c:1795: warning: Function parameter or member 'dev' not described in 'ps3_gelic_driver_remove' Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): from drivers/net/ethernet/ibm/ibmvnic.c:35: inlined from ‘handle_vpd_rsp’ at drivers/net/ethernet/ibm/ibmvnic.c:4124:3: drivers/net/ethernet/ibm/ibmvnic.c:1362: warning: Function parameter or member 'hdr_field' not described in 'build_hdr_data' drivers/net/ethernet/ibm/ibmvnic.c:1362: warning: Function parameter or member 'skb' not described in 'build_hdr_data' drivers/net/ethernet/ibm/ibmvnic.c:1362: warning: Function parameter or member 'hdr_len' not described in 'build_hdr_data' drivers/net/ethernet/ibm/ibmvnic.c:1362: warning: Function parameter or member 'hdr_data' not described in 'build_hdr_data' drivers/net/ethernet/ibm/ibmvnic.c:1423: warning: Function parameter or member 'hdr_field' not described in 'create_hdr_descs' drivers/net/ethernet/ibm/ibmvnic.c:1423: warning: Function parameter or member 'hdr_data' not described in 'create_hdr_descs' drivers/net/ethernet/ibm/ibmvnic.c:1423: warning: Function parameter or member 'len' not described in 'create_hdr_descs' drivers/net/ethernet/ibm/ibmvnic.c:1423: warning: Function parameter or member 'hdr_len' not described in 'create_hdr_descs' drivers/net/ethernet/ibm/ibmvnic.c:1423: warning: Function parameter or member 'scrq_arr' not described in 'create_hdr_descs' drivers/net/ethernet/ibm/ibmvnic.c:1474: warning: Function parameter or member 'txbuff' not described in 'build_hdr_descs_arr' drivers/net/ethernet/ibm/ibmvnic.c:1474: warning: Function parameter or member 'num_entries' not described in 'build_hdr_descs_arr' drivers/net/ethernet/ibm/ibmvnic.c:1474: warning: Function parameter or member 'hdr_field' not described in 'build_hdr_descs_arr' drivers/net/ethernet/ibm/ibmvnic.c:1832: warning: Function parameter or member 'adapter' not described in 'do_change_param_reset' drivers/net/ethernet/ibm/ibmvnic.c:1832: warning: Function parameter or member 'rwi' not described in 'do_change_param_reset' drivers/net/ethernet/ibm/ibmvnic.c:1832: warning: Function parameter or member 'reset_state' not described in 'do_change_param_reset' drivers/net/ethernet/ibm/ibmvnic.c:1911: warning: Function parameter or member 'adapter' not described in 'do_reset' drivers/net/ethernet/ibm/ibmvnic.c:1911: warning: Function parameter or member 'rwi' not described in 'do_reset' drivers/net/ethernet/ibm/ibmvnic.c:1911: warning: Function parameter or member 'reset_state' not described in 'do_reset' Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/net/ethernet/ti/am65-cpts.c:736: warning: Function parameter or member 'en' not described in 'am65_cpts_rx_enable' drivers/net/ethernet/ti/am65-cpts.c:736: warning: Excess function parameter 'skb' description in 'am65_cpts_rx_enable' Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-