- 05 Jun, 2024 14 commits
-
-
Kevin Yang authored
Adding a sysctl knob to allow user to specify a default rto_min at socket init time, other than using the hard coded 200ms default rto_min. Note that the rto_min route option has the highest precedence for configuring this setting, followed by the TCP_BPF_RTO_MIN socket option, followed by the tcp_rto_min_us sysctl. Signed-off-by:
Kevin Yang <yyd@google.com> Reviewed-by:
Neal Cardwell <ncardwell@google.com> Reviewed-by:
Yuchung Cheng <ycheng@google.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
Tony Lu <tonylu@linux.alibaba.com> Reviewed-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Kevin Yang authored
Rto_min now has multiple sources, ordered by preprecedence high to low: ip route option rto_min, icsk->icsk_rto_min. When derive delack_max from rto_min, we should not only use ip route option, but should use tcp_rto_min helper to get the correct rto_min. Signed-off-by:
-
Eric Dumazet authored
These fields can be read and written locklessly, add annotations around these minor races. Signed-off-by:
Simon Horman <horms@kernel.org> Signed-off-by:
-
Anshumali Gaur authored
This patch adds support to dump NIX transmit queue topology. There are multiple levels of scheduling/shaping supported by NIX and a packet traverses through multiple levels before sending the packet out. At each level, there are set of scheduling/shaping rules applied to a packet flow. Each packet traverses through multiple levels SQ->SMQ->TL4->TL3->TL2->TL1 and these levels are mapped in a parent-child relationship. This patch dumps the debug information related to all TM Levels in the following way. Example: $ echo <nixlf> > /sys/kernel/debug/octeontx2/nix/tm_tree $ cat /sys/kernel/debug/octeontx2/nix/tm_tree A more desriptive set of registers at each level can be dumped in the following way. Example: $ echo <nixlf> > /sys/kernel/debug/octeontx2/nix/tm_topo $ cat /sys/kernel/debug/octeontx2/nix/tm_topo Signed-off-by:
Anshumali Gaur <agaur@marvell.com> Reviewed-by:
Wojciech Drewek <wojciech.drewek@intel.com> Reviewed-by:
-
David S. Miller authored
Christophe JAILLET says: ==================== devlink: Constify struct devlink_dpipe_table_ops Patch 1 updates devl_dpipe_table_register() and struct devlink_dpipe_table to accept "const struct devlink_dpipe_table_ops". Then patch 2 updates the only user of this function. This is compile tested only. ==================== Signed-off-by: -
Christophe JAILLET authored
'struct devlink_dpipe_table_ops' are not modified in this driver. Constifying these structures moves some data to a read-only section, so increase overall security. On a x86_64, with allmodconfig: Before: ====== text data bss dec hex filename 15557 712 0 16269 3f8d drivers/net/ethernet/mellanox/mlxsw/spectrum_dpipe.o After: ===== text data bss dec hex filename 15789 488 0 16277 3f95 drivers/net/ethernet/mellanox/mlxsw/spectrum_dpipe.o Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
-
Christophe JAILLET authored
"struct devlink_dpipe_table_ops" only contains some function pointers. Update "struct devlink_dpipe_table" and the 'table_ops' parameter of devl_dpipe_table_register() so that structures in drivers can be constified. Constifying these structures will move some data to a read-only section, so increase overall security. Signed-off-by:
-
Daniel Golle authored
Aquantia Ethernet PHYs got 3 LED output pins which are typically used to indicate link status and activity. Add a minimal LED controller driver supporting the most common uses with the 'netdev' trigger as well as software-driven forced control of the LEDs. Signed-off-by:
Daniel Golle <daniel@makrotopia.org> [ rework indentation, fix checkpatch error and improve some functions ] Signed-off-by:
Christian Marangi <ansuelsmth@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Christian Marangi authored
In preparation for LEDs support, move priv and hw stat to header to reference priv struct also in other .c outside aquantia.main Signed-off-by:
-
Dr. David Alan Gilbert authored
'cable_test_tdr_req_info' is unused since the original commit f2bc8ad3 ("net: ethtool: Allow PHY cable test TDR data to configured"). Remove it. Signed-off-by:
Dr. David Alan Gilbert <linux@treblig.org> Reviewed-by:
-
Dr. David Alan Gilbert authored
'cfpktq' has been unused since commit 73d6ac63 ("caif: code cleanup"). 'caif_packet_funcs' is declared but never defined. Remove both of them. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
-
Jason Xing authored
When I was doing some experiments, I found that when using the first parameter, namely, struct net, in ip_metrics_convert() always triggers NULL pointer crash. Then I digged into this part, realizing that we can remove this one due to its uselessness. Signed-off-by:
Jason Xing <kernelxing@tencent.com> Reviewed-by:
-
Chen Hanxiao authored
Smatch complains: net/bridge/br_netlink_tunnel.c: 318 br_process_vlan_tunnel_info() warn: inconsistent indenting Fix it with a proper indenting Signed-off-by:
Chen Hanxiao <chenhx.fnst@fujitsu.com> Acked-by:
Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by:
-
Linus Walleij authored
This rewrites the Vitesse VSC73xx DSA switches DT binding in schema. It was a bit tricky since I needed to come up with some way of applying the SPI properties only on SPI devices and not platform devices, but I figured something out that works. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Rob Herring (Arm) <robh@kernel.org> Signed-off-by:
-
- 04 Jun, 2024 13 commits
-
-
Jakub Kicinski authored
This reverts commit 727c94c9. Stephen reports that this commit causes a circular module dependency for him. Revert, and we'll try to address the problem, again. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Link: https://lore.kernel.org/all/20240531152223.25591c8e@canb.auug.org.auSigned-off-by:
-
Breno Leitao authored
Commit 3e2f544d ("net: get stats64 if device if driver is configured") moved the callback to dev_get_tstats64() to net core, so, unless the driver is doing some custom stats collection, it does not need to set .ndo_get_stats64. Since this driver is now relying in NETDEV_PCPU_STAT_TSTATS, then, it doesn't need to set the dev_get_tstats64() generic .ndo_get_stats64 function pointer. Signed-off-by:
Breno Leitao <leitao@debian.org> Reviewed-by:
Subbaraya Sundeep <sbhatta@marvell.com> Link: https://lore.kernel.org/r/20240531111552.3209198-2-leitao@debian.orgSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Breno Leitao authored
With commit 34d21de9 ("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. Move openvswitch driver to leverage the core allocation. Signed-off-by:
-
Paolo Abeni authored
Jakub Kicinski says: ==================== tcp: refactor skb_cmp_decrypted() checks Refactor the input patch coalescing checks and wrap "EOR forcing" logic into a helper. This will hopefully make the code easier to follow. While at it throw some DEBUG_NET checks into skb_shift(). ==================== Link: https://lore.kernel.org/r/20240530233616.85897-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
According to current semantics we should never try to shift data between skbs which differ on decrypted or pp_recycle status. Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Jakub Kicinski authored
TLS (and hopefully soon PSP will) use EOR to prevent skbs with different decrypted state from getting merged, without adding new tests to the skb handling. In both cases once the connection switches to an "encrypted" state, all subsequent skbs will be encrypted, so a single "EOR fence" is sufficient to prevent mixing. Add a helper for setting the EOR bit, to make this arrangement more explicit. Signed-off-by:
-
Jakub Kicinski authored
tcp_skb_can_collapse() checks for conditions which don't make sense on input. Because of this we ended up sprinkling a few pairs of mptcp_skb_can_collapse() and skb_cmp_decrypted() calls on the input path. Group them in a new helper. This should make it less likely that someone will check mptcp and not decrypted or vice versa when adding new code. This implicitly adds a decrypted check early in tcp_collapse(). AFAIU this will very slightly increase our ability to collapse packets under memory pressure, not a real bug. Signed-off-by:
Matthieu Baerts (NGI0) <matttbe@kernel.org> Reviewed-by:
-
Paolo Abeni authored
Davide Caratti says: ==================== net: allow dissecting/matching tunnel control flags Ilya says: "for correct matching on decapsulated packets, we should match on not only tunnel id and headers, but also on tunnel configuration flags like TUNNEL_NO_CSUM and TUNNEL_DONT_FRAGMENT. This is done to distinguish similar tunnels with slightly different configs. And it is important since tunnel configuration is flow based, i.e. can be different for every packet, even though the main tunnel port is the same." - patch 1 extends the kernel's flow dissector to extract these flags from the packet's tunnel metadata. - patch 2 extends TC flower to match on any combination of TUNNEL_NO_CSUM, TUNNEL_DONT_FRAGMENT, TUNNEL_OAM, TUNNEL_CRIT_OPT v4: - fix kernel-doc warning in flow_dissector.h (thanks Jakub) v3: - rebase on top of new uAPI bits and internals after commit 5832c4a7 ("ip_tunnel: convert __be16 tunnel flags to bitmaps"). Use of network byte order is no more needed, since these bits match on metadata: convert netlink attributes to be u32. - also include TUNNEL_CRIT_OPT v2: - use NL_REQ_ATTR_CHECK() where possible (thanks Jamal) - don't overwrite 'ret' in the error path of fl_set_key_flags() ==================== Link: https://lore.kernel.org/r/cover.1717088241.git.dcaratti@redhat.comSigned-off-by:
-
Davide Caratti authored
extend cls_flower to match TUNNEL_FLAGS_PRESENT bits in tunnel metadata. Suggested-by:
Ilya Maximets <i.maximets@ovn.org> Acked-by:
Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
Davide Caratti <dcaratti@redhat.com> Reviewed-by:
-
Davide Caratti authored
Dissect [no]csum, [no]dontfrag, [no]oam, [no]crit flags from skb metadata. This is a prerequisite for matching these control flags using TC flower. Suggested-by:
-
Jakub Kicinski authored
Catching and debugging missing qdiscs is pretty tricky. When qdisc is deleted we replace it with a noop qdisc, which silently drops all the packets. Since the noop qdisc has a single static instance we can't count drops at the qdisc level. Count them as dev->tx_drops. ip netns add red ip link add type veth peer netns red ip link set dev veth0 up ip -netns red link set dev veth0 up ip a a dev veth0 10.0.0.1/24 ip -netns red a a dev veth0 10.0.0.2/24 ping -c 2 10.0.0.2 # 2 packets transmitted, 2 received, 0% packet loss, time 1031ms ip -s link show dev veth0 # TX: bytes packets errors dropped carrier collsns # 1314 17 0 0 0 0 tc qdisc replace dev veth0 root handle 1234: mq tc qdisc replace dev veth0 parent 1234:1 pfifo tc qdisc del dev veth0 parent 1234:1 ping -c 2 10.0.0.2 # 2 packets transmitted, 0 received, 100% packet loss, time 1034ms ip -s link show dev veth0 # TX: bytes packets errors dropped carrier collsns # 1314 17 0 3 0 0 Signed-off-by:
-
Douglas Anderson authored
If we get to the end of the r8152's suspend() routine and we find that the USB device is INACCESSIBLE then it means that some of our preparation for suspend didn't take place. We need a USB reset to get ourselves back in a consistent state so we can try again and that can't happen during system suspend. Call pm_wakeup_event() to wake the system up in this case. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Acked-by:
Hayes Wang <hayeswang@realtek.com> Link: https://lore.kernel.org/r/66590f25.170a0220.8b5ad.1752@mx.google.comSigned-off-by:
-
Douglas Anderson authored
If we happened to get a USB transfer error during the transition to suspend then the usb_queue_reset_device() that r8152_control_msg() calls will get dropped on the floor. This is because usb_lock_device_for_reset() (which usb_queue_reset_device() uses) silently fails if it's called when a device is suspended or if too much time passes. Let's resolve this by resetting the device ourselves in r8152's resume() function. NOTE: due to timing, it's _possible_ that we could end up with two USB resets: the one queued previously and the one called from the resume() patch. This didn't happen in test cases I ran, though it's conceivably possible. We can't easily know if this happened since usb_queue_reset_device() can just silently drop the reset request. In any case, it's not expected that this is a problem since the two resets can't run at the same time (because of the device lock) and it should be OK to reset the device twice. If somehow the double-reset causes problems we could prevent resets from being queued up while suspend is running. Signed-off-by:
-
- 03 Jun, 2024 12 commits
-
-
David S. Miller authored
Vladimir Oltean says: ==================== Probing cleanup for the Felix DSA driver This is a follow-up to Russell King's request for code consolidation among felix_vsc9959, seville_vsc9953 and ocelot_ext, stated here: https://lore.kernel.org/all/Zh1GvcOTXqb7CpQt@shell.armlinux.org.uk/ Details are in individual patches. Testing was done on NXP LS1028A (felix_vsc9959). ==================== Signed-off-by:
-
Vladimir Oltean authored
Now that the common felix_register_switch() from the umbrella driver is the only entity that accesses these data structures, we can remove them from the list of the exported symbols. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Sai Krishna <saikrishnag@marvell.com> Signed-off-by:
-
Vladimir Oltean authored
Russell King suggested that felix_vsc9959, seville_vsc9953 and ocelot_ext have a large portion of duplicated init code, which could be made common [1]. [1]: https://lore.kernel.org/all/Zh1GvcOTXqb7CpQt@shell.armlinux.org.uk/ Here, we take the following common steps: - "felix" and "ds" structure allocation - "felix", "ocelot" and "ds" basic structure initialization - dsa_register_switch() call and we make a common function out of them. For every driver except felix_vsc9959, this is also the entire probing procedure. For felix_vsc9959, we also need to do some PCI-specific stuff, which can easily be reordered to be done before, and unwound on failure. We also have to convert the bus-specific platform_set_drvdata() and pci_set_drvdata() calls into dev_set_drvdata(). But this should have no impact on the behavior. Suggested-by:
"Russell King (Oracle)" <linux@armlinux.org.uk> Signed-off-by:
Colin Foster <colin.foster@in-advantage.com> Signed-off-by:
-
Vladimir Oltean authored
Russell King points out that seville_vsc9953 populates felix->info->num_tx_queues = 8, but this doesn't make it all the way into ds->num_tx_queues (which is how the user interface netdev queues get allocated) [1]. [1]: https://lore.kernel.org/all/20240415160150.yejcazpjqvn7vhxu@skbuf/ When num_tx_queues=0 for seville, this is implicitly converted to 1 by dsa_user_create(), and this is good enough for basic operation for a switch port. The tc qdisc offload layer works with netdev TX queues, so for QoS offload we need to pretend we have multiple TX queues. The VSC9953, like ocelot_ext, doesn't export QoS offload, so it doesn't really matter. But we can definitely set num_tx_queues=8 for all switches. The felix->info->num_tx_queues construct itself seems unnecessary. It was introduced by commit de143c0e ("net: dsa: felix: Configure Time-Aware Scheduler via taprio offload") at a time when vsc9959 (LS1028A) was the only switch supported by the driver. 8 traffic classes, and 1 queue per traffic class, is a common architectural feature of all switches in the family. So they could all just set OCELOT_NUM_TC and be fine. Signed-off-by:
-
Vladimir Oltean authored
The current placement of devm_request_threaded_irq() is inconvenient. It is between the allocation of the "felix" structure and dsa_register_switch(), both of which we'd like to refactor into a function that's common for all switches. But the IRQ is specific to felix_vsc9959. A closer inspection of the felix_irq_handler() code suggests that it does things that depend on the data structures having been fully initialized. For example, ocelot_get_txtstamp() takes &port->tx_skbs.lock, which has only been initialized in ocelot_init_port() which has not run yet. It is not one of those IRQF_SHARED IRQs, so CONFIG_DEBUG_SHIRQ_FIXME shouldn't apply here, and thus, it doesn't really matter, because in practice, the IRQ will not be triggered so early. Nonetheless, it is a good practice for the driver to be prepared for it to fire as soon as it is requested. Create a new felix->info method for running custom code for vsc9959 from within felix_setup(), and move the request_irq() call there. The ocelot_ext should have an IRQ as well, so this should be a step in the right direction for that model (VSC7512) as well. Some minor changes are made while moving the code. Casts from void * aren't necessary, so drop them, and rename felix_irq_handler() to the more specific vsc9959_irq_handler(). Signed-off-by:
-
Vladimir Oltean authored
Russell King suggested that felix_vsc9959, seville_vsc9953 and ocelot_ext have a large portion of duplicated init and teardown code, which could be made common [1]. The teardown code could even be simplified away if we made use of devres, something which is used here and there in the felix driver, just not very consistently. [1] https://lore.kernel.org/all/Zh1GvcOTXqb7CpQt@shell.armlinux.org.uk/ Prepare the ground in the felix_vsc9959 driver, by allocating the data structures using devres and deleting the kfree() calls. This also deletes the "Failed to allocate ..." message, since memory allocation errors are extremely loud anyway, and it's hard to miss them. Suggested-by:
-
Vladimir Oltean authored
Since commit 6fffbc7a ("PCI: Honor firmware's device disabled status"), PCI device drivers with OF bindings no longer need this check. Signed-off-by:
-
Vladimir Oltean authored
Russell King suggested that felix_vsc9959, seville_vsc9953 and ocelot_ext have a large portion of duplicated init and teardown code, which could be made common [1]. The teardown code could even be simplified away if we made use of devres, something which is used here and there in the felix driver, just not very consistently. [1] https://lore.kernel.org/all/Zh1GvcOTXqb7CpQt@shell.armlinux.org.uk/ Prepare the ground in the seville_vsc9953 driver, by allocating the data structures using devres and deleting the kfree() calls. This also deletes the "Failed to allocate ..." message, since memory allocation errors are extremely loud anyway, and it's hard to miss them. Suggested-by:
-
Vladimir Oltean authored
Russell King suggested that felix_vsc9959, seville_vsc9953 and ocelot_ext have a large portion of duplicated init and teardown code, which could be made common [1]. The teardown code could even be simplified away if we made use of devres, something which is used here and there in the felix driver, just not very consistently. [1] https://lore.kernel.org/all/Zh1GvcOTXqb7CpQt@shell.armlinux.org.uk/ Prepare the ground in the ocelot_ext driver, by allocating the data structures using devres and deleting the kfree() calls. This also deletes the "Failed to allocate ..." message, since memory allocation errors are extremely loud anyway, and it's hard to miss them. Suggested-by:
-
David S. Miller authored
Guangguan Wang says: ==================== net/smc: Change the upper boundary of SMC-R's snd_buf and rcv_buf to 512MB SMCR_RMBE_SIZES is the upper boundary of SMC-R's snd_buf and rcv_buf. The maximum bytes of snd_buf and rcv_buf can be calculated by 2^SMCR_ RMBE_SIZES * 16KB. SMCR_RMBE_SIZES = 5 means the upper boundary is 512KB. TCP's snd_buf and rcv_buf max size is configured by net.ipv4.tcp_w/rmem[2] whose default value is 4MB or 6MB, is much larger than SMC-R's upper boundary. In some scenarios, such as Recommendation System, the communication pattern is mainly large size send/recv, where the size of snd_buf and rcv_buf greatly affects performance. Due to the upper boundary disadvantage, SMC-R performs poor than TCP in those scenarios. So it is time to enlarge the upper boundary size of SMC-R's snd_buf and rcv_buf, so that the SMC-R's snd_buf and rcv_buf can be configured to larger size for performance gain in such scenarios. The SMC-R rcv_buf's size will be transferred to peer by the field rmbe_size in clc accept and confirm message. The length of the field rmbe_size is four bits, which means the maximum value of SMCR_RMBE_SIZES is 15. In case of frequently adjusting the value of SMCR_RMBE_SIZES in different scenarios, set the value of SMCR_RMBE_SIZES to the maximum value 15, which means the upper boundary of SMC-R's snd_buf and rcv_buf is 512MB. As the real memory usage is determined by the value of net.smc.w/rmem, not by the upper boundary, set the value of SMCR_RMBE_SIZES to the maximum value has no side affects. ==================== Signed-off-by: -
Guangguan Wang authored
SMCR_RMBE_SIZES is the upper boundary of SMC-R's snd_buf and rcv_buf. The maximum bytes of snd_buf and rcv_buf can be calculated by 2^SMCR_ RMBE_SIZES * 16KB. SMCR_RMBE_SIZES = 5 means the upper boundary is 512KB. TCP's snd_buf and rcv_buf max size is configured by net.ipv4.tcp_w/rmem[2] whose default value is 4MB or 6MB, is much larger than SMC-R's upper boundary. In some scenarios, such as Recommendation System, the communication pattern is mainly large size send/recv, where the size of snd_buf and rcv_buf greatly affects performance. Due to the upper boundary disadvantage, SMC-R performs poor than TCP in those scenarios. So it is time to enlarge the upper boundary size of SMC-R's snd_buf and rcv_buf, so that the SMC-R's snd_buf and rcv_buf can be configured to larger size for performance gain in such scenarios. The SMC-R rcv_buf's size will be transferred to peer by the field rmbe_size in clc accept and confirm message. The length of the field rmbe_size is four bits, which means the maximum value of SMCR_RMBE_SIZES is 15. In case of frequently adjusting the value of SMCR_RMBE_SIZES in different scenarios, set the value of SMCR_RMBE_SIZES to the maximum value 15, which means the upper boundary of SMC-R's snd_buf and rcv_buf is 512MB. As the real memory usage is determined by the value of net.smc.w/rmem, not by the upper boundary, set the value of SMCR_RMBE_SIZES to the maximum value has no side affects. Signed-off-by:
Guangguan Wang <guangguan.wang@linux.alibaba.com> Co-developed-by:
Wen Gu <guwen@linux.alibaba.com> Signed-off-by:
-
Guangguan Wang authored
SG_MAX_SINGLE_ALLOC is used to limit maximum number of entries that will be allocated in one piece of scatterlist. When the entries of scatterlist exceeds SG_MAX_SINGLE_ALLOC, sg chain will be used. From commit 7c703e54 ("arch: switch the default on ARCH_HAS_SG_CHAIN"), we can know that the macro CONFIG_ARCH_NO_SG_CHAIN is used to identify whether sg chain is supported. So, SMC-R's rmb buffer should be limited by SG_MAX_SINGLE_ALLOC only when the macro CONFIG_ARCH_NO_SG_CHAIN is defined. Fixes: a3fe3d01 ("net/smc: introduce sg-logic for RMBs") Signed-off-by:
-
- 01 Jun, 2024 1 commit
-
-
Kuniyuki Iwashima authored
When splice() support was added in commit 2b514574 ("net: af_unix: implement splice for stream af_unix sockets"), we had to release unix_sk(sk)->readlock (current iolock) before calling splice_to_pipe(). Due to the unlock, commit 73ed5d25 ("af-unix: fix use-after-free with concurrent readers while splicing") added a safeguard in unix_stream_read_generic(); we had to bump the skb refcount before calling ->recv_actor() and then check if the skb was consumed by a concurrent reader. However, the pipe side locking was refactored, and since commit 25869262 ("skb_splice_bits(): get rid of callback"), we can call splice_to_pipe() without releasing unix_sk(sk)->iolock. Now, the skb is always alive after the ->recv_actor() callback, so let's remove the unnecessary drop_skb logic. This is mostly the revert of commit 73ed5d25 ("af-unix: fix use-after-free with concurrent readers while splicing"). Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://lore.kernel.org/r/20240529144648.68591-1-kuniyu@amazon.comSigned-off-by:
-
