feat(common): allocation-free tag validation and parsing by morrisonlevi · Pull Request #2329 · DataDog/libdatadog

morrisonlevi · 2026-08-06T23:23:23Z

What does this PR do?

Adds typed tag validation errors and a borrowed iterator for tag lists.

Motivation

In the OTel process and context work in PHP, we are now going to be making tags on every sample. I'm working to avoid allocations, or delay them until later if feasible. Right now there's no room because the only validation APIs are to actually make a tag. These new APIs let us validate key:value, value, and DD_TAGS style tags all without allocating.

Additional Notes

These new APIs are consumed internally so they aren't dead code either, except for validating a (key, value) pair. The reason is that the way it is technically implemented in the constructor is to format!("{key}:{value}") and then use the serialized key:value validator instead. This is undesirable for me so I've added the new API and tried to make property tests to ensure it stays in-sync with the equivalent behavior.

How to test the change?

Test regularly, nothing should be significantly different.

Add typed tag validation errors and a borrowed iterator for tag lists. Reuse them internally while preserving existing constructors, return types, and error messages.

github-actions · 2026-08-06T23:28:34Z

📚 Documentation Check Results

⚠️ 168 documentation warning(s) found

📦 `libdd-common` - 168 warning(s)

Updated: 2026-08-07 05:10:13 UTC | Commit: fa6f9a7 | missing-docs job results

github-actions · 2026-08-06T23:30:21Z

🔒 Cargo Deny Results

⚠️ 4 issue(s) found, showing only errors (advisories, bans, sources)

📦 `libdd-common` - 4 error(s)

Show output

error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:35:1
   │
35 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     ├── crossbeam-deque v0.8.5
     │   └── rayon-core v1.12.1
     │       └── rayon v1.10.0
     │           └── criterion v0.5.1
     │               └── libdd-common v5.1.0
     └── moka v0.12.13
         └── hickory-resolver v0.25.2
             └── reqwest v0.13.2
                 └── libdd-common v5.1.0 (*)

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:65:1
   │
65 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0118
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0118
   ├ The NSEC3 closest-encloser proof validation in `hickory-proto`'s
     `DnssecDnsHandle` walks from the QNAME up to the SOA owner name, building a
     list of candidate encloser names. The iterator used assumes the
     QNAME is a descendant of the SOA owner, terminating only when the current
     candidate equals the SOA name. When the SOA in a response's authority section
     is not an ancestor of the QNAME, the loop stalls at the DNS root and never
     terminates, repeatedly calling `Name::base_name()` and pushing newly allocated
     `Name` and hashed-name entries into the candidate `Vec`.
     
     The bug is reachable by any caller of `DnssecDnsHandle` — including the
     resolver, recursor, and client — when built with the `dnssec-ring` or
     `dnssec-aws-lc-rs` feature and configured to perform DNSSEC validation. It is
     triggered while validating a NoData or NXDomain response whose authority
     section contains an SOA record from a zone other than an ancestor of the
     QNAME, on a code path that requires NSEC3 closest-encloser proof. In practice
     this can be reached through an insecure CNAME chain that crosses zone
     boundaries into a DNSSEC-signed zone returning NoData, but the minimum
     condition is just a mismatched SOA owner on a response requiring NSEC3
     validation.
     
     A `debug_assert_ne!(name, Name::root())` guards the loop body, so debug builds
     abort with a panic on the first iteration past the root. Release builds
     compile the assertion out and run the loop unbounded, allocating until the
     process exhausts available memory (OOM). A reachable upstream attacker who
     can return such a response can therefore crash a debug-built validator or
     exhaust memory on a release-built one.
     
     The affected code was migrated from `hickory-proto` to `hickory-net` as part of
     the 0.26.0 release. The `hickory-proto` 0.26.x release no longer offers
     `DnssecDnsHandle` and so we recommend all affected users update to `hickory-net`
     0.26.1 when the implementation of that type is required.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-3v94-mw7p-v465
   ├ Solution: No safe upgrade is available!
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             └── libdd-common v5.1.0

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:65:1
   │
