feat: per-batch scanner lock for concurrent discovery#2
Conversation
Previously the scanner mutex was held for the entire batch-send phase, serializing all concurrent discovery requests. Now each batch acquires and releases the lock independently, with a per-request stealth profile clone instead of mutating shared state. Concurrent scans interleave their batches rather than fully serializing.
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the concurrency of discovery scans by refining how the scanner lock and stealth profiles are managed. By acquiring and releasing the scanner lock for each batch of probes and handling stealth profiles on a per-request, immutable basis, the system can now interleave multiple concurrent scans, leading to more efficient resource utilization and improved performance for parallel operations. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
The changes successfully refactor the discover_bpf method to acquire the scanner mutex per-batch instead of per-scan. This enables concurrent discovery requests to interleave their batches, significantly improving concurrency for the scanning engine. The approach of building a per-request stealth profile and cloning it for each batch ensures that shared state is not mutated, maintaining correctness in a multi-threaded environment. The explicit dropping of the scanner guard within the loop is a crucial detail that ensures the lock is released promptly, allowing other tasks to acquire it between batches.
|
|
||
| // Drain AF_XDP RX ring between batches to prevent overflow | ||
| scanner_guard.poll_rx(0); | ||
| drop(scanner_guard); |
There was a problem hiding this comment.
The explicit drop(scanner_guard) here is critical for enabling the intended concurrency. Without it, the scanner_guard would remain in scope and hold the lock until the end of the for loop iteration, preventing other concurrent scans from acquiring the lock between batches of the same scan. This ensures the lock is released as soon as the batch operations are complete, allowing for true interleaving of batches from different requests.
Passthrough mode silently ran with raw socket TX when BPF had issues, producing discovery results without timing data. Remove the config option entirely so limpet either starts with full BPF or fails hard.
1 participant
Summary
discover_bpf()Part of the limpet concurrent scans work (Layer 3). Requires limpet-timing concurrent dispatch to actually exercise concurrency.
Test plan
cargo test --lib— 249 passed, 0 failed