Received: by 2002:a05:7412:5112:b0:fa:6e18:a558 with SMTP id fm18csp1290691rdb; Wed, 24 Jan 2024 10:18:41 -0800 (PST) X-Google-Smtp-Source: AGHT+IF7PBXzQ9wsCcnDFZLcHWt0nfZzKHdtHT/tVdwthElOaix+btHKlXgS0OWfyD4AOlA++nzx X-Received: by 2002:a05:6214:c2e:b0:681:6991:33c5 with SMTP id a14-20020a0562140c2e00b00681699133c5mr3129636qvd.51.1706120321373; Wed, 24 Jan 2024 10:18:41 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706120321; cv=pass; d=google.com; s=arc-20160816; b=RLuXPFmHXT+knT1XCU8vR/3iaGcZMD3RgnMZ/DwnP+z3LnugRt/tFGsnqQzZifN0A2 +qfqXwBKZrs2slcE4nCWShhvJyZ6+1BDQss93lA78JKPS9C8IzVYuZhBZ/YPf8go+oMx IVWi+KG/KDpGxxM4PCgBp9CCtxgaLEoH6ayUTblYgafCuyUZRf9V85sMRZgmEwGpaaJ3 2iFFV/bJhgZH2J5sGKnx5vyyfaGFu21jTtVJDDFrQR/BqN2KIPlcxeETiWpp5MYZ+EHy zsr/3gyyX66CmIqSN2w9tVLBY2uelnDCGBP1htxsUDB3cuLHhEyCWLWNcQQM+S6Sjjbp gDJA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:list-unsubscribe:list-subscribe :list-id:precedence:dkim-signature; bh=TUH9EJF482lFzbYZU/u33C+9zo+ebi//3wmOi6+KsBk=; fh=j7Lj4D96ERQSont+5C8jwuZWHNsQx9iIx7MI9a4x2ck=; b=Th90V8+NrxozUEaSmqSC2X1gMoTB7jTbG8Fd5VOFeIdDtex3P4147y/GYkmDC6xbf3 lfz3Bksyyj8ZlgjQbVgu3zgoiYVByuGux3TOPSfe/Y8JJlCi65vnbMgMJSKUTDUmfUy+ z4f0eq19RR2l3B2Stq91qEHI86mq20xYQFB+4t/4NJYqWUaRPjzTp4jaeZ+BSxBDXPQj /yWPlMsNaFhauSybcQ4RP41UVGPOp5k84HKhED7OvTo1/HrvZ7NaKgbJ9dWOlXEZpU/X 4hYRVScYNOgkCCsrgyfmOXonAcR402qHcNtwh/fzwLoy1HRIRrqy13/pwgJ88ITlQYAK QKXg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=vhFzUqsf; arc=pass (i=1 spf=pass spfdomain=google.com dkim=pass dkdomain=google.com dmarc=pass fromdomain=google.com); spf=pass (google.com: domain of linux-kernel+bounces-37498-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-37498-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id k4-20020a0cabc4000000b00686acfa79f5si2238398qvb.530.2024.01.24.10.18.41 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jan 2024 10:18:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-37498-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=vhFzUqsf; arc=pass (i=1 spf=pass spfdomain=google.com dkim=pass dkdomain=google.com dmarc=pass fromdomain=google.com); spf=pass (google.com: domain of linux-kernel+bounces-37498-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-37498-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 16FB61C22B6B for ; Wed, 24 Jan 2024 18:18:41 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5A20812A175; Wed, 24 Jan 2024 18:18:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="vhFzUqsf" Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) (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 AA181128366 for ; Wed, 24 Jan 2024 18:18:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706120310; cv=none; b=SppjaR9hpvWJHtFx/Q7Ocbsp5oQJ06SPs76h6YRTsh75hy9eUhSBz+q+uzNy625PcLRxrhfAFT75pAOkcrSkPaBNrWQlSIYmcfx96t29RgBYvppQ2qc5psg0cEOkOuUGDhNxMRyMREjopFFGHiGsdjKxk1hMmrlw4fIoW3sbGBw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706120310; c=relaxed/simple; bh=NI5XBFOKfugI/xLCs7kqRno/JslQKhkEl/+GzifGBuU=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=n4JuYBdyK5inRp93rmZY7YWLkrLD0afXLv+fTU5uqTBVkCuzuEnpUztzX1oqiXqlMP3pNfaEH89DKjdGdOpryLPM47lT/F3xFtvC+gt65gXwm0SUB0S3oQ3Jxsxj4E/LyQcpgpkY7Zjl0xeefaYwk6xeBaReAcsVtrEu5T5ENQM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=vhFzUqsf; arc=none smtp.client-ip=209.85.214.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-1d76f1e3e85so10455ad.0 for ; Wed, 24 Jan 2024 10:18:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706120308; x=1706725108; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=TUH9EJF482lFzbYZU/u33C+9zo+ebi//3wmOi6+KsBk=; b=vhFzUqsfgqizqBGZxw3286KUV64quijn+g8Bps8LP6rXllREx1MYRg8AWYx2Pyhe/e VzwzlYogI/NB8v4y/GrQ0HXJo6dT/SRe8m4r3/kEPyM9Oa0KXLr7r8AuCwLsEfGYIGc1 OjJKrwUvFCAYJL+QCykSlmrkNnv736JMCT1IpzSeADOwzCaEudww4ilRvo3Ss1+4di+u 1r/GTKkZut2TvfB/KKTyQkJoCzHIY7JhSOfTmnosF5S+nskit7GIwPwKVxSj+UEgACTB rpwu4Hc7CoJCVjO5Yucb7PL0FOrFYzOLMSAITUgbKJ5rO3B3wlzLiVIEobUnrFmVfct1 Y9Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706120308; x=1706725108; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TUH9EJF482lFzbYZU/u33C+9zo+ebi//3wmOi6+KsBk=; b=teN3u1R2Gi1mytjcnn8kBt16cLRIMtYZsQ0lGYZ/Q6DZoIB2G2umDr3zOLk+8kWdlq PsYo21jnzauB6jtwElolyHQcl4P85Ht44useN7RU7hw+peJYUdyQN/z7X/3DlYxX/1qa LiyG1xyxoQkz1KS5uEIJfaRE5pvTptTvyYXtNPMwPHNtIRoNyhwg4HXZePbQMa73/RLV FoHUJDYD6p1jeRRML7lqalVKkSJS4acNA+gF1iB+51LGc2ctjwJvePyKUBnjcn2kZR5f pupvYI4FnlJ2wHoNhJyxxujIixOgyfhLBVFb20oHEOap/d2Y/4RwxGtqBpAIY1+4CFtu TmjA== X-Gm-Message-State: AOJu0YxxffR985IOf1KRQsPpbjZI3eH8F0dp4PcgHJ8y5vmeHGSKPL9l 7f9jQbE9jy8z8F80neB4zisNkOo/Ck/3F+xQQxwTNMSBLnmKB2TWfNxTWVH0YxizXmccq6y2Oq0 f+Ncx4nTHcAtNlfr85AlUFoK7h78lkJJNTB92 X-Received: by 2002:a17:902:d2c2:b0:1d7:692e:3c8b with SMTP id n2-20020a170902d2c200b001d7692e3c8bmr183200plc.13.1706120307547; Wed, 24 Jan 2024 10:18:27 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240123204437.1322700-1-irogers@google.com> In-Reply-To: From: Ian Rogers Date: Wed, 24 Jan 2024 10:18:16 -0800 Message-ID: Subject: Re: [PATCH v2] libbpf: Add some details for BTF parsing failures To: Andrii Nakryiko Cc: Alan Maguire , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , bpf@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 24, 2024 at 9:40=E2=80=AFAM Andrii Nakryiko wrote: > > On Tue, Jan 23, 2024 at 8:37=E2=80=AFPM Ian Rogers w= rote: > > > > On Tue, Jan 23, 2024 at 8:25=E2=80=AFPM Andrii Nakryiko > > wrote: > > > > > > On Tue, Jan 23, 2024 at 12:44=E2=80=AFPM Ian Rogers wrote: > > > > > > > > As CONFIG_DEBUG_INFO_BTF is default off the existing "failed to fin= d > > > > valid kernel BTF" message makes diagnosing the kernel build issue s= ome > > > > what cryptic. Add a little more detail with the hope of helping use= rs. > > > > > > > > Before: > > > > ``` > > > > libbpf: failed to find valid kernel BTF > > > > libbpf: Error loading vmlinux BTF: -3 > > > > libbpf: failed to load object 'lock_contention_bpf' > > > > libbpf: failed to load BPF skeleton 'lock_contention_bpf': -3 > > > > ``` > > > > > > > > After no access /sys/kernel/btf/vmlinux: > > > > ``` > > > > libbpf: Unable to access canonical vmlinux BTF from /sys/kernel/btf= /vmlinux > > > > libbpf: Error loading vmlinux BTF: -3 > > > > libbpf: failed to load object 'lock_contention_bpf' > > > > libbpf: failed to load BPF skeleton 'lock_contention_bpf': -3 > > > > ``` > > > > > > > > After no BTF /sys/kernel/btf/vmlinux: > > > > ``` > > > > libbpf: Failed to load vmlinux BTF from /sys/kernel/btf/vmlinux, wa= s CONFIG_DEBUG_INFO_BTF enabled? > > > > libbpf: Error loading vmlinux BTF: -3 > > > > libbpf: failed to load object 'lock_contention_bpf' > > > > libbpf: failed to load BPF skeleton 'lock_contention_bpf': -3 > > > > ``` > > > > > > > > Closes: https://lore.kernel.org/bpf/CAP-5=3DfU+DN_+Y=3DY4gtELUsJxKN= DDCOvJzPHvjUVaUoeFAzNnig@mail.gmail.com/ > > > > Signed-off-by: Ian Rogers > > > > > > > > --- > > > > v2. Try to address review comments from Andrii Nakryiko. > > > > --- > > > > tools/lib/bpf/btf.c | 49 ++++++++++++++++++++++++++++++++---------= ---- > > > > 1 file changed, 35 insertions(+), 14 deletions(-) > > > > > > > > diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c > > > > index ee95fd379d4d..d8a05dda0836 100644 > > > > --- a/tools/lib/bpf/btf.c > > > > +++ b/tools/lib/bpf/btf.c > > > > @@ -4920,16 +4920,25 @@ static int btf_dedup_remap_types(struct btf= _dedup *d) > > > > return 0; > > > > } > > > > > > > > +static struct btf *btf__load_vmlinux_btf_path(const char *path) > > > > > > I don't think we need this helper, you literally call btf__parse() an= d > > > pr_debug(), that's all > > > > > > > +{ > > > > + struct btf *btf; > > > > + int err; > > > > + > > > > + btf =3D btf__parse(path, NULL); > > > > + err =3D libbpf_get_error(btf); > > > > > > we should stop using libbpf_get_error, in libbpf v1.0+ it's best to d= o just > > > > > > btf =3D btf__parse(path, NULL); > > > if (!btf) { > > > err =3D -errno; > > > pr_debug(...); > > > return NULL; > > > } > > > > > > > + pr_debug("loading kernel BTF '%s': %d\n", path, err); > > > > + return err ? NULL : btf; > > > > +} > > > > + > > > > /* > > > > * Probe few well-known locations for vmlinux kernel image and try= to load BTF > > > > * data out of it to use for target BTF. > > > > */ > > > > struct btf *btf__load_vmlinux_btf(void) > > > > { > > > > + /* fall back locations, trying to find vmlinux on disk */ > > > > const char *locations[] =3D { > > > > - /* try canonical vmlinux BTF through sysfs first */ > > > > - "/sys/kernel/btf/vmlinux", > > > > - /* fall back to trying to find vmlinux on disk othe= rwise */ > > > > "/boot/vmlinux-%1$s", > > > > "/lib/modules/%1$s/vmlinux-%1$s", > > > > "/lib/modules/%1$s/build/vmlinux", > > > > @@ -4938,29 +4947,41 @@ struct btf *btf__load_vmlinux_btf(void) > > > > "/usr/lib/debug/boot/vmlinux-%1$s.debug", > > > > "/usr/lib/debug/lib/modules/%1$s/vmlinux", > > > > }; > > > > - char path[PATH_MAX + 1]; > > > > + const char *location; > > > > struct utsname buf; > > > > struct btf *btf; > > > > - int i, err; > > > > + int i; > > > > > > > > - uname(&buf); > > > > + /* try canonical vmlinux BTF through sysfs first */ > > > > + location =3D "/sys/kernel/btf/vmlinux"; > > > > + if (faccessat(AT_FDCWD, location, R_OK, AT_EACCESS) =3D=3D = 0) { > > > > + btf =3D btf__load_vmlinux_btf_path(location); > > > > + if (btf) > > > > + return btf; > > > > + > > > > + pr_warn("Failed to load vmlinux BTF from %s, was CO= NFIG_DEBUG_INFO_BTF enabled?\n", > > > > + location); > > > > > > Mentioning CONFIG_DEBUG_INFO_BTF seems inappropriate here, > > > /sys/kernel/btf/vmlinux exists, we just failed to parse its data, > > > right? So it's not about CONFIG_DEBUG_INFO_BTF, we just don't support > > > something in BTF data. Just pr_warn("Failed to load vmlinux BTF from > > > %s: %d", location, err); should be good > > > > I think that assumes a lot about a user, they understand what BTF > > means, they know it is controlled by a kernel config option, and that > > the config option needs to be overridden (as it is defaulted off) for > > BTF to work. Given this escaped Raspberry Pi OS the potential for this > > mistake seems high - hence wanting to highlight the config option. > > But there is nothing wrong with CONFIG_DEBUG_INFO_BTF, it is enabled, > and hence there is /sys/kernel/btf/vmlinux on the system. With > CONFIG_DEBUG_INFO_BTF suggestion you'll just lead users astray. What > am I missing? Okay, so can we warn about CONFIG_DEBUG_INFO_BTF if /sys/kernel/btf/vmlinux isn't accessible? I'd like to clear up confusion over permissions, generally not an issue as these tools tend to get run as root, and a missing kernel configuration - the issue with Raspberry Pi OS. Thanks, Ian > > > > > > + } else > > > > + pr_warn("Unable to access canonical vmlinux BTF fro= m %s\n", location); > > > > > > here the question of CONFIG_DEBUG_INFO_BTF is more appropriate, if > > > /sys/kernel/btf/vmlinux (on modern enough kernels) is missing, then > > > CONFIG_DEBUG_INFO_BTF is missing, probably. But I'd emit this only > > > after trying all the fallback paths and not finding anything. > > > > > > also stylistical nit: if one side of if has {}, the other has to have > > > {} as well, even if it's just one line > > > > > > > > > > > + uname(&buf); > > > > for (i =3D 0; i < ARRAY_SIZE(locations); i++) { > > > > - snprintf(path, PATH_MAX, locations[i], buf.release)= ; > > > > + char path[PATH_MAX + 1]; > > > > + > > > > + snprintf(path, sizeof(path), locations[i], buf.rele= ase); > > > > > > > > + btf =3D btf__load_vmlinux_btf_path(path); > > > > if (faccessat(AT_FDCWD, path, R_OK, AT_EACCESS)) > > > > continue; > > > > > > > > - btf =3D btf__parse(path, NULL); > > > > - err =3D libbpf_get_error(btf); > > > > - pr_debug("loading kernel BTF '%s': %d\n", path, err= ); > > > > - if (err) > > > > - continue; > > > > + btf =3D btf__load_vmlinux_btf_path(location); > > > > + if (btf) > > > > + return btf; > > > > > > > > - return btf; > > > > + pr_warn("Failed to load vmlinux BTF from %s, was CO= NFIG_DEBUG_INFO_BTF enabled?\n", > > > > > > we should do better here as well. We should distinguish between "ther= e > > > is vmlinux image, but it has no BTF" vs "there is no vmlinux image" v= s > > > "vmlinux image is there, there is BTF, but we can't parse it". See > > > btf__parse(). We return -ENODATA if ELF doesn't have BTF, that's the > > > first situation. We can probably use faccessat() check for second > > > situation. Everything else can be reported as pr_debug() with locatio= n > > > (but still no CONFIG_DEBUG_INFO_BTF, it's meaningless for fallback BT= F > > > locations) > > > > > > > + path); > > > > } > > > > > > > > - pr_warn("failed to find valid kernel BTF\n"); > > > > > > and then here we can probably warn that we failed to find any kernel > > > BTF, and suggest CONFIG_DEBUG_INFO_BTF > > > > Andrii, you've basically written this patch, can I pass this over to yo= u? > > I think it would be great if you can finish thi, thanks. > > > > > Thanks, > > Ian > > > > > > return libbpf_err_ptr(-ESRCH); > > > > } > > > > > > > > -- > > > > 2.43.0.429.g432eaa2c6b-goog > > > >