On Wed, Jan 19, 2022 at 08:10:27PM -0800, Yonghong Song wrote:
>
>
> On 1/19/22 9:47 AM, Alexei Starovoitov wrote:
> > On Wed, Jan 12, 2022 at 12:16 PM Yonghong Song <yhs@xxxxxx> wrote:
> > > +
> > > + /* check __user tag */
> > > + t = btf_type_by_id(btf, mtype->type);
> > > + if (btf_type_is_type_tag(t)) {
> > > + tag_value = __btf_name_by_offset(btf, t->name_off);
> > > + if (strcmp(tag_value, "user") == 0)
> > > + tmp_flag = MEM_USER;
> > > + }
> > > +
> > > stype = btf_type_skip_modifiers(btf, mtype->type, &id);
> >
> > Does LLVM guarantee that btf_tag will be the first in the modifiers?
> > Looking at the selftest:
> > +struct bpf_testmod_btf_type_tag_2 {
> > + struct bpf_testmod_btf_type_tag_1 __user *p;
> > +};
> >
> > What if there are 'const' or 'volatile' modifiers on that pointer too?
> > And in different order with btf_tag?
> > BTF gets normalized or not?
> > I wonder whether we should introduce something like
> > btf_type_collect_modifiers() instead of btf_type_skip_modifiers() ?
>
> Yes, LLVM guarantees that btf_tag will be the first in the modifiers.
> The type chain format looks like below:
> ptr -> [btf_type_tag ->]* (zero or more btf_type_tag's)
> -> [other modifiers: const and/or volatile and/or restrict]
> -> base_type
>
> I only handled zero/one btf_type_tag case as we don't have use case
> in kernel with two btf_type_tags for one pointer yet.
Makes sense. Would be good to document this LLVM behavior somewhere.
When GCC adds support for btf_tag it would need to do the same.
Or is it more of a pahole guarantee when it converts LLVM dwarf tags to BTF?
Separately... looking at:
FLAG_DONTCARE = 0
It's not quite right.
bpf_types already have an enum value at zero:
enum bpf_reg_type {
NOT_INIT = 0, /* nothing was written into register */
and other bpf_*_types too.
So empty flag should really mean zeros in bits after BPF_BASE_TYPE_BITS.
But there is no good way to express it as enum.
So maybe use 0 directly when you init:
enum bpf_type_flag tmp_flag = 0;
?
Another bit.. this patch will conflict with
commit a672b2e36a64 ("bpf: Fix ringbuf memory type confusion when passing to helpers")
so please resubmit when that patch appears in bpf-next.
Thanks!
