From 03184ccb3014dfea45058af7e077d090534ca975 Mon Sep 17 00:00:00 2001 From: Dom Delnano Date: Tue, 19 Nov 2024 09:23:49 -0800 Subject: [PATCH] Allow newer kernels to opt into explicit loop and chunk limit overrides (#2047) Summary: Allow newer kernels to opt into explicit loop and chunk limit overrides Overwriting non default values of the bpf chunk and loop limit is frustrating since it undoes configuration a user explicitly requested. This also will allow for working around #2042, which causes kernels 6.10 and later to fail to start the socket tracer. In addition to this, I tweaked the kernel upgrade logic slightly. The previous logic would have upgraded a 5.0.x kernel to use the new loop limit when the 1M instruction limit isn't available until 5.1. Relevant Issues: Helps to work around #2042 Type of change: /kind bugfix Test Plan: Verified the following on a 6.x kernel running `stirling_wrapper` - [x] Not supplying any arguments results in using an increased loop and chunk limit ``` $ sudo ./bazel-bin/src/stirling/binaries/stirling_wrapper I20241118 05:52:37.358364 3104175 socket_trace_connector.cc:474] Kernel version greater than V5.1 detected (6.8.12), raised loop limit to 882 and chunk limit to 84 ``` - [x] Supplying the loop limit or chunk limit flag disables the automatic increase ``` $ sudo ./bazel-bin/src/stirling/binaries/stirling_wrapper --stirling_bpf_loop_limit=41 I20241118 05:53:21.082810 3104197 source_connector.cc:35] Initializing source connector: socket_tracer I20241118 05:53:21.082886 3104197 kernel_version.cc:82] Obtained Linux version string from `uname`: 6.8.0-1015-gcp I20241118 05:53:21.082916 3104197 linux_headers.cc:395] Detected kernel release (uname -r): 6.8.0-1015-gcp I20241118 05:53:21.082964 3104197 linux_headers.cc:206] Using Linux headers from: /lib/modules/6.8.0-1015-gcp/build. I20241118 05:53:21.083058 3104197 bcc_wrapper.cc:166] Initializing BPF program ... ``` Changelog Message: Ensures that the `--stirling_bpf_loop_limit` and `--stirling_bpf_chunk_limit` values are respected if explicitly provided on the command line. For 5.1 and later kernels, cli provided values would have been ignored --------- Signed-off-by: Dom Del Nano --- .../socket_tracer/socket_trace_connector.cc | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/src/stirling/source_connectors/socket_tracer/socket_trace_connector.cc b/src/stirling/source_connectors/socket_tracer/socket_trace_connector.cc index fd345a8d487..5e18e70d504 100644 --- a/src/stirling/source_connectors/socket_tracer/socket_trace_connector.cc +++ b/src/stirling/source_connectors/socket_tracer/socket_trace_connector.cc @@ -460,7 +460,14 @@ auto SocketTraceConnector::InitPerfBufferSpecs() { Status SocketTraceConnector::InitBPF() { // set BPF loop limit and chunk limit based on kernel version auto kernel = system::GetCachedKernelVersion(); - if (kernel.version >= 5 || (kernel.version == 5 && kernel.major_rev >= 1)) { + auto loop_limit_is_default = + gflags::GetCommandLineFlagInfoOrDie("stirling_bpf_loop_limit").is_default; + auto chunk_limit_is_default = + gflags::GetCommandLineFlagInfoOrDie("stirling_bpf_chunk_limit").is_default; + + // Do not automatically raise loop and chunk limits for non-default values. + if (loop_limit_is_default && chunk_limit_is_default && + (kernel.version > 5 || (kernel.version == 5 && kernel.major_rev >= 1))) { // Kernels >= 5.1 have higher BPF instruction limits (1 million for verifier). // This enables a 21x increase to our loop and chunk limits FLAGS_stirling_bpf_loop_limit = 882;