Restore DTLS buffer pool reuse and enforce buffer provenance - #167
Conversation
algesten
left a comment
There was a problem hiding this comment.
Round 1 found two incomplete receive-buffer recycling paths. Six targeted regression tests are committed and pushed; each fails on the current implementation for the reported reason.
|
Round 2 independent review: no actionable findings on commit 317c50d. I reviewed the complete cumulative PR against the requested receive-pool restoration, Buf::new() lifetime audit, and unconditional pool-provenance assertion, including surrounding receive-queue, decryption, key-exchange, and retained-secret paths. The remaining Buf::new() uses hold temporary work, pre-engine probe state, or test fixtures; buffers returned to the pool retain their provenance. The malformed-datagram and duplicate-discard fixes preserve the intended parser and queue behavior. No code or regression-test commit was needed. I did not repeat the test suites, following the user's instruction and the existing validation evidence. |
Summary
DTLS 1.2 and DTLS 1.3 receive records now acquire buffers from the engine pool and recycle them on parsing failures, rejected datagrams, duplicate or old records, and receive-queue replacement. This prevents fresh receive allocations from accumulating in the pool and preserves reuse on discard paths.
Retained handshake buffers also come from the pool. DTLS 1.2 key exchange transfers buffer ownership directly, and DTLS 1.3 retains derived traffic secrets without redundant copies. Remaining
Buf::new()calls hold temporary work buffers, pre-engine probe state, or test fixtures.BufferPool::pushuses an unconditional assertion to reject buffers that were not acquired from a pool, including in release builds. Regression tests cover repeated receive allocation reuse, malformed or oversized datagram cleanup, duplicate rejection, and rejection of fresh or replaced buffers.Fixes #165.
Supersedes #166.