aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/tracehook.h (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2021-11-16net: remove sk_route_nocapsEric Dumazet5-11/+11
Instead of using a full netdev_features_t, we can use a single bit, as sk_route_nocaps is only used to remove NETIF_F_GSO_MASK from sk->sk_route_cap. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-16net: remove sk_route_forced_capsEric Dumazet3-5/+3
We were only using one bit, and we can replace it by sk_is_tcp() Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-16net: use sk_is_tcp() in more placesEric Dumazet4-14/+9
Move sk_is_tcp() to include/net/sock.h and use it where we can. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-16tcp: small optimization in tcp_v6_send_check()Eric Dumazet1-3/+1
For TCP flows, inet6_sk(sk)->saddr has the same value than sk->sk_v6_rcv_saddr. Using sk->sk_v6_rcv_saddr increases data locality. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-16tcp: remove dead code in __tcp_v6_send_check()Eric Dumazet1-9/+3
For some reason, I forgot to change __tcp_v6_send_check() at the same time I removed (ip_summed == CHECKSUM_PARTIAL) check in __tcp_v4_send_check() Fixes: 98be9b12096f ("tcp: remove dead code after CHECKSUM_PARTIAL adoption") Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-16tcp: minor optimization in tcp_add_backlog()Eric Dumazet1-3/+2
If packet is going to be coalesced, sk_sndbuf/sk_rcvbuf values are not used. Defer their access to the point we need them. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: macb: Fix several edge cases in validateSean Anderson1-39/+73
There were several cases where validate() would return bogus supported modes with unusual combinations of interfaces and capabilities. For example, if state->interface was 10GBASER and the macb had HIGH_SPEED and PCS but not GIGABIT MODE, then 10/100 modes would be set anyway. In another case, SGMII could be enabled even if the mac was not a GEM (despite this being checked for later on in mac_config()). These inconsistencies make it difficult to refactor this function cleanly. There is still the open question of what exactly the requirements for SGMII and 10GBASER are, and what SGMII actually supports. If someone from Cadence (or anyone else with access to the GEM/MACB datasheet) could comment on this, it would be greatly appreciated. In particular, what is supported by Cadence vs. vendor extension/limitation? To address this, the current logic is split into three parts. First, we determine what we support, then we eliminate unsupported interfaces, and finally we set the appropriate link modes. There is still some cruft related to NA, but this can be removed in a future patch. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Parshuram Thombare <pthombar@cadence.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/20211112190400.1937855-1-sean.anderson@seco.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-15Revert "Merge branch 'mctp-i2c-driver'"Jakub Kicinski12-1209/+25
This reverts commit 71812af7234f30362b43ccff33f93890ae4c0655, reversing changes made to cc0be1ad686fb29a4d127948486f40b17fb34b50. Wolfram Sang says: Please revert. Besides the driver in net, it modifies the I2C core code. This has not been acked by the I2C maintainer (in this case me). So, please don't pull this in via the net tree. The question raised here (extending SMBus calls to 255 byte) is complicated because we need ABI backwards compatibility. Link: https://lore.kernel.org/all/YZJ9H4eM%2FM7OXVN0@shikoro/ Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-11-15net: mvpp2: use phylink_generic_validate()Russell King (Oracle)1-49/+9
Convert mvpp2 to use phylink_generic_validate() for the bulk of its validate() implementation. This network adapter has a restriction that for 802.3z links, autonegotiation must be enabled. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: mvneta: use phylink_generic_validate()Russell King (Oracle)1-30/+4
Convert mvneta to use phylink_generic_validate() for the bulk of its validate() implementation. This network adapter has a restriction that for 802.3z links, autonegotiation must be enabled. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: phylink: add generic validate implementationRussell King (Oracle)2-0/+283
Add a generic validate() implementation using the supported_interfaces and a bitmask of MAC pause/speed/duplex capabilities. This allows us to entirely eliminate many driver private validate() implementations. We expose the underlying phylink_get_linkmodes() function so that drivers which have special needs can still benefit from conversion. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net/wan/fsl_ucc_hdlc: fix sparse warningsChristophe Leroy1-30/+32
CHECK drivers/net/wan/fsl_ucc_hdlc.c drivers/net/wan/fsl_ucc_hdlc.c:309:57: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:309:57: expected void [noderef] __iomem * drivers/net/wan/fsl_ucc_hdlc.c:309:57: got restricted __be16 * drivers/net/wan/fsl_ucc_hdlc.c:311:46: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:311:46: expected void [noderef] __iomem * drivers/net/wan/fsl_ucc_hdlc.c:311:46: got restricted __be32 * drivers/net/wan/fsl_ucc_hdlc.c:320:57: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:320:57: expected void [noderef] __iomem * drivers/net/wan/fsl_ucc_hdlc.c:320:57: got restricted __be16 * drivers/net/wan/fsl_ucc_hdlc.c:322:46: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:322:46: expected void [noderef] __iomem * drivers/net/wan/fsl_ucc_hdlc.c:322:46: got restricted __be32 * drivers/net/wan/fsl_ucc_hdlc.c:372:29: warning: incorrect type in assignment (different base types) drivers/net/wan/fsl_ucc_hdlc.c:372:29: expected unsigned short [usertype] drivers/net/wan/fsl_ucc_hdlc.c:372:29: got restricted __be16 [usertype] drivers/net/wan/fsl_ucc_hdlc.c:379:36: warning: restricted __be16 degrades to integer drivers/net/wan/fsl_ucc_hdlc.c:402:12: warning: incorrect type in assignment (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:402:12: expected struct qe_bd [noderef] __iomem *bd drivers/net/wan/fsl_ucc_hdlc.c:402:12: got struct qe_bd *curtx_bd drivers/net/wan/fsl_ucc_hdlc.c:425:20: warning: incorrect type in assignment (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:425:20: expected struct qe_bd [noderef] __iomem *[assigned] bd drivers/net/wan/fsl_ucc_hdlc.c:425:20: got struct qe_bd *tx_bd_base drivers/net/wan/fsl_ucc_hdlc.c:427:16: error: incompatible types in comparison expression (different address spaces): drivers/net/wan/fsl_ucc_hdlc.c:427:16: struct qe_bd [noderef] __iomem * drivers/net/wan/fsl_ucc_hdlc.c:427:16: struct qe_bd * drivers/net/wan/fsl_ucc_hdlc.c:462:33: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:506:41: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:528:33: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:552:38: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:596:67: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:611:41: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:851:38: warning: incorrect type in initializer (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:854:40: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:855:40: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:858:39: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:861:37: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:866:38: warning: incorrect type in initializer (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:868:21: warning: incorrect type in argument 1 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:870:40: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:871:40: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:873:39: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:993:57: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:995:46: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:1004:57: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:1006:46: warning: incorrect type in argument 2 (different address spaces) drivers/net/wan/fsl_ucc_hdlc.c:412:35: warning: dereference of noderef expression drivers/net/wan/fsl_ucc_hdlc.c:412:35: warning: dereference of noderef expression drivers/net/wan/fsl_ucc_hdlc.c:724:29: warning: dereference of noderef expression drivers/net/wan/fsl_ucc_hdlc.c:815:21: warning: dereference of noderef expression drivers/net/wan/fsl_ucc_hdlc.c:1021:29: warning: dereference of noderef expression Most of the warnings are due to DMA memory being incorrectly handled as IO memory. Fix it by doing direct read/write and doing proper dma_rmb() / dma_wmb(). Other problems are type mismatches or lack of use of IO accessors. Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Reported-by: kernel test robot <lkp@intel.com> Link: https://lkml.org/lkml/2021/11/12/647 Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: fddi: use swap() to make code cleanerYihao Han1-10/+4
Use the macro 'swap()' defined in 'include/linux/minmax.h' to avoid opencoding it. Signed-off-by: Yihao Han <hanyihao@vivo.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15hinic: use ARRAY_SIZE instead of ARRAY_LENGuo Zhengkui1-17/+15
ARRAY_SIZE defined in <linux/kernel.h> is safer than self-defined macros to get size of an array such as ARRAY_LEN used here. Because ARRAY_SIZE uses __must_be_array(arr) to ensure arr is really an array. Reported-by: Alejandro Colomar <colomar.6.4.3@gmail.com> Signed-off-by: Guo Zhengkui <guozhengkui@vivo.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: usb: ax88179_178a: add TSO featureJacky Chou1-6/+11
On low-effciency embedded platforms, transmission performance is poor due to on Bulk-out with single packet. Adding TSO feature improves the transmission performance and reduces the number of interrupt caused by Bulk-out complete. Reference to module, net: usb: aqc111. Signed-off-by: Jacky Chou <jackychou@asix.com.tw> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15mctp i2c: MCTP I2C binding driverMatt Johnston3-0/+995
Provides MCTP network transport over an I2C bus, as specified in DMTF DSP0237. All messages between nodes are sent as SMBus Block Writes. Each I2C bus to be used for MCTP is flagged in devicetree by a 'mctp-controller' property on the bus node. Each flagged bus gets a mctpi2cX net device created based on the bus number. A 'mctp-i2c-controller' I2C client needs to be added under the adapter. In an I2C mux situation the mctp-i2c-controller node must be attached only to the root I2C bus. The I2C client will handle incoming I2C slave block write data for subordinate busses as well as its own bus. In configurations without devicetree a driver instance can be attached to a bus using the I2C slave new_device mechanism. The MCTP core will hold/release the MCTP I2C device while responses are pending (a 6 second timeout or once a socket is closed, response received etc). While held the MCTP I2C driver will lock the I2C bus so that the correct I2C mux remains selected while responses are received. (Ideally we would just lock the mux to keep the current bus selected for the response rather than a full I2C bus lock, but that isn't exposed in the I2C mux API) This driver requires I2C adapters that allow 255 byte transfers (SMBus 3.0) as the specification requires a minimum MTU of 68 bytes. Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15dt-bindings: net: New binding mctp-i2c-controllerMatt Johnston2-0/+96
Used to define a local endpoint to communicate with MCTP peripherals attached to an I2C bus. This I2C endpoint can communicate with remote MCTP devices on the I2C bus. In the example I2C topology below (matching the second yaml example) we have MCTP devices on busses i2c1 and i2c6. MCTP-supporting busses are indicated by the 'mctp-controller' DT property on an I2C bus node. A mctp-i2c-controller I2C client DT node is placed at the top of the mux topology, since only the root I2C adapter will support I2C slave functionality. .-------. |eeprom | .------------. .------. /'-------' | adapter | | mux --@0,i2c5------' | i2c1 ----.*| --@1,i2c6--.--. |............| \'------' \ \ ......... | mctp-i2c- | \ \ \ .mctpB . | controller | \ \ '.0x30 . | | \ ......... \ '.......' | 0x50 | \ .mctpA . \ ......... '------------' '.0x1d . '.mctpC . '.......' '.0x31 . '.......' (mctpX boxes above are remote MCTP devices not included in the DT at present, they can be hotplugged/probed at runtime. A DT binding for specific fixed MCTP devices could be added later if required) Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15i2c: npcm7xx: Allow 255 byte block SMBus transfersMatt Johnston1-1/+2
255 byte support has been tested on a npcm750 board Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Reviewed-by: Tali Perry <tali.perry1@gmail.com> Reviewed-by: Patrick Venture <venture@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15i2c: aspeed: Allow 255 byte block transfersMatt Johnston1-2/+3
255 byte transfers have been tested on an AST2500 board Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15i2c: dev: Handle 255 byte blocks for i2c ioctlMatt Johnston3-14/+83
I2C_SMBUS is limited to 32 bytes due to compatibility with the 32 byte i2c_smbus_data.block I2C_RDWR allows larger transfers if sufficient sized buffers are passed. Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15i2c: core: Allow 255 byte transfers for SMBus 3.xMatt Johnston3-8/+30
SMBus 3.0 increased the maximum block transfer size from 32 bytes to 255 bytes. We increase the size of struct i2c_smbus_data's block[] member. i2c_smbus_xfer() and i2c_smbus_xfer_emulated() now support 255 byte block operations, other block functions remain limited to 32 bytes for compatibility with existing callers. We allow adapters to indicate support for the larger size with I2C_FUNC_SMBUS_V3_BLOCK. Most emulated drivers should be able to use 255 byte blocks by replacing I2C_SMBUS_BLOCK_MAX with I2C_SMBUS_V3_BLOCK_MAX though some will have hardware limitations that need testing. Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: bridge: Slightly optimize 'find_portno()'Christophe JAILLET1-4/+4
The 'inuse' bitmap is local to this function. So we can use the non-atomic '__set_bit()' to save a few cycles. While at it, also remove some useless {}. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: sched: sch_netem: Refactor code in 4-state loss generatorHarshit Mogalapalli1-9/+9
Fixed comments to match description with variable names and refactored code to match the convention as per [1]. To match the convention mapping is done as follows: State 3 - LOST_IN_BURST_PERIOD State 4 - LOST_IN_GAP_PERIOD [1] S. Salsano, F. Ludovici, A. Ordine, "Definition of a general and intuitive loss model for packet networks and its implementation in the Netem module in the Linux kernel" Fixes: a6e2fe17eba4 ("sch_netem: replace magic numbers with enumerate") Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Acked-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: dsa: vsc73xxx: Make vsc73xx_remove() return voidUwe Kleine-König2-4/+2
vsc73xx_remove() returns zero unconditionally and no caller checks the returned value. So convert the function to return no value. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-15net: stmmac: enhance XDP ZC driver level switching performanceOng Boon Leong3-6/+139
The previous stmmac_xdp_set_prog() implementation uses stmmac_release() and stmmac_open() which tear down the PHY device and causes undesirable autonegotiation which causes a delay whenever AFXDP ZC is setup. This patch introduces two new functions that just sufficiently tear down DMA descriptors, buffer, NAPI process, and IRQs and reestablish them accordingly in both stmmac_xdp_release() and stammac_xdp_open(). As the results of this enhancement, we get rid of transient state introduced by the link auto-negotiation: $ ./xdpsock -i eth0 -t -z sock0@eth0:0 txonly xdp-drv pps pkts 1.00 rx 0 0 tx 634444 634560 sock0@eth0:0 txonly xdp-drv pps pkts 1.00 rx 0 0 tx 632330 1267072 sock0@eth0:0 txonly xdp-drv pps pkts 1.00 rx 0 0 tx 632438 1899584 sock0@eth0:0 txonly xdp-drv pps pkts 1.00 rx 0 0 tx 632502 2532160 Reported-by: Kurt Kanzenbach <kurt@linutronix.de> Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com> Tested-by: Kurt Kanzenbach <kurt@linutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-14bpftool: Use libbpf_get_error() to check errorHengqi Chen5-23/+27
Currently, LIBBPF_STRICT_ALL mode is enabled by default for bpftool which means on error cases, some libbpf APIs would return NULL pointers. This makes IS_ERR check failed to detect such cases and result in segfault error. Use libbpf_get_error() instead like we do in libbpf itself. Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211115012436.3143318-1-hengqi.chen@gmail.com
2021-11-14bpftool: Fix mixed indentation in documentationQuentin Monnet2-38/+38
Some paragraphs in bpftool's documentation have a mix of tabs and spaces for indentation. Let's make it consistent. This patch brings no change to the text content. Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211110114632.24537-7-quentin@isovalent.com
2021-11-14bpftool: Update the lists of names for maps and prog-attach typesQuentin Monnet4-3/+6
To support the different BPF map or attach types, bpftool must remain up-to-date with the types supported by the kernel. Let's update the lists, by adding the missing Bloom filter map type and the perf_event attach type. Both missing items were found with test_bpftool_synctypes.py. Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211110114632.24537-6-quentin@isovalent.com
2021-11-14bpftool: Fix indent in option lists in the documentationQuentin Monnet7-14/+14
Mixed indentation levels in the lists of options in bpftool's documentation produces some unexpected results. For the "bpftool" man page, it prints a warning: $ make -C bpftool.8 GEN bpftool.8 <stdin>:26: (ERROR/3) Unexpected indentation. For other pages, there is no warning, but it results in a line break appearing in the option lists in the generated man pages. RST paragraphs should have a uniform indentation level. Let's fix it. Fixes: c07ba629df97 ("tools: bpftool: Update and synchronise option list in doc and help msg") Fixes: 8cc8c6357c8f ("tools: bpftool: Document and add bash completion for -L, -B options") Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211110114632.24537-5-quentin@isovalent.com
2021-11-14bpftool: Remove inclusion of utilities.mak from MakefilesQuentin Monnet2-2/+0
Bpftool's Makefile, and the Makefile for its documentation, both include scripts/utilities.mak, but they use none of the items defined in this file. Remove the includes. Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool") Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211110114632.24537-3-quentin@isovalent.com
2021-11-14bpftool: Fix memory leak in prog_dump()Quentin Monnet1-6/+9
Following the extraction of prog_dump() from do_dump(), the struct btf allocated in prog_dump() is no longer freed on error; the struct bpf_prog_linfo is not freed at all. Make sure we release them before exiting the function. Fixes: ec2025095cf6 ("bpftool: Match several programs with same tag") Signed-off-by: Quentin Monnet <quentin@isovalent.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211110114632.24537-2-quentin@isovalent.com
2021-11-14ipv6: Remove duplicate statementsluo penghao1-1/+0
This statement is repeated with the initialization statement Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: luo penghao <luo.penghao@zte.com.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-14ipv4: Remove duplicate assignmentsluo penghao1-1/+0
there is a same action when the variable is initialized Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: luo penghao <luo.penghao@zte.com.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-14ipv4: drop unused assignmentluo penghao1-1/+0
The assignment in the if statement will be overwritten by the following statement Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: luo penghao <luo.penghao@zte.com.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-11-12selftests/bpf: Fix a tautological-constant-out-of-range-compare compiler warningYonghong Song1-6/+11
When using clang to build selftests with LLVM=1 in make commandline, I hit the following compiler warning: benchs/bench_bloom_filter_map.c:84:46: warning: result of comparison of constant 256 with expression of type '__u8' (aka 'unsigned char') is always false [-Wtautological-constant-out-of-range-compare] if (args.value_size < 2 || args.value_size > 256) { ~~~~~~~~~~~~~~~ ^ ~~~ The reason is arg.vaue_size has type __u8, so comparison "args.value_size > 256" is always false. This patch fixed the issue by doing proper comparison before assigning the value to args.value_size. The patch also fixed the same issue in two other places. Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211112204838.3579953-1-yhs@fb.com
2021-11-12selftests/bpf: Fix an unused-but-set-variable compiler warningYonghong Song1-2/+0
When using clang to build selftests with LLVM=1 in make commandline, I hit the following compiler warning: xdpxceiver.c:747:6: warning: variable 'total' set but not used [-Wunused-but-set-variable] u32 total = 0; ^ This patch fixed the issue by removing that declaration and its assocatied unused operation. Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211112204833.3579457-1-yhs@fb.com
2021-11-12tools/lib/lockdep: drop liblockdepSasha Levin39-1229/+3
TL;DR: While a tool like liblockdep is useful, it probably doesn't belong within the kernel tree. liblockdep attempts to reuse kernel code both directly (by directly building the kernel's lockdep code) as well as indirectly (by using sanitized headers). This makes liblockdep an integral part of the kernel. It also makes liblockdep quite unique: while other userspace code might use sanitized headers, it generally doesn't attempt to use kernel code directly which means that changes on the kernel side of things don't affect (and break) it directly. All our workflows and tooling around liblockdep don't support this uniqueness. Changes that go into the kernel code aren't validated to not break in-tree userspace code. liblockdep ended up being very fragile, breaking over and over, to the point that living in the same tree as the lockdep code lost most of it's value. liblockdep should continue living in an external tree, syncing with the kernel often, in a controllable way. Signed-off-by: Sasha Levin <sashal@kernel.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-11-12thermal: int340x: fix build on 32-bit targetsLinus Torvalds1-0/+1
Commit aeb58c860dc5 ("thermal/drivers/int340x: processor_thermal: Suppot 64 bit RFIM responses") started using 'readq()' to read 64-bit status responses from the int340x hardware. That's all fine and good, but on 32-bit targets a 64-bit 'readq()' is ambiguous, since it's no longer an atomic access. Some hardware might require 64-bit accesses, and other hardware might want low word first or high word first. It's quite likely that the driver isn't relevant in a 32-bit environment any more, and there's a patch floating around to just make it depend on X86_64, but let's make it buildable on x86-32 anyway. The driver previously just read the low 32 bits, so the hardware certainly is ok with 32-bit reads, and in a little-endian environment the low word first model is the natural one. So just add the include for the 'io-64-nonatomic-lo-hi.h' version. Fixes: aeb58c860dc5 ("thermal/drivers/int340x: processor_thermal: Suppot 64 bit RFIM responses") Reported-by: Jakub Kicinski <kuba@kernel.org> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-11-12bpf: Introduce btf_tracing_idsSong Liu7-17/+29
Similar to btf_sock_ids, btf_tracing_ids provides btf ID for task_struct, file, and vm_area_struct via easy to understand format like btf_tracing_ids[BTF_TRACING_TYPE_[TASK|file|VMA]]. Suggested-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Song Liu <songliubraving@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/20211112150243.1270987-3-songliubraving@fb.com
2021-11-12bpf: Extend BTF_ID_LIST_GLOBAL with parameter for number of IDsSong Liu3-9/+5
syzbot reported the following BUG w/o CONFIG_DEBUG_INFO_BTF BUG: KASAN: global-out-of-bounds in task_iter_init+0x212/0x2e7 kernel/bpf/task_iter.c:661 Read of size 4 at addr ffffffff90297404 by task swapper/0/1 CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.15.0-syzkaller #0 Hardware name: ... Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xf/0x309 mm/kasan/report.c:256 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 task_iter_init+0x212/0x2e7 kernel/bpf/task_iter.c:661 do_one_initcall+0x103/0x650 init/main.c:1295 do_initcall_level init/main.c:1368 [inline] do_initcalls init/main.c:1384 [inline] do_basic_setup init/main.c:1403 [inline] kernel_init_freeable+0x6b1/0x73a init/main.c:1606 kernel_init+0x1a/0x1d0 init/main.c:1497 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> This is caused by hard-coded name[1] in BTF_ID_LIST_GLOBAL (w/o CONFIG_DEBUG_INFO_BTF). Fix this by adding a parameter n to BTF_ID_LIST_GLOBAL. This avoids ifdef CONFIG_DEBUG_INFO_BTF in btf.c and filter.c. Fixes: 7c7e3d31e785 ("bpf: Introduce helper bpf_find_vma") Reported-by: syzbot+e0d81ec552a21d9071aa@syzkaller.appspotmail.com Reported-by: Eric Dumazet <edumazet@google.com> Suggested-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Song Liu <songliubraving@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/20211112150243.1270987-2-songliubraving@fb.com
2021-11-12bpftool: Enable libbpf's strict mode by defaultStanislav Fomichev5-19/+48
Otherwise, attaching with bpftool doesn't work with strict section names. Also: - Add --legacy option to switch back to pre-1.0 behavior - Print a warning when program fails to load in strict mode to point to --legacy flag - By default, don't append / to the section name; in strict mode it's relevant only for a small subset of prog types + bpftool --legacy prog loadall tools/testing/selftests/bpf/test_cgroup_link.o /sys/fs/bpf/kprobe type kprobe libbpf: failed to pin program: File exists Error: failed to pin all programs + bpftool prog loadall tools/testing/selftests/bpf/test_cgroup_link.o /sys/fs/bpf/kprobe type kprobe v1 -> v2: - strict by default (Quentin Monnet) - add more info to --legacy description (Quentin Monnet) - add bash completion (Quentin Monnet) Signed-off-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/bpf/20211110192324.920934-1-sdf@google.com
2021-11-11docs/bpf: Update documentation for BTF_KIND_TYPE_TAG supportYonghong Song1-1/+12
Add BTF_KIND_TYPE_TAG documentation in btf.rst. Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211112012656.1509082-1-yhs@fb.com
2021-11-11selftests/bpf: Clarify llvm dependency with btf_tag selftestYonghong Song1-4/+5
btf_tag selftest needs certain llvm versions (>= llvm14). Make it clear in the selftests README.rst file. Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211112012651.1508549-1-yhs@fb.com
2021-11-11selftests/bpf: Add a C test for btf_type_tagYonghong Song2-0/+49
The following is the main btf_type_tag usage in the C test: #define __tag1 __attribute__((btf_type_tag("tag1"))) #define __tag2 __attribute__((btf_type_tag("tag2"))) struct btf_type_tag_test { int __tag1 * __tag1 __tag2 *p; } g; The bpftool raw dump with related types: [4] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED [11] STRUCT 'btf_type_tag_test' size=8 vlen=1 'p' type_id=14 bits_offset=0 [12] TYPE_TAG 'tag1' type_id=16 [13] TYPE_TAG 'tag2' type_id=12 [14] PTR '(anon)' type_id=13 [15] TYPE_TAG 'tag1' type_id=4 [16] PTR '(anon)' type_id=15 [17] VAR 'g' type_id=11, linkage=global With format C dump, we have struct btf_type_tag_test { int __attribute__((btf_type_tag("tag1"))) * __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag2"))) *p; }; The result C code is identical to the original definition except macro's are gone. Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211112012646.1508231-1-yhs@fb.com
2021-11-11selftests/bpf: Rename progs/tag.c to progs/btf_decl_tag.cYonghong Song2-11/+13
Rename progs/tag.c to progs/btf_decl_tag.c so we can introduce progs/btf_type_tag.c in the next patch. Also create a subtest for btf_decl_tag in prog_tests/btf_tag.c so we can introduce btf_type_tag subtest in the next patch. I also took opportunity to remove the check whether __has_attribute is defined or not in progs/btf_decl_tag.c since all recent clangs should already support this macro. Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211112012641.1507144-1-yhs@fb.com
2021-11-11selftests/bpf: Test BTF_KIND_DECL_TAG for deduplicationYonghong Song1-4/+135
Add BTF_KIND_TYPE_TAG duplication unit tests. Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20211112012635.1506853-1-yhs@fb.com
2021-11-11selftests/bpf: Add BTF_KIND_TYPE_TAG unit testsYonghong Song2-0/+21
Add BTF_KIND_TYPE_TAG unit tests. Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211112012630.1506095-1-yhs@fb.com
2021-11-11selftests/bpf: Test libbpf API function btf__add_type_tag()Yonghong Song2-28/+43
Add unit tests for btf__add_type_tag(). Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211112012625.1505748-1-yhs@fb.com
2021-11-11bpftool: Support BTF_KIND_TYPE_TAGYonghong Song1-0/+2
Add bpftool support for BTF_KIND_TYPE_TAG. Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211112012620.1505506-1-yhs@fb.com
2021-11-11libbpf: Support BTF_KIND_TYPE_TAGYonghong Song6-2/+73
Add libbpf support for BTF_KIND_TYPE_TAG. Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211112012614.1505315-1-yhs@fb.com
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.