daemon: cgen: use float for meta.probability matcher

[qdeslandes]

Unify meta.probability and meta.flow_probability to share the same floating-point parsing and printing logic, replacing the integer-only code path. This allows meta.probability to accept fractional percentages (e.g., "33.33%") and removes duplicate parser/printer functions.

[github-actions]

Claude: The payload size for BF_MATCHER_META_PROBABILITY changes from sizeof(uint8_t) (1 byte) to sizeof(float) (4 bytes). Since bf_matcher_pack serializes the payload as raw binary and bf_matcher_new_from_pack → bf_matcher_new copies payload bytes without validating against ref_payload_size, any previously persisted matchers with the old 1-byte payload will be deserialized into a matcher struct with only 1 byte of payload. Subsequent *(float *)bf_matcher_payload(matcher) reads in both codegen and print would then read 3 bytes out of bounds.

Is there a version/migration mechanism for serialized state, or is this acceptable because the daemon always re-generates matchers from rules on restart?

bpfilter/src/libbpfilter/matcher.c

Line 898 in 47e22e8

.layer = BF_MATCHER_NO_LAYER,

[github-actions]

Claude: _bf_matcher_generate_meta_probability uses BPF_JMP_IMM (64-bit comparison) while the analogous _bf_matcher_generate_meta_flow_probability at line 251 uses BPF_JMP32_IMM (32-bit comparison). Since bpf_get_prandom_u32() returns a 32-bit value, BPF_JMP32_IMM is the more precise match. This is a pre-existing inconsistency, but now that the two matchers share the same parsing/printing logic, aligning the codegen would be a natural follow-up.

bpfilter/src/bpfilter/cgen/matcher/meta.c

Line 75 in 47e22e8

BPF_JMP_IMM(BPF_JGT, BPF_REG_0,

[github-actions]

Claude: review of facebook/bpfilter #453 (47e22e8)

Suggestions

• ABI break: payload size changes from 1 to 4 bytes — src/libbpfilter/matcher.c:898 — BF_MATCHER_META_PROBABILITY payload changes from sizeof(uint8_t) to sizeof(float). Previously serialized matchers will have a 1-byte payload that the new code reads as 4 bytes (*(float *)), causing out-of-bounds reads in codegen and print. Is there a version/migration mechanism, or does the daemon always regenerate from rules?
• BPF_JMP_IMM vs BPF_JMP32_IMM inconsistency — src/bpfilter/cgen/matcher/meta.c:75 — _bf_matcher_generate_meta_probability uses BPF_JMP_IMM while the analogous _bf_matcher_generate_meta_flow_probability uses BPF_JMP32_IMM. Since bpf_get_prandom_u32() returns a 32-bit value, BPF_JMP32_IMM is the more precise match. Pre-existing inconsistency, but natural to fix alongside this unification.

Nits

• strtod accepts scientific notation — src/libbpfilter/matcher.c — The shared strtod-based parser will accept inputs like "1e2%" (parsed as 100.0%) or "+50%". The lexer prevents these via bfcli, but other translation paths calling bf_matcher_new_from_raw directly could pass such strings. Pre-existing in _bf_parse_flow_probability, now also applies to meta.probability.
• Commit message component — The title is daemon: cgen: but the primary change is in src/libbpfilter/matcher.c (lib: matcher). The daemon/cgen change is a 2-line side effect. Something like lib: matcher: use float for meta.probability may be more accurate.