On Fri, Jul 4, 2025 at 12:23 PM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote: > > On Fri, 2025-07-04 at 21:15 +0200, Kumar Kartikeya Dwivedi wrote: > > [...] > > > Yeah, so if the user specifies a type and has co-re enabled, they're > > accessing a kernel struct. > > If they're doing it without co-re, it's broken today already, or they > > know the struct is fixed in layout somehow so it's ok. > > If not, they want to access things at fixed offsets. So we can just > > use the type they're using to model untrusted derefs. > > > > So always using prog BTF makes sense to me. > > Ok, I'm switching to always using prog BTF. Hold on. The concept of ptr_to_btf_id|untrusted that points to prog type doesn't exist today. We should be careful when introducing such things. I prefer to keep btf_get_ptr_to_btf_id() in this patch and think through untrusted|ptr_to prog type later, since the use case of untrusted local type doesn't quite resonate with me. Currently we only have mem_alloc|ptr_to prog type which is read/write and came from obj_new, rbtree, link lists. Untrusted == readonly for prog type is quite odd.
