From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 994AB36074D for ; Wed, 28 Jan 2026 14:10:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769609431; cv=none; b=HnJt8dSTG/dznk0fmLmFK/FqG1mIJuBZd+HVr2Urz/+5myaek7UhvGwJdpIvcEZdjGxKpJISif1srMimWM29SsMQ4QV4dgFmmC029APlMWH9dswOphu0Gc8llUz9UnbHV0x/3uPq/2ZMieC1aQcz+NVel9B0VAS21eiyeBDY1DM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769609431; c=relaxed/simple; bh=THyzkYNiA5RTUK9YKP7lt4PaxlMYqQzmPF+ejfi7aHM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Md+pKJ12TL8kyPKsRqwnkZU+QxAt43oEGY8QGBimv/PqUaZsEqXehsVN/v9bfYJn2sA5/AgFkR74LvJvza0PipJAoX1qANIeCvUYcu7PszCD2sbuGaDDXWcrMMEa0OQWWiwpzbqFWYAFL5O97unfk+eYeGyAiVPdFH/SpO5zKG4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=koiK4S9f; arc=none smtp.client-ip=209.85.128.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="koiK4S9f" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-47edd9024b1so57663395e9.3 for ; Wed, 28 Jan 2026 06:10:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769609427; x=1770214227; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=5N/dLnDP7ZNeMr/qwDSyiaL36LDhsQe2QSv+3xSbKhs=; b=koiK4S9f4t2sZ+hxMz7eG9lX7AIcTGVNhhXtayxl/PaKD/SqOSrA3bXWG+VE9bBgTd 5FakKGnzOBxZZkBVShYaSQTAU7K75BeEzTD5x+Ym3sF9aWCUR8OdMTjEtcr+JebzWLQ+ 2TdRMPNAe5jPLZrfzjTHB8Iss9C4NPIzRF1XraQJm4JlGr6IQa6me+TcqlN2GF2WsMNk PkZpdCFbSujjd9jQw9XjJ4ZuRMNlJfRDDCBEG7ysbuiXcnBADnGBfociwqqpk9Mdmoyz +qKb/yShAdWSxPanf5DnRtG7Slo8FDjPie9PpLreMcnz3sviSgwtMCyR74YPQQzMUNB9 Dt5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769609427; x=1770214227; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5N/dLnDP7ZNeMr/qwDSyiaL36LDhsQe2QSv+3xSbKhs=; b=Gp64WKfY1R2dhtQIhrebryHFw+vk6EJIJWL71T7rNW1yZjYq/D/oZPdnvBNDjWon7L zRUppQXK1tHWRLoGAM1keimJqQSGTrgQk05agz+LsioHWRc4uG5kLS/s6OKrnWRIF6Zl 9Sp5fsyXujPOUYBjdE4/njsnZSlcD4r3Ba0VT1ekCfpta5Sr4Dr8IYyjhfahqrHW5ZpQ A0Hnp6db+IwevABfYhXwy/3dyyHTxcshR7le9x/4RqUJZlXwLVp5/tJnP8v3PmC6l25J 2ZxYHWpPv11La7QJz2gASQ9OgB76B+jx2TTNQPGUMARMc3g/i1s7y5D8PqHC/NywmYer 5Cfw== X-Forwarded-Encrypted: i=1; AJvYcCWDAURzVablOWuNsqOdswRs+tgJymuiHsSlhlXyHN62ogrKf/AVMtKuP91u7NFPV+CczgrKXwXD0lhJ65g=@vger.kernel.org X-Gm-Message-State: AOJu0YzN6VlT9uGh3NpBGUHydEYQBf6S1LeimDbf5OXZkOhn+C7bEqlg uSjaPM8UFtRCsr+LQYIe2MrcVf7DOJValFr8XCeUhVKrF6jR0gTsELzr X-Gm-Gg: AZuq6aLqohSa5vdc0Z05ark+cVSExyCqi7reIPPxnsBiJctGp/c4HFea60BC7ghSZBv BY3p6Ubi27jjk1d/3BZrQ5VqknRUjNq5a6O26hGZEniLhFc1CD9/Ut8wP0ZiO+IXsV0XdL6tXF1 CYynPGBv8sKYOTjsBDo4rdC/P0QlgzReTxrYLh5TmREUL9c4rqJh23f8mCs+a7i/EFvXe+quNnF 0FxLzLrwiiZpaVSBx8pVtSjHfiuxtk+jh/hXtWL4ylhN84NsfoEUsT4RClpPYGXKBGp3GCrEopI GPOKH66qvuvZ901tUr8q4bh6GQH+X87u0ZNgPiaXE31YFKWR0jJvbbtcUqq29/fTXKw+R117mZd L9W+SDgdyDiXAnB+TMtWYxB2LAyOO5aNllyxiFJsgeK6tZWoOSc2ZQY5teehv1svKkb3sHXMamw dM0UyWjQeTlNWYGyPQzfW5pag5sqjGyR2qXeWHmiOKXVMwQD4= X-Received: by 2002:a05:600c:64ce:b0:475:dd8d:2f52 with SMTP id 5b1f17b1804b1-48069c92cacmr56536475e9.32.1769609426544; Wed, 28 Jan 2026 06:10:26 -0800 (PST) Received: from ?IPV6:2a03:83e0:1126:4:c307:95a:6dc8:83a5? ([2620:10d:c092:500::6:f1cc]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066bee7d0sm141733965e9.4.2026.01.28.06.10.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 06:10:25 -0800 (PST) Message-ID: <750db7bc-2cc5-4a53-8bb6-30e702fa0989@gmail.com> Date: Wed, 28 Jan 2026 14:10:24 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH bpf-next] bpf: Add the missing types in the logs To: Feng Yang , ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev, john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me, haoluo@google.com, jolsa@kernel.org Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260128085842.145057-1-yangfeng59949@163.com> Content-Language: en-US From: Mykyta Yatsenko In-Reply-To: <20260128085842.145057-1-yangfeng59949@163.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/28/26 08:58, Feng Yang wrote: > From: Feng Yang > > Add the missing types to avoid such uninformative errors as shown below: > R1 type=ptr_ expected=ptr_ > > Signed-off-by: Feng Yang > --- > kernel/bpf/log.c | 16 ++++++++++++++-- > 1 file changed, 14 insertions(+), 2 deletions(-) > > diff --git a/kernel/bpf/log.c b/kernel/bpf/log.c > index a0c3b35de2ce..6fee3d8b3703 100644 > --- a/kernel/bpf/log.c > +++ b/kernel/bpf/log.c > @@ -473,14 +473,26 @@ const char *reg_type_str(struct bpf_verifier_env *env, enum bpf_reg_type type) > strscpy(postfix, "_or_null"); > } > > - snprintf(prefix, sizeof(prefix), "%s%s%s%s%s%s%s", > + snprintf(prefix, sizeof(prefix), "%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s", > type & MEM_RDONLY ? "rdonly_" : "", > type & MEM_RINGBUF ? "ringbuf_" : "", > type & MEM_USER ? "user_" : "", > type & MEM_PERCPU ? "percpu_" : "", > type & MEM_RCU ? "rcu_" : "", > type & PTR_UNTRUSTED ? "untrusted_" : "", > - type & PTR_TRUSTED ? "trusted_" : "" > + type & PTR_TRUSTED ? "trusted_" : "", > + type & MEM_UNINIT ? "uninit_" : "", > + type & DYNPTR_TYPE_LOCAL ? "dynptr_local_" : "", > + type & DYNPTR_TYPE_RINGBUF ? "dynptr_ringbuf_" : "", > + type & MEM_FIXED_SIZE ? "fixed_size_" : "", > + type & MEM_ALLOC ? "alloc_" : "", > + type & NON_OWN_REF ? "non_own_ref_" : "", > + type & DYNPTR_TYPE_SKB ? "dynptr_skb_" : "", > + type & DYNPTR_TYPE_XDP ? "dynptr_xdp_" : "", > + type & MEM_ALIGNED ? "aligned_" : "", > + type & MEM_WRITE ? "write_" : "", > + type & DYNPTR_TYPE_SKB_META ? "dynptr_skb_meta_" : "", > + type & DYNPTR_TYPE_FILE ? "dynptr_file_" : "" > ); Maybe it'll be good to decrease the number of the %s and also group up the strings, for example: const char *dynptr_reg_type(...) {     if (type & DYNPTR_TYPE_SKB) return "dynptr_skb_"; if (type & DYNPTR_TYPE_XDP) return "dynptr_xdp_";} so later we can substitute multiple %s with just one, corresponding to the dynptr type, this also ensures dynptr type is always in the same place, relative to other things. This can also be applied to (MEM_RDONLY, MEM_WRITE), (PTR_TRUSTED, PTR_UNTRUSTED) and so on. > > snprintf(env->tmp_str_buf, TMP_STR_BUF_LEN, "%s%s%s",