On Fri, 2026-08-14 at 16:19 -0700, Vineet Gupta wrote: > bpf_reg_state carries a single bool, ->precise. Other per-register boolean > properties exist (and more are coming), so convert the bool into a u8, > call it flags and give the property a name. > > - bool precise; > +#define BPF_FLAG_PRECISE (1U << 7) > + u8 flags; > > Both occupy 1 byte at the same offset, so the struct layout is unchanged. > ->precise was the last field, after ->frameno, and ->flags takes exactly > that slot, so the memcmp()/offsetof() based comparisons are unaffected: > every one of them stops at offsetof(id), offsetof(var_off) or > offsetof(frameno), i.e. at or before the field either way. > > That tail position is not an accident -- it is where fields live that are > compared semantically rather than byte-wise. ->precise is never memcmp()ed; > regsafe() tests it explicitly, and an imprecise old scalar is a wildcard: > > if (!reg_is_precise(rold) && exact == NOT_EXACT) > return true; > > PRECISE also takes bit 7 rather than bit 0, because it is the odd one out > among the flags that will share this byte: the others describe how a register > relates to its ->id set and are cleared as a group, while PRECISE belongs to > the register alone and must survive that clearing. Growing the rest up from > bit 0 keeps a clear-the-link-bits mask from reaching it by construction. > > Reads go through a helper, since they are the common case and read better. > Set and clear stay open-coded as the usual reg->flags |= / &= ~ bit ops. > > No functional change intended. > > Suggested-by: Eduard Zingerman <[email protected]> > Signed-off-by: Vineet Gupta <[email protected]> > ---
Sorry for the confusion, what I intended to suggest is usage of bitfields, instead of carving out bits from the 'id' field. Let me read the rest of the series to see how the flags look overall, but looking just at this patch I'd suggest bitfields.
