Hello Alexei Starovoitov, This is a semi-automatic email about new static checker warnings. The patch 5b92a28aae4d: "bpf: Support attaching tracing BPF program to other BPF programs" from Nov 14, 2019, leads to the following Smatch complaint: kernel/bpf/btf.c:3744 btf_ctx_access() error: we previously assumed 't' could be null (see line 3706) kernel/bpf/btf.c 3705 /* if (t == NULL) Fall back to default BPF prog with 5 u64 arguments */ 3706 nr_args = t ? btf_type_vlen(t) : 5; ^ Check 3707 if (prog->aux->attach_btf_trace) { 3708 /* skip first 'void *__data' argument in btf_trace_##name typedef */ 3709 args++; 3710 nr_args--; 3711 } 3712 3713 if (arg == nr_args) { 3714 if (prog->expected_attach_type == BPF_TRACE_FEXIT) { 3715 if (!t) 3716 return true; 3717 t = btf_type_by_id(btf, t->type); 3718 } else if (prog->expected_attach_type == BPF_MODIFY_RETURN) { 3719 /* For now the BPF_MODIFY_RETURN can only be attached to 3720 * functions that return an int. 3721 */ 3722 if (!t) 3723 return false; 3724 3725 t = btf_type_skip_modifiers(btf, t->type, NULL); 3726 if (!btf_type_is_int(t)) { 3727 bpf_log(log, 3728 "ret type %s not allowed for fmod_ret\n", 3729 btf_kind_str[BTF_INFO_KIND(t->info)]); 3730 return false; 3731 } 3732 } Smatch is complaining that maybe t is NULL and prog->expected_attach_type is neither BPF_TRACE_FEXIT nor BPF_MODIFY_RETURN. 3733 } else if (arg >= nr_args) { 3734 bpf_log(log, "func '%s' doesn't have %d-th argument\n", 3735 tname, arg + 1); 3736 return false; 3737 } else { 3738 if (!t) 3739 /* Default prog with 5 args */ 3740 return true; 3741 t = btf_type_by_id(btf, args[arg].type); 3742 } 3743 /* skip modifiers */ 3744 while (btf_type_is_modifier(t)) ^ Dereference 3745 t = btf_type_by_id(btf, t->type); 3746 if (btf_type_is_int(t) || btf_type_is_enum(t)) regards, dan carpenter