On 1/19/22 8:27 PM, Alexei Starovoitov wrote:
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?
Yes, this property is guaranteed by both llvm (for bpf target) and
pahole (for non bpf target). I will document this behavior in
btf.rst.
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;
?
I thought about this before and that is why I added FLAG_DONTCARE
to match value to the type. But I agree that is not elegent, I will
use 0 as you suggested.
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 for heads-up. Will fix the above two issues and
resubmit once commit a672b2e36a64 arrives in bpf-next.
Thanks!
