From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9634BC3DA4A for ; Thu, 22 Aug 2024 22:56:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F152880070; Thu, 22 Aug 2024 18:56:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EC4BB8005A; Thu, 22 Aug 2024 18:56:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D8C1A80070; Thu, 22 Aug 2024 18:56:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id BAFED8005A for ; Thu, 22 Aug 2024 18:56:13 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 4F9E7C08A7 for ; Thu, 22 Aug 2024 22:56:13 +0000 (UTC) X-FDA: 82481391426.16.ED50720 Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by imf22.hostedemail.com (Postfix) with ESMTP id 6F318C000F for ; Thu, 22 Aug 2024 22:56:10 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kwz2IzL9; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.216.48 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724367310; a=rsa-sha256; cv=none; b=VrQtt8iyims8TyWfHYJbvzgaAY0BIW1eeK1UCJcPaXRmtXa263P+6bSvkFMddFvkXr5/C6 iS8TpK3ENo8qom59E/yTht7JNTJeI/3ykTcwv3bRJ5aYd3TwcpZmrMI/vEd8MNSBZH8UGy PnwyutLbJdG673Z0ik0+rkbifLVTN5s= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kwz2IzL9; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.216.48 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724367310; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tjfM1tDPtzJW0CXat37/s7Shi6wDy4arWqqG5/O7u7Q=; b=UPjFvciaXFitOO5+itz9Ku3AhrU+P8AXBDhnP+ADLxAzDZFYWPQVo2VDknCfRpUsqB54Ig VP2jQlQFpW0JfJHnAquMBS+EnljV5S2YmCEHocn3E0vxA91deA6KmhfZvlxAGFq+4R5wRR 3XtPbiQ2o/aVw1+MitX8N+yfL/JzSA0= Received: by mail-pj1-f48.google.com with SMTP id 98e67ed59e1d1-2d3d7a1e45fso1018343a91.3 for ; Thu, 22 Aug 2024 15:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724367369; x=1724972169; darn=kvack.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=tjfM1tDPtzJW0CXat37/s7Shi6wDy4arWqqG5/O7u7Q=; b=kwz2IzL9Dmtu4eoVglcSUHQha1Wz8JP2P+ZfonCehA98yCVHGpo4RX72FLfAUYl9f1 6vaIvijdfsVaTHSv+Bbpub+u83/bhiLFhOwi5u0qh+nqS8s1wdhjTYyvwReoQ+NkHVKI iX/3XDQHP3qcBXkS6Fr5d584VAEL24/J1IjQKkg5MDrOfvc3x/CUEOT5DwDDUGWmLBbj zqJDdQGYnBJLz6FGGSPJkRyLUr/30GHAgc7J5EhHdkFqwyjvBo8+c1788FItazM5xoJW CuO0QWKtqjtZRbx14W/h676B4F7iVwYbFhlaS8P3CfPmA5jjbkO/JkLmjW9amp/+NZ/B WXgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724367369; x=1724972169; 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=tjfM1tDPtzJW0CXat37/s7Shi6wDy4arWqqG5/O7u7Q=; b=l3ZuBWNYeZDPR5lus8WjYB13+XAZcOIfGkuqOpTkVAafwVu/TEZTr9xzvAlBckYrnH c44zHxnAE/Dd8ArqxEZPzn8Crw2+h8fHKWKyBIwOHid8I13MVLDDiXHt1CMCB9oy8gyf 0GY1V2gYgrjsGNnXtwbcE9g6Vz4dTMdXw5hOjYzOOj/SpEQ+tLMgnUqa8+PJtD1RGLbF NCpf0qyzgHMJqSs7MsnNCxx9ABUP50NUbLGyktJ1iroQkP7UKa3HCipl+8wWMXn1k4oi po+eztrC0ku2lpD/j3EJ+DRzEwIS/y5q6DHccteSeH/K4rqH7zYiR3r379yLAHSSkkKb CHoQ== X-Forwarded-Encrypted: i=1; AJvYcCXSiVSWuySWAg5z+0NW9r9XSzqu2e4Fwc2okixnkWAJ2UN/JwIEZH4zJfw6Ch+Aho4+wDv+iFz97A==@kvack.org X-Gm-Message-State: AOJu0Yyu7exYn3+gpAh8RQIqPbCx0pFhygzLep6Ne+hO+8DD/lJUZ/uN VPAhBGQA3gP/2Wsjqe/Q+LXzJfoR9dt9woC6vx4Nv3S9cGN1FclRqXNcBsiHHMiFXrev/wY9HBb e77ZVmHMLsr50M5eWs2XRo3LxkYg= X-Google-Smtp-Source: AGHT+IE7BQzGG9IQdWyZ7CNB4himy3Vyu7t/fW6gQnY84i3UivtF8Mh5TAs94EbgeLdTO8xhY2RCyRCtGztl+0q9NHw= X-Received: by 2002:a17:90b:3549:b0:2c9:58dd:e01d with SMTP id 98e67ed59e1d1-2d646bc6dafmr228008a91.14.1724367369019; Thu, 22 Aug 2024 15:56:09 -0700 (PDT) MIME-Version: 1.0 References: <20240814185417.1171430-1-andrii@kernel.org> <20240814185417.1171430-11-andrii@kernel.org> In-Reply-To: From: Andrii Nakryiko Date: Thu, 22 Aug 2024 15:55:56 -0700 Message-ID: Subject: Re: [PATCH v6 bpf-next 10/10] selftests/bpf: add build ID tests To: Eduard Zingerman Cc: Andrii Nakryiko , bpf@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, adobriyan@gmail.com, shakeel.butt@linux.dev, hannes@cmpxchg.org, ak@linux.intel.com, osandov@osandov.com, song@kernel.org, jannh@google.com, linux-fsdevel@vger.kernel.org, willy@infradead.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 6F318C000F X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 3a1sxknc77u3am8pusaf6zzc4bpqwhfn X-HE-Tag: 1724367370-377135 X-HE-Meta: U2FsdGVkX18RgBJVW7vfNiYZQgZ4TdPGS3OJLjSlqoXkiZR4vvzYDUF+giI4V/YKnIJd0H6Tc4QxeCHm11wteBTioXqQt2CoVCltWwEKTWcD9JjVsYsOQd9Tl8st1MuSsJ2e1zjVk1hrYJXXhk4e0kcDPX07j7Ye9h0Zae2pBQpJhZx0gD4evXP+CpRN1F0umUIGPJwOZhXBW1njTNIo8gMeuuIzx5+xz6zx/E6oiIE59hkCdxdFrHm2gDVJJwn1vBNNgsT70KbpShmaaGSJznxEubARCEgVyO4eNzurJGbvj1EQadYei2LJLNe6K8k0+V3OvImpmRfqj7ITjyIaEmVSaaefiwSGZDIJ3o4VMJIYC8FgQXZ9NxxLC0B5RNkUfqTxbUNae3RXHThH1J8+c2M6wyTTEJ3Os5Lf9/TIz0F2aSyN60pIBWqc1+5zK2VPZdQkYgPZR4SaGve69x3o8pddcQXWJXX+UShk3KONIMVIV35h+VlXyAmfjZmkPKBTEdGYZUdJ7k4rFuDRDIAiTjoZOey1940AmCzgmsb/zskoEOsj4mR3Dvuj5oWFtJc9RWYOkxYRFULbsesFmmhV3JA1JWE0qOkki2wTIBeNg1bttb0LtUQpVvje3ROxWJNgPThXmx8usLX6BDW4zuo6LuTUL8arugJyy8ozsLUI524r8ahtcX1ojwCCPh9kBiw/1Zggrp9YF7TBV4yEEkiqBO0gOtmBAQk0ZJtH8DuOsJWLXWVzFEwqYclwVxKpLLL8XCR5Kifx40seoolSIxMVMNzYu6dfM0npQGuI1LVE/qYtAIrynJnWxTZgvaCQAjMGDMMukm5mzFBXWtEi3v8sb35WkfgGZtxiQPn44l9uKp4jEMtBvO2EP2N5sebfqXqcioNV1mqvhbS6u3qLWxXSqnxFEuKl2yR5Q9nBDG9s/s/XHe9i3UQKP6XTOLBsFKVzP7VyTtOsBZ7wBeX5ySy 0P5w8vGV G8R630tmhLBYOeHvS/YfH4Q8MJx9b8cUshCMGInM6Gx586HjEzm/Neak76ibAXUup72knCwl3xYwZXSL76tzxxo6EAsNBe7f75lCnFYOkKkcKvFhvvYFUsH3G2cAkl81NPg0dbxs30vlbnf3/27heOoo98GjBZrsIKO9CuHrEdV/WKnoRbJznhaBa8tbbgbajKbtHjWnFC6c0wCNy51Hqok73ENcAitG9/Elh+vz1HYu81wFq/4rLu/Rg/vANqdFaANmuXV26Iw0R3LtyYXuog+eBg8hlpDZhURLi8W4/6jp29HBmtmukziapJyzrqTwBIBl+jwffAY2z4x1yxotUecEb2iipoihOcLUOr6jAiMyxzd21Kf1bGZrd759KWw8ps6ysRoJCVBMLMBlJqDLL7YSKTyRVIWqaIQyWLD/Q23L1/9oUqagt27HN9TI1eT5BN+EynQASZCiFAEDObqLGT/nkVwzHnL9FkdwLOD6ZjHSMafg+mWSgnYf2AA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Aug 22, 2024 at 3:30=E2=80=AFPM Eduard Zingerman wrote: > > On Wed, 2024-08-14 at 11:54 -0700, Andrii Nakryiko wrote: > > Add a new set of tests validating behavior of capturing stack traces > > with build ID. We extend uprobe_multi target binary with ability to > > trigger uprobe (so that we can capture stack traces from it), but also > > we allow to force build ID data to be either resident or non-resident i= n > > memory (see also a comment about quirks of MADV_PAGEOUT). > > > > That way we can validate that in non-sleepable context we won't get > > build ID (as expected), but with sleepable uprobes we will get that > > build ID regardless of it being physically present in memory. > > > > Also, we add a small add-on linker script which reorders > > .note.gnu.build-id section and puts it after (big) .text section, > > putting build ID data outside of the very first page of ELF file. This > > will test all the relaxations we did in build ID parsing logic in kerne= l > > thanks to freader abstraction. > > > > Signed-off-by: Andrii Nakryiko > > --- > > Acked-by: Eduard Zingerman > > [...] > > > diff --git a/tools/testing/selftests/bpf/uprobe_multi.c b/tools/testing= /selftests/bpf/uprobe_multi.c > > index 7ffa563ffeba..c7828b13e5ff 100644 > > --- a/tools/testing/selftests/bpf/uprobe_multi.c > > +++ b/tools/testing/selftests/bpf/uprobe_multi.c > > [...] > > > +int __attribute__((weak)) trigger_uprobe(bool build_id_resident) > > +{ > > + int page_sz =3D sysconf(_SC_PAGESIZE); > > + void *addr; > > + > > + /* page-align build ID start */ > > + addr =3D (void *)((uintptr_t)&build_id_start & ~(page_sz - 1)); > > + > > + /* to guarantee MADV_PAGEOUT work reliably, we need to ensure tha= t > > + * memory range is mapped into current process, so we uncondition= ally > > + * do MADV_POPULATE_READ, and then MADV_PAGEOUT, if necessary > > + */ > > + madvise(addr, page_sz, MADV_POPULATE_READ); > > Nit: check error code? > Well, even if this errors out there is no one to notice and do anything about it, given this is in a forked process. The idea, though, is that if this doesn't work, we'll catch it as part of the actual selftest. > > + if (!build_id_resident) > > + madvise(addr, page_sz, MADV_PAGEOUT); > > + > > + (void)uprobe(); > > + > > + return 0; > > +} > > + > > [...] > > Silly question, unrelated to the patch-set itself. > When I do ./test_progs -vvv -t build_id/sleepable five stack frames > are printed: > > FRAME #00: BUILD ID =3D 46d2568fe293274105f9dad0cc73de54a176f368 OFFSET = =3D 2c4156 > FRAME #01: BUILD ID =3D 46d2568fe293274105f9dad0cc73de54a176f368 OFFSET = =3D 393aef > FRAME #02: BUILD ID =3D 8f53abaad945a669f2bdcd25f471d80e077568ef OFFSET = =3D 2a088 > FRAME #03: BUILD ID =3D 8f53abaad945a669f2bdcd25f471d80e077568ef OFFSET = =3D 2a14b > FRAME #04: BUILD ID =3D 46d2568fe293274105f9dad0cc73de54a176f368 OFFSET = =3D 2c4095 In my QEMU I only get 3: FRAME #00: BUILD ID =3D d370860567af6d28316d45726045f1c59bbfc416 OFFSET =3D= 2c4156 FRAME #01: BUILD ID =3D d370860567af6d28316d45726045f1c59bbfc416 OFFSET =3D= 393ac7 FRAME #02: BUILD ID =3D 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658 OFFSET =3D= 27cd0 But see below, for my actual devserver there are 4 frames. My bet would be that 568ef is libc. A bit confused why you get frame 04 from uprobe_multi, but maybe that's how things work with musl or whatever? Don't know. Check libc.so. > > The ...6f368 is build-id of the uprobe_multi. > How do I check where ...568ef comes from? > Also, why are there 5 frames when nesting level for uprobe() is 3? > Well, libc has some function calls before it gets to main. E.g., for my local machine: $ sudo bpftrace -e 'uprobe:./uprobe_multi:uprobe { print(ustack()); }' Attaching 1 probe... uprobe+4 trigger_uprobe+113 main+176 __libc_start_call_main+128 Note that you won't have trigger_uprobe in your stack trace until your kernel has [0] [0] https://lore.kernel.org/linux-trace-kernel/20240729175223.23914-1-and= rii@kernel.org/