Re: [PATCH bpf-next v2 1/4] bpf: representation and basic operations on circular numbers

[Eduard Zingerman <eddyz87@gmail.com>]

On Fri, 2026-04-24 at 09:00 +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/kernel/bpf/cnum.c b/kernel/bpf/cnum.c
> > new file mode 100644
> > index 000000000000..86142cb2aee5
> > --- /dev/null
> > +++ b/kernel/bpf/cnum.c
> 
> [ ... ]
> 
> > @@ -0,0 +1,120 @@
> 
> [ ... ]
> 
> > +/*
> > + * Suppose 'a' and 'b' are laid out as follows:
> > + *
> > + *                                                          64-bit number axis --->
> > + *
> > + * N*2^32                   (N+1)*2^32                (N+2)*2^32                (N+3)*2^32
> > + * ||------|---|=====|-------||----------|=====|-------||----------|=====|----|--||
> > + *         |   |< b >|                   |< b >|                   |< b >|    |
> > + *         |   |                                                         |    |
> > + *         |<--+--------------------------- a ---------------------------+--->|
> > + *             |                                                         |
> > + *             |<-------------------------- t -------------------------->|
> > + *
> > + * In such a case it is possible to infer a more tight representation t
> > + * such that ∀ v ∈ a, (u32)v ∈ b: v ∈ t.
> 
> The commit message describes this specification as "∀ v ∈ a, (u32)v ∈ b:
> v ∈ t." This typo was identified by the CI bot and you acknowledged it
> in v1 review, and the code comment was fixed to use "(u32)v" correctly.
> However, the commit message still shows "(u32)v" instead of the
> incorrect "(u32)a" from v1. Is this inconsistency intentional, or should
> the commit message match the corrected specification?
> 
> Note: The CI bot pointed out that "(u32)a ∈ b" doesn't depend on v,
> making the quantifier trivial. You agreed and the code was fixed, but the
> description in the commit message appears to already have the correct
> version.

This appears to be a word salad.
Both comment and commit message say: ∀ v ∈ a, (u32)v ∈ b: v ∈ t.

> > + */
> > +struct cnum64 cnum64_cnum32_intersect(struct cnum64 a, struct cnum32 b)
> 
> [ ... ]
> 
> > diff --git a/kernel/bpf/cnum_defs.h b/kernel/bpf/cnum_defs.h
> > new file mode 100644
> > index 000000000000..1aa0554bf19f
> > --- /dev/null
> > +++ b/kernel/bpf/cnum_defs.h
> 
> [ ... ]
> 
> > @@ -0,0 +1,233 @@
> 
> [ ... ]
> 
> > +/*
> > + * If there exists a cnum representing an intersection of cnums 'a' and 'b',
> > + * returns this intersection in 'out' and returns true.
> > + * If such cnum does not exist:
> > + * - if intersection is empty, returns false.
> > + * - if intersection produces two ranges, returns smaller of
> > + *   'a' or 'b' in 'out'.
> > + */
> > +struct cnum_t FN(intersect)(struct cnum_t a, struct cnum_t b)
> 
> Does this comment match the actual function signature? The comment
> describes returning "this intersection in 'out' and returns true" and
> "returns false" for empty intersection, which suggests an output parameter
> 'out' and a bool return type. However, the function signature shows
> (struct cnum_t a, struct cnum_t b) with no 'out' parameter, and returns
> struct cnum_t by value. Should the comment be updated to describe the
> actual return convention where the intersection cnum is returned directly,
> EMPTY is returned for empty intersection, and the smaller range is returned
> when the intersection produces two disjoint arcs?

The comment has to be fixed.