summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* rxrpc: Use rxrpc_txbuf::kvec[0] instead of rxrpc_txbuf::wireDavid Howells2024-03-043-55/+56
| | | | | | | | | | | | | | | | | | | Use rxrpc_txbuf::kvec[0] instead of rxrpc_txbuf::wire to gain access to the Rx protocol header. In future, the wire header will be stored in a page frag, not in the rxrpc_txbuf struct making it possible to use MSG_SPLICE_PAGES when sending it. Similarly, access the ack header as being immediately after the wire header when filling out an ACK packet. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> 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: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
* rxrpc: Move rxrpc_send_ACK() to output.c with rxrpc_send_ack_packet()David Howells2024-02-293-40/+40
| | | | | | | | | | | | | | Move rxrpc_send_ACK() to output.c to so that it is with rxrpc_send_ack_packet() prior to merging the two. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> 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: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
* rxrpc: Don't pick values out of the wire header when setting up securityDavid Howells2024-02-291-4/+4
| | | | | | | | | | | | | | | Don't pick values out of the wire header in rxkad when setting up DATA packet security, but rather use other sources. This makes it easier to get rid of txb->wire. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> 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: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
* rxrpc: Split up the DATA packet transmission functionDavid Howells2024-02-292-30/+69
| | | | | | | | | | | | | | | | | Split (sub)packet preparation and timestamping out of the DATA packet transmission function to make it easier to glue multiple txbufs together into a jumbo DATA packet. This will require preparation and timestamping of all the subpackets in a txbuf, and these functions provide convenient points to place the required iteration. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> 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: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
* rxrpc: Add a kvec[] to the rxrpc_txbuf structDavid Howells2024-02-294-24/+22
| | | | | | | | | | | | | | | | | | | | | Add a kvec[] to the rxrpc_txbuf struct to point to the contributory buffers for a packet. Start with just a single element for now, but this will be expanded later. Make the ACK sending function use it, which means that rxrpc_fill_out_ack() doesn't need to return the size of the sack table, padding and trailer. Make the data sending code use it, both in where sendmsg() packages code up into txbufs and where those txbufs are transmitted. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> 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: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
* rxrpc: Merge together DF/non-DF branches of data Tx functionDavid Howells2024-02-291-39/+15
| | | | | | | | | | | | | | | Merge together the DF and non-DF branches of the transmission function and always set the flag to the right thing before transmitting. If we see -EMSGSIZE from udp_sendmsg(), turn off DF and retry. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> 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: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
* rxrpc: Do lazy DF flag resettingDavid Howells2024-02-292-3/+2
| | | | | | | | | | | | | | | | | | Don't reset the DF flag after transmission, but rather set it when needed since it should be a fast op now that we call IP directly. This includes turning it off for RESPONSE packets and, for the moment, ACK packets. In future, we will need to turn it on for ACK packets used to do path MTU discovery. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> 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: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
* rxrpc: Remove atomic handling on some fields only used in I/O threadDavid Howells2024-02-292-11/+7
| | | | | | | | | | | | | | call->tx_transmitted and call->acks_prev_seq don't need to be managed with cmpxchg() and barriers as it's only used within the singular I/O thread. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> 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: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
* rxrpc: Strip barriers and atomics off of timer trackingDavid Howells2024-02-294-37/+32
| | | | | | | | | | | | | | | Strip the atomic ops and barriering off of the call timer tracking as this is handled solely within the I/O thread, except for expect_term_by which is set by sendmsg(). Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> 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: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
* rxrpc: Fix the names of the fields in the ACK trailer structDavid Howells2024-02-295-30/+30
| | | | | | | | | | | | | | | | | From AFS-3.3 a trailer containing extra info was added to the ACK packet format - but AF_RXRPC has the names of some of the fields mixed up compared to other AFS implementations. Rename the struct and the fields to make them match. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> 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: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
* rxrpc: Note cksum in txbufDavid Howells2024-02-294-1/+4
| | | | | | | | | | | | | | | Add a field to rxrpc_txbuf in which to store the checksum to go in the header as this may get overwritten in the wire header struct when transmitting as part of a jumbo packet. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> 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: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
* rxrpc: Convert rxrpc_txbuf::flags into a mask and don't use atomicsDavid Howells2024-02-297-38/+33
| | | | | | | | | | | | | | | | | | Convert the transmission buffer flags into a mask and use | and & rather than bitops functions (atomic ops are not required as only the I/O thread can manipulate them once submitted for transmission). The bottom byte can then correspond directly to the Rx protocol header flags. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> 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: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
* rxrpc: Record the Tx serial in the rxrpc_txbuf and retransmit traceDavid Howells2024-02-295-25/+29
| | | | | | | | | | | | | | | | | | Each Rx protocol packet contains a per-connection monotonically increasing serial number used to correlate outgoing messages with their replies - something that can be used for RTT calculation. Note this value in the rxrpc_txbuf struct in addition to the wire header and then log it in the rxrpc_retransmit trace for reference. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> 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: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org
* Merge branch 'net-collect-tstats-automatically'Paolo Abeni2024-02-292-1/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Breno Leitao says: ==================== net: collect tstats automatically The commit 34d21de99cea9 ("net: Move {l,t,d}stats allocation to core and convert veth & vrf") added a field in struct_netdevice, which tells what type of statistics the driver supports. That field is used primarily to allocate stats structures automatically, but, it also could leveraged to simplify the drivers even further, such as, if the driver relies in the default stats collection, then it doesn't need to assign to .ndo_get_stats64. That means that drivers only assign functions to .ndo_get_stats64 if they are using something special. I started to move some of these drivers[1][2][3] to use the core allocation, and with this change in, I just need to touch the driver once, and be able to simplify the whole stats allocation and collection for generic case. There are 44 devices today that could benefit from this simplification. # grep -r .ndo_get_stats64 | grep dev_get_tstats64 | wc -l 44 As of today, netnext only has the `sit` driver fully ported to core stats allocation, hence the second patch. Links: [1] https://lore.kernel.org/all/20240227182338.2739884-1-leitao@debian.org/ [2] https://lore.kernel.org/all/20240222144117.1370101-1-leitao@debian.org/ [3] https://lore.kernel.org/all/20240223115839.3572852-1-leitao@debian.org/ ==================== Link: https://lore.kernel.org/r/20240228113125.3473685-1-leitao@debian.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
| * net: sit: Do not set .ndo_get_stats64Breno Leitao2024-02-291-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the driver is using the network core allocation mechanism, by setting NETDEV_PCPU_STAT_TSTATS, as this driver is, then, it doesn't need to set the dev_get_tstats64() generic .ndo_get_stats64 function pointer. Since the network core calls it automatically, and .ndo_get_stats64 should only be set if the driver needs special treatment. This simplifies the driver, since all the generic statistics is now handled by core. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
| * net: get stats64 if device if driver is configuredBreno Leitao2024-02-291-0/+2
|/ | | | | | | | | | | | | | | If the network driver is relying in the net core to do stats allocation, then we want to dev_get_tstats64() instead of netdev_stats_to_stats64(), since there are per-cpu stats that needs to be taken in consideration. This will also simplify the drivers in regard to statistics. Once the driver sets NETDEV_PCPU_STAT_TSTATS, it doesn't not need to allocate the stacks, neither it needs to set `.ndo_get_stats64 = dev_get_tstats64` for the generic stats collection function anymore. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* net: stmmac: fix typo in commentYanteng Si2024-02-291-1/+1
| | | | | | | | | | This is just a trivial fix for a typo in a comment, no functional changes. Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Yanteng Si <siyanteng@loongson.cn> Link: https://lore.kernel.org/r/20240228112447.1490926-1-siyanteng@loongson.cn Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* ipv4: raw: remove useless input parameter in do_raw_set/getsockoptZhengchao Shao2024-02-291-5/+5
| | | | | | | | | | The input parameter 'level' in do_raw_set/getsockopt() is not used. Therefore, remove it. Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240228072505.640550-1-shaozhengchao@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* Merge branch 'net-dsa-mv88e6xxx-add-amethyst-specific-smi-gpio-function'Paolo Abeni2024-02-293-4/+40
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Robert Marko says: ==================== net: dsa: mv88e6xxx: add Amethyst specific SMI GPIO function Amethyst family (MV88E6191X/6193X/6393X) has a simplified SMI GPIO setting via the Scratch and Misc register so it requires family specific function. In the v1 review, Andrew pointed out that it would make sense to rename the existing mv88e6xxx_g2_scratch_gpio_set_smi as it only works on the MV6390 family. Changes in v2: * Add rename of mv88e6xxx_g2_scratch_gpio_set_smi to mv88e6390_g2_scratch_gpio_set_smi ==================== Link: https://lore.kernel.org/r/20240227175457.2766628-1-robimarko@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
| * net: dsa: mv88e6xxx: add Amethyst specific SMI GPIO functionRobert Marko2024-02-293-1/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing mv88e6390_g2_scratch_gpio_set_smi() cannot be used on the 88E6393X as it requires certain P0_MODE, it also checks the CPU mode as it impacts the bit setting value. This is all irrelevant for Amethyst (MV88E6191X/6193X/6393X) as only the default value of the SMI_PHY Config bit is set to CPU_MGD bootstrap pin value but it can be changed without restrictions so that GPIO pins 9 and 10 are used as SMI pins. So, introduce Amethyst specific function and call that if the Amethyst family wants to setup the external PHY. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Robert Marko <robimarko@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
| * net: dsa: mv88e6xxx: rename mv88e6xxx_g2_scratch_gpio_set_smiRobert Marko2024-02-293-4/+4
|/ | | | | | | | | | The name mv88e6xxx_g2_scratch_gpio_set_smi is a bit ambiguous as it appears to only be applicable to the 6390 family, so lets rename it to mv88e6390_g2_scratch_gpio_set_smi to make it more obvious. Signed-off-by: Robert Marko <robimarko@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* inet6: expand rcu_read_lock() scope in inet6_dump_addr()Eric Dumazet2024-02-291-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I missed that inet6_dump_addr() is calling in6_dump_addrs() from two points. First one under RTNL protection, and second one under rcu_read_lock(). Since we want to remove RTNL use from inet6_dump_addr() very soon, no longer assume in6_dump_addrs() is protected by RTNL (even if this is still the case). Use rcu_read_lock() earlier to fix this lockdep splat: WARNING: suspicious RCU usage 6.8.0-rc5-syzkaller-01618-gf8cbf6bde4c8 #0 Not tainted net/ipv6/addrconf.c:5317 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by syz-executor.2/8834: #0: ffff88802f554678 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x119/0x780 net/netlink/af_netlink.c:2338 #1: ffffffff8f377a88 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0x676/0xda0 net/netlink/af_netlink.c:2265 #2: ffff88807e5f0580 (&ndev->lock){++--}-{2:2}, at: in6_dump_addrs+0xb8/0x1de0 net/ipv6/addrconf.c:5279 stack backtrace: CPU: 1 PID: 8834 Comm: syz-executor.2 Not tainted 6.8.0-rc5-syzkaller-01618-gf8cbf6bde4c8 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106 lockdep_rcu_suspicious+0x220/0x340 kernel/locking/lockdep.c:6712 in6_dump_addrs+0x1b47/0x1de0 net/ipv6/addrconf.c:5317 inet6_dump_addr+0x1597/0x1690 net/ipv6/addrconf.c:5428 netlink_dump+0x6a6/0xda0 net/netlink/af_netlink.c:2266 __netlink_dump_start+0x59d/0x780 net/netlink/af_netlink.c:2374 netlink_dump_start include/linux/netlink.h:340 [inline] rtnetlink_rcv_msg+0xcf7/0x10d0 net/core/rtnetlink.c:6555 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2547 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x8e0/0xcb0 net/netlink/af_netlink.c:1902 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 Fixes: c3718936ec47 ("ipv6: anycast: complete RCU handling of struct ifacaddr6") Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240227222259.4081489-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: call skb_defer_free_flush() from __napi_busy_loop()Eric Dumazet2024-02-291-21/+22
| | | | | | | | | | | | | | | | skb_defer_free_flush() is currently called from net_rx_action() and napi_threaded_poll(). We should also call it from __napi_busy_loop() otherwise there is the risk the percpu queue can grow until an IPI is forced from skb_attempt_defer_free() adding a latency spike. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Samiullah Khawaja <skhawaja@google.com> Acked-by: Stanislav Fomichev <sdf@google.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240227210105.3815474-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* tcp: remove some holes in struct tcp_sockEric Dumazet2024-02-291-4/+4
| | | | | | | | | | | | | | | | | | | By moving some fields around, this patch shrinks holes size from 56 to 32, saving 24 bytes on 64bit arches. After the patch pahole gives the following for 'struct tcp_sock': /* size: 2304, cachelines: 36, members: 162 */ /* sum members: 2234, holes: 6, sum holes: 32 */ /* sum bitfield members: 34 bits, bit holes: 5, sum bit holes: 14 bits */ /* padding: 32 */ /* paddings: 3, sum paddings: 10 */ /* forced alignments: 1, forced holes: 1, sum forced holes: 12 */ Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240227192721.3558982-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: bridge: Exit if multicast_init_stats failsBreno Leitao2024-02-291-1/+2
| | | | | | | | | | If br_multicast_init_stats() fails, there is no need to set lockdep classes. Just return from the error path. Signed-off-by: Breno Leitao <leitao@debian.org> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://lore.kernel.org/r/20240227182338.2739884-2-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: bridge: Do not allocate stats in the driverBreno Leitao2024-02-291-11/+2
| | | | | | | | | | | | | | | | | | With commit 34d21de99cea9 ("net: Move {l,t,d}stats allocation to core and convert veth & vrf"), stats allocation could be done on net core instead of this driver. With this new approach, the driver doesn't have to bother with error handling (allocation failure checking, making sure free happens in the right spot, etc). This is core responsibility now. Remove the allocation in the bridge driver and leverage the network core allocation. Signed-off-by: Breno Leitao <leitao@debian.org> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://lore.kernel.org/r/20240227182338.2739884-1-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* selftests: vxlan_mdb: Avoid duplicate test namesIdo Schimmel2024-02-291-18/+18
| | | | | | | | | | Rename some test cases to avoid overlapping test names which is problematic for the kernel test robot. No changes in the test's logic. Suggested-by: Yujie Liu <yujie.liu@intel.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/20240227170418.491442-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* netlabel: remove impossible return value in netlbl_bitmap_walkZhengchao Shao2024-02-293-9/+3
| | | | | | | | | | | | Since commit 446fda4f2682 ("[NetLabel]: CIPSOv4 engine"), *bitmap_walk function only returns -1. Nearly 18 years have passed, -2 scenes never come up, so there's no need to consider it. Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Acked-by: Paul Moore <paul@paul-moore.com> Link: https://lore.kernel.org/r/20240227093604.3574241-1-shaozhengchao@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* Merge branch 'inet-implement-lockless-rtm_getnetconf-ops'Jakub Kicinski2024-02-295-90/+81
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Eric Dumazet says: ==================== inet: implement lockless RTM_GETNETCONF ops This series removes RTNL use for RTM_GETNETCONF operations on AF_INET. - Annotate data-races to avoid possible KCSAN splats. - "ip -4 netconf show dev XXX" can be implemented without RTNL [1] - "ip -4 netconf" dumps can be implemented using RCU instead of RTNL [1] [1] This only refers to RTM_GETNETCONF operation, "ip" command also uses RTM_GETLINK dumps which are using RTNL at this moment. ==================== Link: https://lore.kernel.org/r/20240227092411.2315725-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * inet: use xa_array iterator to implement inet_netconf_dump_devconf()Eric Dumazet2024-02-291-58/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1) inet_netconf_dump_devconf() can run under RCU protection instead of RTNL. 2) properly return 0 at the end of a dump, avoiding an an extra recvmsg() system call. 3) Do not use inet_base_seq() anymore, for_each_netdev_dump() has nice properties. Restarting a GETDEVCONF dump if a device has been added/removed or if net->ipv4.dev_addr_genid has changed is moot. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240227092411.2315725-4-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * inet: do not use RTNL in inet_netconf_get_devconf()Eric Dumazet2024-02-291-12/+15
| | | | | | | | | | | | | | | | | | | | | | "ip -4 netconf show dev XXXX" no longer acquires RTNL. Return -ENODEV instead of -EINVAL if no netdev or idev can be found. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240227092411.2315725-3-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * inet: annotate devconf data-racesEric Dumazet2024-02-295-21/+24
|/ | | | | | | | | | | | | Add READ_ONCE() in ipv4_devconf_get() and corresponding WRITE_ONCE() in ipv4_devconf_set() Add IPV4_DEVCONF_RO() and IPV4_DEVCONF_ALL_RO() macros, and use them when reading devconf fields. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240227092411.2315725-2-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: phy: dp83826: disable WOL at initCatalin Popescu2024-02-291-1/+1
| | | | | | | | | | | Commit d1d77120bc28 ("net: phy: dp83826: support TX data voltage tuning") introduced a regression in that WOL is not disabled by default for DP83826. WOL should normally be enabled through ethtool. Fixes: d1d77120bc28 ("net: phy: dp83826: support TX data voltage tuning") Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com> Link: https://lore.kernel.org/r/20240226162339.696461-1-catalin.popescu@leica-geosystems.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: remove SLAB_MEM_SPREAD flag usageChengming Zhou2024-02-291-1/+1
| | | | | | | | | | | | | | | The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was removed as of v6.8-rc1, so it became a dead flag since the commit 16a1d968358a ("mm/slab: remove mm/slab.c and slab_def.h"). And the series[1] went on to mark it obsolete to avoid confusion for users. Here we can just remove all its users, which has no functional change. [1] https://lore.kernel.org/all/20240223-slab-cleanup-flags-v2-1-02f1753e8303@suse.cz/ Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240228030658.3512782-1-chengming.zhou@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* Merge branch 'tools-ynl-stop-using-libmnl'Jakub Kicinski2024-02-295-268/+543
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Jakub Kicinski says: ==================== tools: ynl: stop using libmnl There is no strong reason to stop using libmnl in ynl but there are a few small ones which add up. First (as I remembered immediately after hitting send on v1), C++ compilers do not like the libmnl for_each macros. I haven't tried it myself, but having all the code directly in YNL makes it easier for folks porting to C++ to modify them and/or make YNL more C++ friendly. Second, we do much more advanced netlink level parsing in ynl than libmnl so it's hard to say that libmnl abstracts much from us. The fact that this series, removing the libmnl dependency, only adds <300 LoC shows that code savings aren't huge. OTOH when new types are added (e.g. auto-int) we need to add compatibility to deal with older version of libmnl (in fact, even tho patches have been sent months ago, auto-ints are still not supported in libmnl.git). Thrid, the dependency makes ynl less self contained, and harder to vendor in. Whether vendoring libraries into projects is a good idea is a separate discussion, nonetheless, people want to do it. Fourth, there are small annoyances with the libmnl APIs which are hard to fix in backward-compatible ways. See the last patch for example. All in all, libmnl is a great library, but with all the code generation and structured parsing, ynl is better served by going its own way. v1: https://lore.kernel.org/all/20240222235614.180876-1-kuba@kernel.org/ ==================== Link: https://lore.kernel.org/r/20240227223032.1835527-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * tools: ynl: use MSG_DONTWAIT for getting notificationsJakub Kicinski2024-02-291-15/+14
| | | | | | | | | | | | | | | | | | | | To stick to libmnl wrappers in the past we had to use poll() to check if there are any outstanding notifications on the socket. This is no longer necessary, we can use MSG_DONTWAIT. Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://lore.kernel.org/r/20240227223032.1835527-16-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * tools: ynl: remove the libmnl dependencyJakub Kicinski2024-02-294-6/+2
| | | | | | | | | | | | | | | | We don't use libmnl any more. Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://lore.kernel.org/r/20240227223032.1835527-15-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * tools: ynl: stop using mnl socket helpersJakub Kicinski2024-02-293-22/+42
| | | | | | | | | | | | | | | | | | | | Most libmnl socket helpers can be replaced by direct calls to the underlying libc API. We need portid, the netlink manpage suggests we bind() address of zero. Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://lore.kernel.org/r/20240227223032.1835527-14-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * tools: ynl: switch away from MNL_CB_*Jakub Kicinski2024-02-293-34/+40
| | | | | | | | | | | | | | | | Create a local version of the MNL_CB_* parser control values. Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://lore.kernel.org/r/20240227223032.1835527-13-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * tools: ynl: switch away from mnl_cb_tJakub Kicinski2024-02-293-18/+21
| | | | | | | | | | | | | | | | | | All YNL parsing callbacks take struct ynl_parse_arg as the argument. Make that official by using a local callback type instead of mnl_cb_t. Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://lore.kernel.org/r/20240227223032.1835527-12-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * tools: ynl: stop using mnl_cb_run2()Jakub Kicinski2024-02-292-19/+45
| | | | | | | | | | | | | | | | | | | | There's only one set of callbacks in YNL, for netlink control messages, and most of them are trivial. So implement the message walking directly without depending on mnl_cb_run2(). Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://lore.kernel.org/r/20240227223032.1835527-11-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * tools: ynl: use ynl_sock_read_msgs() for ACK handlingJakub Kicinski2024-02-292-23/+14
| | | | | | | | | | | | | | | | | | | | ynl_recv_ack() is simple and it's the only user of mnl_cb_run(). Now that ynl_sock_read_msgs() exists it's actually less code to use ynl_sock_read_msgs() instead of being special. Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://lore.kernel.org/r/20240227223032.1835527-10-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * tools: ynl: wrap recv() + mnl_cb_run2() into a single helperJakub Kicinski2024-02-291-38/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All callers to mnl_cb_run2() call mnl_socket_recvfrom() right before. Wrap the two in a helper, take typed arguments (struct ynl_parse_arg), instead of hoping that all callers remember that parser error handling requires yarg. In case of ynl_sock_read_family() we will no longer check for kernel returning no data, but that would be a kernel bug, not worth complicating the code to catch this. Calling mnl_cb_run2() on an empty buffer is legal and results in STOP (1). Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://lore.kernel.org/r/20240227223032.1835527-9-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * tools: ynl-gen: remove unused parse codeJakub Kicinski2024-02-293-11/+1
| | | | | | | | | | | | | | | | | | | | Commit f2ba1e5e2208 ("tools: ynl-gen: stop generating common notification handlers") removed the last caller of the parse_cb_run() helper. We no longer need to export ynl_cb_array. Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://lore.kernel.org/r/20240227223032.1835527-8-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * tools: ynl: make yarg the first member of struct ynl_dump_stateJakub Kicinski2024-02-293-7/+6
| | | | | | | | | | | | | | | | | | | | | | All YNL parsing code expects a pointer to struct ynl_parse_arg AKA yarg. For dump was pass in struct ynl_dump_state, which works fine, because struct ynl_dump_state and struct ynl_parse_arg have identical layout for the members that matter.. but it's a bit hacky. Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://lore.kernel.org/r/20240227223032.1835527-7-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * tools: ynl: create local ARRAY_SIZE() helperJakub Kicinski2024-02-292-2/+5
| | | | | | | | | | | | | | | | libc doesn't have an ARRAY_SIZE() create one locally. Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://lore.kernel.org/r/20240227223032.1835527-6-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * tools: ynl: create local nlmsg access helpersJakub Kicinski2024-02-293-17/+52
| | | | | | | | | | | | | | | | | | Create helpers for accessing payloads of struct nlmsg. Use them instead of the libmnl ones. Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://lore.kernel.org/r/20240227223032.1835527-5-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * tools: ynl: create local for_each helpersJakub Kicinski2024-02-293-10/+57
| | | | | | | | | | | | | | | | | | Create ynl_attr_for_each*() iteration helpers. Use them instead of the mnl ones. Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://lore.kernel.org/r/20240227223032.1835527-4-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * tools: ynl: create local attribute helpersJakub Kicinski2024-02-293-74/+227
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't use mnl attr helpers, we're trying to remove the libmnl dependency. Create both signed and unsigned helpers, libmnl had unsigned helpers, so code generator no longer needs the mnl_type() hack. The new helpers are written from first principles, but are hopefully not too buggy. Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://lore.kernel.org/r/20240227223032.1835527-3-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * tools: ynl: give up on libmnl for auto-intsJakub Kicinski2024-02-291-9/+36
|/ | | | | | | | | | | | | | | The temporary auto-int helpers are not really correct. We can't treat signed and unsigned ints the same when determining whether we need full 8B. I realized this before sending the patch to add support in libmnl. Unfortunately, that patch has not been merged, so time to fix our local helpers. Use the mnl* name for now, subsequent patches will address that. Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Link: https://lore.kernel.org/r/20240227223032.1835527-2-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-19 21:53:38 +0100