65 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0119
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0119
   ├ During message encoding, `hickory-proto`'s `BinEncoder` stores pointers to
     labels that are candidates for name compression in a `Vec<(usize, Vec<u8>)>`.
     The name compression logic then searches for matches with a linear scan.
     
     A malicious message with many records can both introduce many candidate labels,
     and invoke this linear scan many times. This can amplify CPU exhaustion in DoS
     attacks.
     
     This is similar to
     [CVE-2024-8508](https://www.nlnetlabs.nl/downloads/unbound/CVE-2024-8508.txt).
     
     We recommend all affected users update to `hickory-proto` 0.26.1 for the fix.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-q2qq-hmj6-3wpp
   ├ Solution: Upgrade to >=0.26.1 (try `cargo update -p hickory-proto`)
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             └── libdd-common v5.1.0

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:131:1
    │
131 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by [@lopopolo](https://github.com/lopopolo)) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── libdd-common v5.1.0
      └── proptest v1.5.0
          └── (dev) libdd-common v5.1.0 (*)

advisories FAILED, bans ok, sources ok

Updated: 2026-08-07 05:11:54 UTC | Commit: fa6f9a7 | dependency-check job results

datadog-prod-us1-4 · 2026-08-06T23:38:38Z

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 75.92% (+0.01%)

_{This comment will be updated automatically if new data arrives.

🔗 Commit SHA: e1489d3 | Docs | Datadog PR Page | Give us feedback!}

dd-octo-sts · 2026-08-06T23:52:10Z

Artifact Size Benchmark Report

aarch64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a	89.19 MB	89.19 MB	-0% (-6.21 KB) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so	8.20 MB	8.20 MB	0% (0 B) 👌

aarch64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so	11.06 MB	11.06 MB	+0% (+128 B) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a	100.37 MB	100.36 MB	-0% (-6.10 KB) 👌

libdatadog-x64-windows

Artifact	Baseline	Commit	Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll	26.63 MB	26.63 MB	-0% (-1.00 KB) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib	94.56 KB	94.56 KB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb	191.43 MB	191.42 MB	-0% (-8.00 KB) 👌
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib	1001.70 MB	1001.43 MB	--.02% (-272.57 KB) 💪
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll	8.71 MB	8.71 MB	--.02% (-2.00 KB) 💪
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib	94.56 KB	94.56 KB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb	25.62 MB	25.62 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib	51.01 MB	51.01 MB	-0% (-2.73 KB) 👌

libdatadog-x86-windows

Artifact	Baseline	Commit	Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll	23.22 MB	23.22 MB	-0% (-1.00 KB) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib	96.04 KB	96.04 KB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb	196.35 MB	196.33 MB	--.01% (-24.00 KB) 💪
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib	990.83 MB	990.81 MB	-0% (-23.72 KB) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll	6.73 MB	6.73 MB	--.01% (-1.00 KB) 💪
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib	96.04 KB	96.04 KB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb	27.55 MB	27.55 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib	48.56 MB	48.55 MB	-0% (-2.20 KB) 👌

x86_64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a	79.47 MB	79.46 MB	--.01% (-8.64 KB) 💪
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so	9.13 MB	9.12 MB	--.04% (-4.00 KB) 💪

x86_64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a	95.12 MB	95.12 MB	-0% (-8.42 KB) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so	11.14 MB	11.14 MB	--.03% (-3.88 KB) 💪

pr-commenter · 2026-08-07T00:05:59Z

Benchmarks

Comparison

Benchmark execution time: 2026-08-07 05:43:06

Comparing candidate commit e1489d3 in PR branch PROF-15487-allocation-free-tag-validation with baseline commit ea75b04 in branch main.

Found 0 performance improvements and 2 performance regressions! Performance is the same for 138 metrics, 0 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

🟩 = significantly better candidate vs. baseline
🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:vec_map/as_deduped_map/already_deduped/16

🟥 execution_time [+2.722ns; +3.818ns] or [+8.940%; +12.538%]

scenario:vec_map/get_miss/64

🟥 execution_time [+28.678ns; +28.785ns] or [+102.664%; +103.045%]

Benchmark execution time: 2026-08-07 05:54:01

Comparing candidate commit e1489d3 in PR branch PROF-15487-allocation-free-tag-validation with baseline commit ea75b04 in branch main.

Found 7 performance improvements and 2 performance regressions! Performance is the same for 171 metrics, 10 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

🟩 = significantly better candidate vs. baseline
🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:alloc_free/system/4096

🟩 execution_time [-12.315ns; -12.125ns] or [-11.627%; -11.448%]

scenario:datadog_sample_span/name_pattern_rule_matching/wall_time

🟥 execution_time [+33.482ns; +33.666ns] or [+13.042%; +13.114%]

scenario:profiler_attached/fast_path_system/16

🟩 execution_time [-17.191ns; -17.162ns] or [-38.611%; -38.546%]

scenario:profiler_attached/fast_path_system/256

🟩 execution_time [-17.283ns; -17.249ns] or [-38.811%; -38.736%]

scenario:profiler_attached/fast_path_system/64

🟩 execution_time [-17.317ns; -17.282ns] or [-38.890%; -38.810%]

scenario:profiler_attached/fast_path_system/65536

🟩 execution_time [-10.084ns; -9.922ns] or [-9.029%; -8.883%]

scenario:profiler_attached/slow_path_system/4096

🟥 execution_time [+25.134ns; +25.236ns] or [+19.659%; +19.739%]

scenario:trace_buffer/4_senders/no_delay

🟩 execution_time [-180.039µs; -155.845µs] or [-6.806%; -5.892%]
🟩 throughput [+85566.255op/s; +99006.913op/s] or [+6.284%; +7.271%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

feat(common): allocation-free tag validation and parsing

29c77c3

Add typed tag validation errors and a borrowed iterator for tag lists. Reuse them internally while preserving existing constructors, return types, and error messages.

github-actions Bot added the common label Aug 6, 2026

morrisonlevi marked this pull request as ready for review August 7, 2026 03:45

morrisonlevi requested a review from a team as a code owner August 7, 2026 03:45

Merge branch 'main' into PROF-15487-allocation-free-tag-validation

e1489d3

Navigation Menu

Uh oh!

feat(common): allocation-free tag validation and parsing - #2329

feat(common): allocation-free tag validation and parsing#2329
morrisonlevi wants to merge 2 commits into
mainfrom
PROF-15487-allocation-free-tag-validation

morrisonlevi commented Aug 6, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Aug 6, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Aug 6, 2026 •

edited

Loading

Uh oh!

datadog-prod-us1-4 Bot commented Aug 6, 2026 •

edited by datadog-datadog-prod-us1 Bot

Loading

Uh oh!

dd-octo-sts Bot commented Aug 6, 2026 •

edited

Loading

Uh oh!

pr-commenter Bot commented Aug 7, 2026 •

edited

Loading

Explanation

More details about the CI and significant changes

Explanation

More details about the CI and significant changes

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

morrisonlevi commented Aug 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR do?

Motivation

Additional Notes

How to test the change?

Uh oh!

github-actions Bot commented Aug 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📚 Documentation Check Results

📦 libdd-common - 168 warning(s)

Uh oh!

github-actions Bot commented Aug 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔒 Cargo Deny Results

📦 libdd-common - 4 error(s)

Uh oh!

datadog-prod-us1-4 Bot commented Aug 6, 2026 • edited by datadog-datadog-prod-us1 Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dd-octo-sts Bot commented Aug 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Artifact Size Benchmark Report

Uh oh!

pr-commenter Bot commented Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Benchmarks

Comparison

Explanation

More details about the CI and significant changes

scenario:vec_map/as_deduped_map/already_deduped/16

scenario:vec_map/get_miss/64

Explanation

More details about the CI and significant changes

scenario:alloc_free/system/4096

scenario:datadog_sample_span/name_pattern_rule_matching/wall_time

scenario:profiler_attached/fast_path_system/16

scenario:profiler_attached/fast_path_system/256

scenario:profiler_attached/fast_path_system/64

scenario:profiler_attached/fast_path_system/65536

scenario:profiler_attached/slow_path_system/4096

scenario:trace_buffer/4_senders/no_delay

Candidate

Baseline

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

morrisonlevi commented Aug 6, 2026 •

edited

Loading

github-actions Bot commented Aug 6, 2026 •

edited

Loading

📦 `libdd-common` - 168 warning(s)

github-actions Bot commented Aug 6, 2026 •

edited

Loading

📦 `libdd-common` - 4 error(s)

datadog-prod-us1-4 Bot commented Aug 6, 2026 •

edited by datadog-datadog-prod-us1 Bot

Loading

dd-octo-sts Bot commented Aug 6, 2026 •

edited

Loading

pr-commenter Bot commented Aug 7, 2026 •

edited

Loading