- 23 Feb, 2022 13 commits
-
-
Vladimir Oltean authored
The logic from switchdev_handle_port_obj_add_foreign() is directly adapted from switchdev_handle_fdb_event_to_device(), which already detects events on foreign interfaces and reoffloads them towards the switchdev neighbors. However, when we have a simple br0 <-> bond0 <-> swp0 topology and the switchdev_handle_port_obj_add_foreign() gets called on bond0, we get stuck into an infinite recursion: 1. bond0 does not pass check_cb(), so we attempt to find switchdev neighbor interfaces. For that, we recursively call __switchdev_handle_port_obj_add() for bond0's bridge, br0. 2. __switchdev_handle_port_obj_add() recurses through br0's lowers, essentially calling __switchdev_handle_port_obj_add() for bond0 3. Go to step 1. This happens because switchdev_handle_fdb_event_to_device() and switchdev_handle_port_obj_add_foreign() are not exactly the same. The FDB event helper special-cases LAG interfaces with its lag_mod_cb(), so this is why we don't end up in an infinite loop - because it doesn't attempt to treat LAG interfaces as potentially foreign bridge ports. The problem is solved by looking ahead through the bridge's lowers to see whether there is any switchdev interface that is foreign to the @dev we are currently processing. This stops the recursion described above at step 1: __switchdev_handle_port_obj_add(bond0) will not create another call to __switchdev_handle_port_obj_add(br0). Going one step upper should only happen when we're starting from a bridge port that has been determined to be "foreign" to the switchdev driver that passes the foreign_dev_check_cb(). Fixes: c4076cdd ("net: switchdev: introduce switchdev_handle_port_obj_{add,del} for foreign interfaces") Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Shannon Nelson authored
The ever-vigilant Linux kernel test robot reminded us that we need to use the correct include files to be sure that all the build variations will work correctly. Adding the vmalloc.h include takes care of declaring our use of vzalloc() and vfree(). drivers/net/ethernet/pensando/ionic/ionic_lif.c:396:17: error: implicit declaration of function 'vfree'; did you mean 'kvfree'? drivers/net/ethernet/pensando/ionic/ionic_lif.c:531:21: warning: assignment to 'struct ionic_desc_info *' from 'int' makes pointer from integer without a cast Fixes: 116dce0f ("ionic: Use vzalloc for large per-queue related buffers") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Shannon Nelson <snelson@pensando.io> Link: https://lore.kernel.org/r/20220223015731.22025-1-snelson@pensando.ioSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Eric Dumazet says: ==================== tcp: take care of another syzbot issue This is a minor issue: It took months for syzbot to find a C repro, and even with it, I had to spend a lot of time to understand KFENCE was a prereq. With the default kfence 500ms interval, I had to be very patient to trigger the kernel warning and perform my analysis. This series targets net-next tree, because I added a new generic helper in the first patch, then fixed the issue in the second one. They can be backported once proven solid. ==================== Link: https://lore.kernel.org/r/20220222032113.4005821-1-eric.dumazet@gmail.comSigned-off-by:
-
Eric Dumazet authored
syzbot found another way to trigger the infamous WARN_ON_ONCE(delta < len) in skb_try_coalesce() [1] I was able to root cause the issue to kfence. When kfence is in action, the following assertion is no longer true: int size = xxxx; void *ptr1 = kmalloc(size, gfp); void *ptr2 = kmalloc(size, gfp); if (ptr1 && ptr2) ASSERT(ksize(ptr1) == ksize(ptr2)); We attempted to fix these issues in the blamed commits, but forgot that TCP was possibly shifting data after skb_unclone_keeptruesize() has been used, notably from tcp_retrans_try_collapse(). So we not only need to keep same skb->truesize value, we also need to make sure TCP wont fill new tailroom that pskb_expand_head() was able to get from a addr = kmalloc(...) followed by ksize(addr) Split skb_unclone_keeptruesize() into two parts: 1) Inline skb_unclone_keeptruesize() for the common case, when skb is not cloned. 2) Out of line __skb_unclone_keeptruesize() for the 'slow path'. WARNING: CPU: 1 PID: 6490 at net/core/skbuff.c:5295 skb_try_coalesce+0x1235/0x1560 net/core/skbuff.c:5295 Modules linked in: CPU: 1 PID: 6490 Comm: syz-executor161 Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:skb_try_coalesce+0x1235/0x1560 net/core/skbuff.c:5295 Code: bf 01 00 00 00 0f b7 c0 89 c6 89 44 24 20 e8 62 24 4e fa 8b 44 24 20 83 e8 01 0f 85 e5 f0 ff ff e9 87 f4 ff ff e8 cb 20 4e fa <0f> 0b e9 06 f9 ff ff e8 af b2 95 fa e9 69 f0 ff ff e8 95 b2 95 fa RSP: 0018:ffffc900063af268 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 00000000ffffffd5 RCX: 0000000000000000 RDX: ffff88806fc05700 RSI: ffffffff872abd55 RDI: 0000000000000003 RBP: ffff88806e675500 R08: 00000000ffffffd5 R09: 0000000000000000 R10: ffffffff872ab659 R11: 0000000000000000 R12: ffff88806dd554e8 R13: ffff88806dd9bac0 R14: ffff88806dd9a2c0 R15: 0000000000000155 FS: 00007f18014f9700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002000 CR3: 000000006be7a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tcp_try_coalesce net/ipv4/tcp_input.c:4651 [inline] tcp_try_coalesce+0x393/0x920 net/ipv4/tcp_input.c:4630 tcp_queue_rcv+0x8a/0x6e0 net/ipv4/tcp_input.c:4914 tcp_data_queue+0x11fd/0x4bb0 net/ipv4/tcp_input.c:5025 tcp_rcv_established+0x81e/0x1ff0 net/ipv4/tcp_input.c:5947 tcp_v4_do_rcv+0x65e/0x980 net/ipv4/tcp_ipv4.c:1719 sk_backlog_rcv include/net/sock.h:1037 [inline] __release_sock+0x134/0x3b0 net/core/sock.c:2779 release_sock+0x54/0x1b0 net/core/sock.c:3311 sk_wait_data+0x177/0x450 net/core/sock.c:2821 tcp_recvmsg_locked+0xe28/0x1fd0 net/ipv4/tcp.c:2457 tcp_recvmsg+0x137/0x610 net/ipv4/tcp.c:2572 inet_recvmsg+0x11b/0x5e0 net/ipv4/af_inet.c:850 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] sock_recvmsg net/socket.c:962 [inline] ____sys_recvmsg+0x2c4/0x600 net/socket.c:2632 ___sys_recvmsg+0x127/0x200 net/socket.c:2674 __sys_recvmsg+0xe2/0x1a0 net/socket.c:2704 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: c4777efa ("net: add and use skb_unclone_keeptruesize() helper") Fixes: 097b9146 ("net: fix up truesize of cloned skb in skb_prepare_for_shift()") Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Marco Elver <elver@google.com> Signed-off-by:
-
Eric Dumazet authored
We have multiple places where this helper is convenient, and plan using it in the following patch. Signed-off-by:
-
Eric Dumazet authored
All other skbs allocated for TCP tx are using MAX_TCP_HEADER already. MAX_HEADER can be too small for some cases (like eBPF based encapsulation), so this can avoid extra pskb_expand_head() in lower stacks. Signed-off-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20220222031115.4005060-1-eric.dumazet@gmail.comSigned-off-by:
-
Maciek Machnikowski authored
Add option to shift the clock by a specified number of nanoseconds. The new argument -n will specify the number of nanoseconds to add to the ptp clock. Since the API doesn't support negative shifts those needs to be calculated by subtracting full seconds and adding a nanosecond offset. Signed-off-by:
Maciek Machnikowski <maciek@machnikowski.net> Acked-by:
Richard Cochran <richardcochran@gmail.com> Link: https://lore.kernel.org/r/20220221200637.125595-1-maciek@machnikowski.netSigned-off-by:
-
Gustavo A. R. Silva authored
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). This issue was found with the help of Coccinelle and audited and fixed, manually. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/79Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20220221173415.GA1149599@embeddedorSigned-off-by:
-
Russell King (Oracle) authored
Vladimir Oltean reports that probing on DSA drivers that aren't yet populating supported_interfaces now fails. Fix this by allowing phylink to detect whether DSA actually provides an underlying mac_select_pcs() implementation. Reported-by:
Vladimir Oltean <olteanv@gmail.com> Fixes: bde01822 ("net: dsa: add support for phylink mac_select_pcs()") Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Tested-by:
-
Oleksij Rempel authored
30 seconds is too long interval especially if it used with ip -s l. Reduce polling interval to 5 sec. Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20220221084129.3660124-1-o.rempel@pengutronix.deSigned-off-by:
-
Jakub Kicinski authored
Alexandra Winter says: ==================== s390/net: updates 2022-02-21 Just cleanup. No functional changes, as currently virt=phys in s390. ==================== Link: https://lore.kernel.org/r/20220221145633.3869621-1-wintera@linux.ibm.comSigned-off-by:
-
Alexander Gordeev authored
Fix virtual vs physical address confusion (which currently are the same). Reviewed-by:
Alexandra Winter <wintera@linux.ibm.com> Reviewed-by:
Wenjia Zhang <wenjia@linux.ibm.com> Signed-off-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
-
Alexander Gordeev authored
Fix virtual vs physical address confusion (which currently are the same). Reviewed-by:
-
- 22 Feb, 2022 9 commits
-
-
Eric Dumazet authored
Another thing making netns dismantles potentially very slow is located in gro_cells_destroy(), whenever cleanup_net() has to remove a device using gro_cells framework. RTNL is not held at this stage, so synchronize_net() is calling synchronize_rcu(): netdev_run_todo() ip_tunnel_dev_free() gro_cells_destroy() synchronize_net() synchronize_rcu() // Ouch. This patch uses call_rcu(), and gave me a 25x performance improvement in my tests. cleanup_net() is no longer blocked ~10 ms per synchronize_rcu() call. In the case we could not allocate the memory needed to queue the deferred free, use synchronize_rcu_expedited() v2: made percpu_free_defer_callback() static Signed-off-by:Paolo Abeni <pabeni@redhat.com> Link: https://lore.kernel.org/r/20220220041155.607637-1-eric.dumazet@gmail.comSigned-off-by:
-
David S. Miller authored
Russell King says: ==================== net: dsa: b53: convert to phylink_generic_validate() and mark as non-legacy This series converts b53 to use phylink_generic_validate() and also marks this driver as non-legacy. Patch 1 cleans up an if() condition to be more readable before we proceed with the conversion. Patch 2 populates the supported_interfaces and mac_capabilities members of phylink_config. Patch 3 drops the use of phylink_helper_basex_speed() which is now not necessary. Patch 4 switches the driver to use phylink_generic_validate() Patch 5 marks the driver as non-legacy. ==================== Signed-off-by: -
Russell King (Oracle) authored
The B53 driver does not make use of the speed, duplex, pause or advertisement in its phylink_mac_config() implementation, so it can be marked as a non-legacy driver. Signed-off-by:
-
Russell King (Oracle) authored
Switch the Broadcom b53 driver to using the phylink_generic_validate() implementation by removing its own .phylink_validate method and associated code. Signed-off-by:
-
Russell King (Oracle) authored
Now that we have a better method to select SFP interface modes, we no longer need to use phylink_helper_basex_speed() in a driver's validation function. Signed-off-by:
-
Russell King (Oracle) authored
Populate the supported interfaces and MAC capabilities for the Broadcom B53 DSA switches in preparation to using these for the generic validation functionality. The interface modes are derived from: - b53_serdes_phylink_validate() - SRAB mux configuration Signed-off-by:
-
Russell King (Oracle) authored
I've stared at this if() statement for a while trying to work out if it really does correspond with the comment above, and it does seem to. However, let's make it more readable and phrase it in the same way as the comment. Also add a FIXME into the comment - we appear to deny Gigabit modes for 802.3z interface modes, but 802.3z interface modes only operate at gigabit and above. Reviewed-by:
-
Dan Carpenter authored
This code dereferences "skb" after calling dev_kfree_skb(). Fixes: 2dc95a4d ("net: Add dm9051 driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20220221105440.GA10045@kiliSigned-off-by:
-
Juhee Kang authored
In hsr, lockdep_is_held() is needed for rcu_dereference_bh_check(). But if lockdep is not enabled, lockdep_is_held() causes a build error: ERROR: modpost: "lockdep_is_held" [net/hsr/hsr.ko] undefined! Thus, this patch solved by adding lockdep_hsr_is_held(). This helper function calls the lockdep_is_held() when lockdep is enabled, and returns 1 if not defined. Fixes: e7f27420 ("net: hsr: fix suspicious RCU usage warning in hsr_node_get_first()") Reported-by:Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
Juhee Kang <claudiajkang@gmail.com> Link: https://lore.kernel.org/r/20220220153250.5285-1-claudiajkang@gmail.comSigned-off-by:
-
- 21 Feb, 2022 15 commits
-
-
David S. Miller authored
Rakesh Babu Saladi says: ==================== RVU AF and NETDEV drivers' PTP updates. Patch 1: Add suppot such that RVU drivers support new timestamp format. Patch 2: This patch adds workaround for PTP errata. Changes made from v1 to v2 1. CC'd Richard Cochran to review PTP related patches. 2. Removed a patch from the old patch series. Will submit the removed patch separately. ==================== Signed-off-by: -
Naveen Mamindlapalli authored
This patch adds workaround for PTP errata given below. 1. At the time of 1 sec rollover of nano-second counter, the nano-second counter is set to 0. However, it should be set to (existing counter_value - 10^9). This leads to an accumulating error in the timestamp value with each sec rollover. 2. Additionally, the nano-second counter currently is rolling over at 'h3B9A_C9FF. It should roll over at 'h3B9A_CA00. The workaround for issue #1 is to speed up the ptp clock by adjusting PTP_CLOCK_COMP register to the desired value to compensate for the nanoseconds lost per each second. The workaround for issue #2 is to slow down the ptp clock such that the rollover occurs at ~1sec. Signed-off-by:
Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by:
Sunil Kovvuri Goutham <sgoutham@marvell.com> Signed-off-by:
Rakesh Babu Saladi <rsaladi2@marvell.com> Signed-off-by:
-
Naveen Mamindlapalli authored
The cn10k hardware ptp timestamp format has been modified primarily to support 1-step ptp clock. The 64-bit timestamp used by hardware is split into two 32-bit fields, the upper one holds seconds, the lower one nanoseconds. A new register (PTP_CLOCK_SEC) has been added that returns the current seconds value. The nanoseconds register PTP_CLOCK_HI resets after every second. The cn10k RPM block provides Rx/Tx timestamps to the NIX block using the new timestamp format. The software can read the current timestamp in nanoseconds by reading both PTP_CLOCK_SEC & PTP_CLOCK_HI registers. This patch provides support for new timestamp format. Signed-off-by:
-
David S. Miller authored
Hangbin Liu says: ==================== bonding: add IPv6 NS/NA monitor support This patch add bond IPv6 NS/NA monitor support. A new option ns_ip6_target is added, which is similar with arp_ip_target. The IPv6 NS/NA monitor will take effect when there is a valid IPv6 address. Both ARP monitor and NS monitor will working at the same time. A new extra storage field is added to struct bond_opt_value for IPv6 support. Function bond_handle_vlan() is split from bond_arp_send() for both IPv4/IPv6 usage. To alloc NS message and send out. ndisc_ns_create() and ndisc_send_skb() are exported. v1 -> v2: 1. remove sysfs entry[1] and only keep netlink support. RFC -> v1: 1. define BOND_MAX_ND_TARGETS as BOND_MAX_ARP_TARGETS 2. adjust for reverse xmas tree ordering of local variables 3. remove bond_do_ns_validate() 4. add extra field for bond_opt_value 5. set IS_ENABLED(CONFIG_IPV6) for IPv6 codes [1] https://lore.kernel.org/netdev/8863.1645071997@famine ==================== Signed-off-by:
-
Hangbin Liu authored
This patch add a new bonding option ns_ip6_target, which correspond to the arp_ip_target. With this we set IPv6 targets and send IPv6 NS request to determine the health of the link. For other related options like the validation, we still use arp_validate, and will change to ns_validate later. Note: the sysfs configuration support was removed based on https://lore.kernel.org/netdev/8863.1645071997@famineSigned-off-by:
Hangbin Liu <liuhangbin@gmail.com> Signed-off-by:
-
Hangbin Liu authored
Add a new bonding parameter ns_targets to store IPv6 address. Add required bond_ns_send/rcv functions first before adding IPv6 address option setting. Add two functions bond_send/rcv_validate so we can send/recv ARP and NS at the same time. Signed-off-by:
-
Hangbin Liu authored
Adding an extra storage field for bond_opt_value so we can set large bytes of data for bonding options in future, e.g. IPv6 address. Define a new call bond_opt_initextra(). Also change the checking order of __bond_opt_init() and check values first. Signed-off-by:
-
Hangbin Liu authored
Function bond_handle_vlan() is split from bond_arp_send() for later IPv6 usage. Signed-off-by:
-
Hangbin Liu authored
This patch separate NS message allocation steps from ndisc_send_ns(), so it could be used in other places, like bonding, to allocate and send IPv6 NS message. Also export ndisc_send_skb() and ndisc_ns_create() for later bonding usage. Signed-off-by:
-
Christophe JAILLET authored
'max_rx_len' can be up to GBETH_RX_BUFF_MAX (i.e. 8192) (see 'gbeth_hw_info'). The default value of 'num_rx_ring' can be BE_RX_RING_SIZE (i.e. 1024). So this loop can allocate 8 Mo of memory. Previous memory allocations in this function already use GFP_KERNEL, so use __netdev_alloc_skb() and an explicit GFP_KERNEL instead of a implicit GFP_ATOMIC. This gives more opportunities of successful allocation. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Reviewed-by:
Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by:
-
Christophe JAILLET authored
Use skb_put_zero() instead of hand-writing it. This saves a few lines of code and is more readable. Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== ipv4: Invalidate neighbour for broadcast address upon address addition Patch #1 solves a recently reported issue [1]. See detailed description in the changelog. Patch #2 adds a matching test case. Targeting at net-next since as far as I can tell this use case never worked. There are no regressions in fib_tests.sh with this change: # ./fib_tests.sh ... Tests passed: 186 Tests failed: 0 [1] https://lore.kernel.org/netdev/55a04a8f-56f3-f73c-2aea-2195923f09d1@huawei.com/ ==================== Signed-off-by:
-
Ido Schimmel authored
Test that resolved neighbours for IPv4 broadcast addresses are unaffected by the configuration of matching broadcast routes, whereas unresolved neighbours are invalidated. Without previous patch: # ./fib_tests.sh -t ipv4_bcast_neigh IPv4 broadcast neighbour tests TEST: Resolved neighbour for broadcast address [ OK ] TEST: Resolved neighbour for network broadcast address [ OK ] TEST: Unresolved neighbour for broadcast address [FAIL] TEST: Unresolved neighbour for network broadcast address [FAIL] Tests passed: 2 Tests failed: 2 With previous patch: # ./fib_tests.sh -t ipv4_bcast_neigh IPv4 broadcast neighbour tests TEST: Resolved neighbour for broadcast address [ OK ] TEST: Resolved neighbour for network broadcast address [ OK ] TEST: Unresolved neighbour for broadcast address [ OK ] TEST: Unresolved neighbour for network broadcast address [ OK ] Tests passed: 4 Tests failed: 0 Signed-off-by:Ido Schimmel <idosch@nvidia.com> Signed-off-by:
-
Ido Schimmel authored
In case user space sends a packet destined to a broadcast address when a matching broadcast route is not configured, the kernel will create a unicast neighbour entry that will never be resolved [1]. When the broadcast route is configured, the unicast neighbour entry will not be invalidated and continue to linger, resulting in packets being dropped. Solve this by invalidating unresolved neighbour entries for broadcast addresses after routes for these addresses are internally configured by the kernel. This allows the kernel to create a broadcast neighbour entry following the next route lookup. Another possible solution that is more generic but also more complex is to have the ARP code register a listener to the FIB notification chain and invalidate matching neighbour entries upon the addition of broadcast routes. It is also possible to wave off the issue as a user space problem, but it seems a bit excessive to expect user space to be that intimately familiar with the inner workings of the FIB/neighbour kernel code. [1] https://lore.kernel.org/netdev/55a04a8f-56f3-f73c-2aea-2195923f09d1@huawei.com/Reported-by:
Wang Hai <wanghai38@huawei.com> Signed-off-by:
-
Christophe Leroy authored
Open coded calculation can be avoided and replaced by the equivalent csum_replace_by_diff() and csum_sub(). Signed-off-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by:
-
- 20 Feb, 2022 3 commits
-
-
David S. Miller authored
Menglong Dong says: ==================== net: add skb drop reasons to TCP packet receive In the commit c504e5c2 ("net: skb: introduce kfree_skb_reason()"), we added the support of reporting the reasons of skb drops to kfree_skb tracepoint. And in this series patches, reasons for skb drops are added to TCP layer (both TCPv4 and TCPv6 are considered). Following functions are processed: tcp_v4_rcv() tcp_v6_rcv() tcp_v4_inbound_md5_hash() tcp_v6_inbound_md5_hash() tcp_add_backlog() tcp_v4_do_rcv() tcp_v6_do_rcv() tcp_rcv_established() tcp_data_queue() tcp_data_queue_ofo() The functions we handled are mostly for packet ingress, as skb drops hardly happens in the egress path of TCP layer. However, it's a little complex for TCP state processing, as I find that it's hard to report skb drop reasons to where it is freed. For example, when skb is dropped in tcp_rcv_state_process(), the reason can be caused by the call of tcp_v4_conn_request(), and it's hard to return a drop reason from tcp_v4_conn_request(). So such cases are skipped for this moment. Following new drop reasons are introduced (what they mean can be see in the document for them): /* SKB_DROP_REASON_TCP_MD5* corresponding to LINUX_MIB_TCPMD5* */ SKB_DROP_REASON_TCP_MD5NOTFOUND SKB_DROP_REASON_TCP_MD5UNEXPECTED SKB_DROP_REASON_TCP_MD5FAILURE SKB_DROP_REASON_SOCKET_BACKLOG SKB_DROP_REASON_TCP_FLAGS SKB_DROP_REASON_TCP_ZEROWINDOW SKB_DROP_REASON_TCP_OLD_DATA SKB_DROP_REASON_TCP_OVERWINDOW /* corresponding to LINUX_MIB_TCPOFOMERGE */ SKB_DROP_REASON_TCP_OFOMERGE Here is a example to get TCP packet drop reasons from ftrace: $ echo 1 > /sys/kernel/debug/tracing/events/skb/kfree_skb/enable $ cat /sys/kernel/debug/tracing/trace $ <idle>-0 [036] ..s1. 647.428165: kfree_skb: skbaddr=000000004d037db6 protocol=2048 location=0000000074cd1243 reason: NO_SOCKET $ <idle>-0 [020] ..s2. 639.676674: kfree_skb: skbaddr=00000000bcbfa42d protocol=2048 location=00000000bfe89d35 reason: PROTO_MEM From the reason 'PROTO_MEM' we can know that the skb is dropped because the memory configured in net.ipv4.tcp_mem is up to the limition. Changes since v2: - remove the 'inline' of tcp_drop() in the 1th patch, as Jakub suggested Changes since v1: - enrich the document for this series patches in the cover letter, as Eric suggested - fix compile warning report by Jakub in the 6th patch - let NO_SOCKET trump the XFRM failure in the 2th and 3th patches ==================== Signed-off-by:
-
Menglong Dong authored
Replace tcp_drop() used in tcp_data_queue_ofo with tcp_drop_reason(). Following drop reasons are introduced: SKB_DROP_REASON_TCP_OFOMERGE Reviewed-by:
Mengen Sun <mengensun@tencent.com> Reviewed-by:
Hao Peng <flyingpeng@tencent.com> Signed-off-by:
Menglong Dong <imagedong@tencent.com> Reviewed-by:
-
Menglong Dong authored
Replace tcp_drop() used in tcp_data_queue() with tcp_drop_reason(). Following drop reasons are introduced: SKB_DROP_REASON_TCP_ZEROWINDOW SKB_DROP_REASON_TCP_OLD_DATA SKB_DROP_REASON_TCP_OVERWINDOW SKB_DROP_REASON_TCP_OLD_DATA is used for the case that end_seq of skb less than the left edges of receive window. (Maybe there is a better name?) Reviewed-by:
-
