What the Scheduler-as-Explorer Proves—and What It Does Not

SECT asks whether Linux scheduling can be used to search for concurrency bugs rather than left as an opaque source of timing. The evidence supports a meaningful but bounded answer. In the paper’s selected experiments, kernel-native schedule control improved the ability to expose interleavings and reproduce known failures, while consuming throughput and depending on instrumentation, admissibility checks, and version-specific interfaces. The final judgment is therefore conditional: SECT is valuable when rare task orderings are the bottleneck, but it is not a substitute for input fuzzing, execution oracles, or careful triage.

The numbers describe a trade-off, not a trophy

The paper evaluates SECT under a fixed experimental setting rather than treating it as an abstract improvement. The coverage and throughput experiments use Linux 6.13-rc4, fixed resources, and ten 48-hour trials. In that setting, SECT reaches 38% higher branch coverage than SegFuzz. It also adds about 11% per-test execution latency relative to Syzkaller, while the paper reports a 72% latency reduction compared with existing concurrency fuzzers on average. Its throughput is about 4.4 million tests under the listed campaign, compared with 8.3 million for Syzkaller and 0.38 million for SegFuzz.

Those figures are not contradictory once the objective is made explicit. Syzkaller spends more of its budget on sequential input generation and therefore executes more tests. SECT spends part of the same budget on asynchronous task setup, temporal isolation, injected scheduling points, and repeated interleaving choices. A concurrency-oriented tool can produce fewer total test cases and still be more effective at a defect whose probability is dominated by thread order. The relevant comparison is not “more tests” against “fewer tests” in isolation. It is how much of the missing search dimension each test explores.

The benchmark of ten known concurrency bugs makes that distinction concrete. The full SECT variants find up to eight of the ten benchmark bugs. Syzkaller finds five, SegFuzz one, and the SECT ablation without extra scheduling-point instrumentation finds six. Two benchmark bugs remain undiscovered by all of the fuzzers. The ablation is especially informative: the scheduler’s policy alone can reveal some failures, but removing the additional points reduces its ability to reach bugs that require finer-grained orderings. The result ties the observed benefit to the combination of policy and visibility rather than to the label “SECT” alone.

The reproduction experiment isolates another question. Instead of asking the entire fuzzer to discover both an input and an ordering, it feeds schedulers syscall programs already known to trigger the benchmark bugs and counts the schedules needed to induce a failure. Across the benchmark, the paper reports an average 11.4× speed-up for SECT relative to the native operating-system scheduler. In examples, the native scheduler needs up to thousands of schedules while SECT exposes the failure in fewer than 500. This is evidence that temporal isolation addresses a real reproduction bottleneck: once the input is available, deliberate schedule selection can be much more efficient than waiting for the native scheduler to stumble into the ordering.

The same result should not be stretched into a universal coverage claim. The evaluation uses selected baselines, kernels, configurations, trials, and benchmark programs. It does not show that SECT always has higher total branch coverage than a sequential fuzzer, or that every exploration policy behaves identically. The paper itself attributes the lower coverage relative to Syzkaller partly to the allocation of resources toward interleaving exploration, and it reports variation among bugs and strategies. The strongest supported conclusion is narrower: in the evaluated setting, schedule control produced substantial gains on concurrency-focused measures while imposing a measurable cost on broad sequential throughput.

That interpretation also explains why a concurrency campaign can appear less productive under a metric that ignores its target. If its objective is to maximize branches per hour, the time spent serializing tasks and sampling extra points looks like overhead. If its objective is to reproduce a rare ordering or find a concurrency defect that ordinary scheduling almost never exposes, the same work is the mechanism of progress.