Changes in settings

7155cc45 - selftests/seccomp: Try to fit runtime of benchmark into timeout

Mon, 25 Mar 2024 16:57:59 +0000

selftests/seccomp: Try to fit runtime of benchmark into timeoutThe seccomp benchmark runs five scenarios, one calibration run with noseccomp filters enabled then four further runs each adding a filter. Thecalibration run times itself for 15s and then each additional run executesfor the same number of times.Currently the seccomp tests, including the benchmark, run with an extended120s timeout but this is not sufficient to robustly run the tests on a lotof platforms. Sample timings from some recent runs: Platform Run 1 Run 2 Run 3 Run 4 --------- ----- ----- ----- ----- PowerEdge R200 16.6s 16.6s 31.6s 37.4s BBB (arm) 20.4s 20.4s 54.5s Synquacer (arm64) 20.7s 23.7s 40.3sThe x86 runs from the PowerEdge are quite marginal and routinely fail, forthe successful run reported here the timed portions of the run are at117.2s leaving less than 3s of margin which is frequently breached. Theadded overhead of adding filters on the other platforms is such that thereis no prospect of their runs fitting into the 120s timeout, especiallyon 32 bit arm where there is no BPF JIT.While we could lower the time we calibrate for I'm also already seeing thecurrently completing runs reporting issues with the per filter overheadsnot matching expectations:Let's instead raise the timeout to 180s which is only a 50% increase on thecurrent timeout which is itself not *too* large given that there's only twotests in this suite.Signed-off-by: Mark Brown Signed-off-by: Shuah Khan List of files: /linux-6.15/tools/testing/selftests/seccomp/settings

192cf322 - selftests/seccomp: Compare bitmap vs filter overhead

Sun, 11 Oct 2020 15:47:45 +0000

selftests/seccomp: Compare bitmap vs filter overheadAs part of the seccomp benchmarking, include the expectations withregard to the timing behavior of the constant action bitmaps, and reportinconsistencies better.Example output with constant action bitmaps on x86:$ sudo ./seccomp_benchmark 100000000Current BPF sysctl settings:net.core.bpf_jit_enable = 1net.core.bpf_jit_harden = 0Benchmarking 200000000 syscalls...129.359381409 - 0.008724424 = 129350656985 (129.4s)getpid native: 646 ns264.385890006 - 129.360453229 = 135025436777 (135.0s)getpid RET_ALLOW 1 filter (bitmap): 675 ns399.400511893 - 264.387045901 = 135013465992 (135.0s)getpid RET_ALLOW 2 filters (bitmap): 675 ns545.872866260 - 399.401718327 = 146471147933 (146.5s)getpid RET_ALLOW 3 filters (full): 732 ns696.337101319 - 545.874097681 = 150463003638 (150.5s)getpid RET_ALLOW 4 filters (full): 752 nsEstimated total seccomp overhead for 1 bitmapped filter: 29 nsEstimated total seccomp overhead for 2 bitmapped filters: 29 nsEstimated total seccomp overhead for 3 full filters: 86 nsEstimated total seccomp overhead for 4 full filters: 106 nsEstimated seccomp entry overhead: 29 nsEstimated seccomp per-filter overhead (last 2 diff): 20 nsEstimated seccomp per-filter overhead (filters / 4): 19 nsExpectations: native ≤ 1 bitmap (646 ≤ 675): ✔️ native ≤ 1 filter (646 ≤ 732): ✔️ per-filter (last 2 diff) ≈ per-filter (filters / 4) (20 ≈ 19): ✔️ 1 bitmapped ≈ 2 bitmapped (29 ≈ 29): ✔️ entry ≈ 1 bitmapped (29 ≈ 29): ✔️ entry ≈ 2 bitmapped (29 ≈ 29): ✔️ native + entry + (per filter * 4) ≈ 4 filters total (755 ≈ 752): ✔️[YiFei: Changed commit message to show stats for this patch series]Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/1b61df3db85c5f7f1b9202722c45e7b39df73ef2.1602431034.git.yifeifz2@illinois.edu List of files: /linux-6.15/tools/testing/selftests/seccomp/settings

bc32c9c8 - selftests/seccomp: use 90s as timeout

Mon, 01 Jun 2020 19:50:12 +0000

selftests/seccomp: use 90s as timeoutAs seccomp_benchmark tries to calibrate how many samples will take morethan 5 seconds to execute, it may end up picking up a number of samplesthat take 10 (but up to 12) seconds. As the calibration will take doublethat time, it takes around 20 seconds. Then, it executes the whole thingagain, and then once more, with some added overhead. So, the thing mighttake more than 40 seconds, which is too close to the 45s timeout.That is very dependent on the system where it's executed, so may not beobserved always, but it has been observed on x86 VMs. Using a 90s timeoutseems safe enough.Signed-off-by: Thadeu Lima de Souza Cascardo Link: https://lore.kernel.org/r/20200601123202.1183526-1-cascardo@canonical.comSigned-off-by: Kees Cook List of files: /linux-6.15/tools/testing/selftests/seccomp/settings