Hi Hao,
On Thu, Jan 12, 2023 at 02:18:05PM -0800, Hao Luo wrote:
> Feature request:
>
> To support checking the type of a specific field directly.
>
> Background:
>
> Currently, As far as I know, CORE is able to check a field’s
> existence, offset, size and signedness, but not the field’s type
> directly.
Are you aware of the TYPE_MATCHES support [0] that was added a while back?
Specifically, for types to "match" they have to be of the same "kind" (struct
vs. struct, union vs. union, etc.). That check is done recursively for fields
from what I recall (please see linked change description or source code for more
details).
> There are changes that convert a field from a scalar type to a struct
> type, without changing the field’s name, offset or size. In that case,
> it is currently difficult to use CORE to check such changes. For a
> concrete example,
>
> Commit 94a9717b3c (“locking/rwsem: Make rwsem->owner an atomic_long_t”)
>
> Changed the type of rw_semaphore::owner from tast_struct * to
> atomic_long_t. In that change, the field name, offset and size remain
> the same. But the BPF program code used to extract the value is
> different. For the kernel where the field is a pointer, we can write:
>
> sem->owner
>
> While in the kernel where the field is an atomic, we need to write:
>
> sem->owner.counter.
>
> It would be great to be able to check a field’s type directly.
> Probably something like:
>
> #include “vmlinux.h”
>
> struct rw_semaphore__old {
> struct task_struct *owner;
> };
>
> struct rw_semaphore__new {
> atomic_long_t owner;
> };
>
> u64 owner;
> if (bpf_core_field_type_is(sem->owner, struct task_struct *)) {
> struct rw_semaphore__old *old = (struct rw_semaphore__old *)sem;
> owner = (u64)sem->owner;
> } else if (bpf_core_field_type_is(sem->owner, atomic_long_t)) {
> struct rw_semaphore__new *new = (struct rw_semaphore__new *)sem;
> owner = new->owner.counter;
> }
I haven't tried it out, but from the top of my head, TYPE_MATCHES should be able
to help with this case. If not, it may be useful for us to understand why it is
insufficient. Could you share feedback?
Thanks,
Daniel
[0]: https://lore.kernel.org/bpf/20220620231713.2143355-5-deso@xxxxxxxxxx/
