On Mon, Nov 21, 2022 at 01:10:21AM IST, Alexei Starovoitov wrote: > On Sun, Nov 20, 2022 at 11:10 AM Kumar Kartikeya Dwivedi > <memxor@xxxxxxxxx> wrote: > > > > IMO, there are a certain set of properties that check_func_arg_reg_off provides, > > you could say that if each register type was a class, then the checks there > > would be what you would do while constructing them on calling: > > > > PtrToStack(off, var_off /* can be const or variable */) > > PtrToMapValue(off, var_off /* can be const or variable */) > > PtrToBtfId(off /* must be >= 0 */) /* no var_off */ > > Just to complicate things a bit... ;) > There was a request to allow var_off in ptr_to_btf_id. > Sometimes there are fixed size arrays in structs and > programs need to iterate those arrays in a loop. Honestly, I don't see why this case needs var_off. Each iteration will bump the reg->off while indexing into the flex/fixed size array. Even ptr += scalar where scalar is known will accumulate into reg->off. But maybe I missed some specific case. > Another case is to access flex_array at the end of a struct. > Like cgroup->ancestors[]. This might, but still, to mark the dst_reg as pointer you need to know whether the possibly variable offset going beyond type->size is 8-byte aligned, right? Otherwise the best that could be done conservatively is mark_reg_unknown. > Both are currently impossible, but the verifier has to > get this capability. I guess it will be a very involved change. All over the verifier there are implicit assumptions in places (after certain checks) that PTR_TO_BTF_ID never has var_off.
