[PATCH net-next v9 5/7] mptcp: support rstreason for passive reset

2024-04-24 Thread Jason Xing
From: Jason Xing It relies on what reset options in the skb are as rfc8684 says. Reusing this logic can save us much energy. This patch replaces most of the prior NOT_SPECIFIED reasons. Signed-off-by: Jason Xing Reviewed-by: Matthieu Baerts (NGI0) --- net/mptcp/protocol.h | 27

[PATCH net-next v9 6/7] mptcp: introducing a helper into active reset logic

2024-04-24 Thread Jason Xing
From: Jason Xing Since we have mapped every mptcp reset reason definition in enum sk_rst_reason, introducing a new helper can cover some missing places where we have already set the subflow->reset_reason. Note: using SK_RST_REASON_NOT_SPECIFIED is the same as SK_RST_REASON_MPTCP_RST_EUNSPEC.

[PATCH net-next v9 7/7] rstreason: make it work in trace world

2024-04-24 Thread Jason Xing
From: Jason Xing At last, we should let it work by introducing this reset reason in trace world. One of the possible expected outputs is: ... tcp_send_reset: skbaddr=xxx skaddr=xxx src=xxx dest=xxx state=TCP_ESTABLISHED reason=NOT_SPECIFIED Signed-off-by: Jason Xing Reviewed-by: Steven

[PATCH 1/2] objpool: enable inlining objpool_push() and objpool_pop() operations

2024-04-24 Thread Andrii Nakryiko
objpool_push() and objpool_pop() are very performance-critical functions and can be called very frequently in kretprobe triggering path. As such, it makes sense to allow compiler to inline them completely to eliminate function calls overhead. Luckily, their logic is quite well isolated and

[PATCH 2/2] objpool: cache nr_possible_cpus() and avoid caching nr_cpu_ids

2024-04-24 Thread Andrii Nakryiko
Profiling shows that calling nr_possible_cpus() in objpool_pop() takes a noticeable amount of CPU (when profiled on 80-core machine), as we need to recalculate number of set bits in a CPU bit mask. This number can't change, so there is no point in paying the price for recalculating it. As such,

[PATCH 0/2] Objpool performance improvements

2024-04-24 Thread Andrii Nakryiko
Improve objpool (used heavily in kretprobe hot path) performance with two improvements: - inlining performance critical objpool_push()/objpool_pop() operations; - avoiding re-calculating relatively expensive nr_possible_cpus(). These opportunities were found when benchmarking and profiling

[PATCH 5.15,5.10,5.4,4.19 0/2] Fix warning when tracing with large filenames

2024-04-24 Thread Thadeu Lima de Souza Cascardo
The warning described on patch "tracing: Increase PERF_MAX_TRACE_SIZE to handle Sentinel1 and docker together" can be triggered with a perf probe on do_execve with a large path. As PATH_MAX is larger than PERF_MAX_TRACE_SIZE (2048 before the patch), the warning will trigger. The fix was included

[PATCH 5.15,5.10,5.4,4.19 1/2] tracing: Show size of requested perf buffer

2024-04-24 Thread Thadeu Lima de Souza Cascardo
From: "Robin H. Johnson" commit a90afe8d020da9298c98fddb19b7a6372e2feb45 upstream. If the perf buffer isn't large enough, provide a hint about how large it needs to be for whatever is running. Link: https://lkml.kernel.org/r/20210831043723.13481-1-robb...@gentoo.org Signed-off-by: Robin H.

[PATCH 5.15,5.10 2/2] tracing: Increase PERF_MAX_TRACE_SIZE to handle Sentinel1 and docker together

2024-04-24 Thread Thadeu Lima de Souza Cascardo
From: "Robin H. Johnson" commit e531e90b5ab0f7ce5ff298e165214c1aec6ed187 upstream. Running endpoint security solutions like Sentinel1 that use perf-based tracing heavily lead to this repeated dump complaining about dockerd. The default value of 2048 is nowhere near not large enough. Using the

[PATCH 5.4,4.19 2/2] tracing: Increase PERF_MAX_TRACE_SIZE to handle Sentinel1 and docker together

2024-04-24 Thread Thadeu Lima de Souza Cascardo
From: "Robin H. Johnson" commit e531e90b5ab0f7ce5ff298e165214c1aec6ed187 upstream. Running endpoint security solutions like Sentinel1 that use perf-based tracing heavily lead to this repeated dump complaining about dockerd. The default value of 2048 is nowhere near not large enough. Using the

[PATCH net-next v9 2/7] rstreason: prepare for passive reset

2024-04-24 Thread Jason Xing
From: Jason Xing Adjust the parameter and support passing reason of reset which is for now NOT_SPECIFIED. No functional changes. Signed-off-by: Jason Xing Acked-by: Matthieu Baerts (NGI0) --- include/net/request_sock.h | 4 +++- net/dccp/ipv4.c| 10 ++ net/dccp/ipv6.c

[PATCH net-next v9 3/7] rstreason: prepare for active reset

2024-04-24 Thread Jason Xing
From: Jason Xing Like what we did to passive reset: only passing possible reset reason in each active reset path. No functional changes. Signed-off-by: Jason Xing Acked-by: Matthieu Baerts (NGI0) --- include/net/tcp.h | 3 ++- net/ipv4/tcp.c| 15 ++-

[PATCH net-next v9 0/7] Implement reset reason mechanism to detect

2024-04-24 Thread Jason Xing
From: Jason Xing In production, there are so many cases about why the RST skb is sent but we don't have a very convenient/fast method to detect the exact underlying reasons. RST is implemented in two kinds: passive kind (like tcp_v4_send_reset()) and active kind (like tcp_send_active_reset()).

[PATCH net-next v9 1/7] net: introduce rstreason to detect why the RST is sent

2024-04-24 Thread Jason Xing
From: Jason Xing Add a new standalone file for the easy future extension to support both active reset and passive reset in the TCP/DCCP/MPTCP protocols. This patch only does the preparations for reset reason mechanism, nothing else changes. The reset reasons are divided into three parts: 1)

[PATCH net-next v9 4/7] tcp: support rstreason for passive reset

2024-04-24 Thread Jason Xing
From: Jason Xing Reuse the dropreason logic to show the exact reason of tcp reset, so we can finally display the corresponding item in enum sk_reset_reason instead of reinventing new reset reasons. This patch replaces all the prior NOT_SPECIFIED reasons. Signed-off-by: Jason Xing ---

[PATCH RFC] rethook: inline arch_rethook_trampoline_callback() in assembly code

2024-04-24 Thread Andrii Nakryiko
At the lowest level, rethook-based kretprobes on x86-64 architecture go through arch_rethoook_trampoline() function, manually written in assembly, which calls into a simple arch_rethook_trampoline_callback() function, written in C, and only doing a few straightforward field assignments, before