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 6B8C5C3DA49 for ; Tue, 30 Jul 2024 20:03:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE3806B007B; Tue, 30 Jul 2024 16:03:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E92AF6B0082; Tue, 30 Jul 2024 16:03:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D5AAC6B0083; Tue, 30 Jul 2024 16:03:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B83306B007B for ; Tue, 30 Jul 2024 16:03:33 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6426CA4C01 for ; Tue, 30 Jul 2024 20:03:33 +0000 (UTC) X-FDA: 82397493906.18.A1AE31F Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf26.hostedemail.com (Postfix) with ESMTP id 929FE140012 for ; Tue, 30 Jul 2024 20:03:31 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="bBPXYpG/"; spf=pass (imf26.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722369756; 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=Dy2vTUicnHvciea9CSXO+764BDpH/BVQTzGJckestek=; b=d5aAs3nAPvomnOUYn6sLXWMLmPpDmy08gsNoEdoyvrCc4hpnYqdE857RJfNxGxdQcyCYPH mkBePD0SDfaRBEZ5O8rndDrkJ0bqF98gJRcXjQmtxkS1rwPdnDnGdzDAaKLxDYkwK6jcCs tNPhWQrhrcF96IRmwdkZrna3CUB9Ksk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722369756; a=rsa-sha256; cv=none; b=c797PX8NbL800gs0/CykA/vyUl3/JzzokjWCsXgwzoz2J5psZCvAEBoHd1NGrHPgmAAvGe 6sS+rXNQ95AnqqBbxj9grUmC5ydYaCG+xRRmgoujR2RKZ0389MXjGLsesoVicMbz0qOQRg lfQTGGoCh0WSpyEL45yQZz+kAia++L8= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="bBPXYpG/"; spf=pass (imf26.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-1fd66cddd07so33742325ad.2 for ; Tue, 30 Jul 2024 13:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722369810; x=1722974610; 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=Dy2vTUicnHvciea9CSXO+764BDpH/BVQTzGJckestek=; b=bBPXYpG/VE70t9H3DVeokH/W632/WbjNed3VtTehBreYDY9uxK7dOtaZyGnw6nibYK PZoJTWYdWcutLXlDGiVwDD3S6NVMuH63WEfV1i2WXrI340PS2y41tMvjul104Hglp26u 2cGk2d5PUz/pfhI7AivxXVK70Yztk4H/RFw/1gF9+MVOolWVbB/JlTazCZx04y3t0/nz Gs9RYfiMdBoDMGkHoO3X0TDe+imPTWpFLdHQpWm4K7ckWzmtzzMO8ieZk0CAfdtnclcY v6ldc2mGr2KTiUUDpYvSrmsu2t2maVQOtEIyBb3DwxcIjedPA8WYIHXctqNy+3wWWrgr vNGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722369810; x=1722974610; 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=Dy2vTUicnHvciea9CSXO+764BDpH/BVQTzGJckestek=; b=KRj+AeqUfh5N4bnrCyePsc+G3YXsagurTw+WLwr/Hce98Yf5VeHL06dpdxJWRFLO4d T7SpSV35aosnkPLkUwmOQRXQjvo6tZeId6CdqPFxvbBDXL5yqN0CbBtbobzVOSpME7vz 6guMTikyiEeZCAMD5Ak+kRtn5QueaXepjXd4lqnuyCZy9yDxXrd/LcesAu29kO9sYjlv Qmb4OKYdb2fFCZ+Qds0mERDhjfWpm/g2pp6WLabh2ETXaZJeZlAzVyXHA3neA+SHGkIv zlYmG+5MQfHVEHrGl2vvCPZAh5K0j91AvNeAmW/NZyRtHET8ItxVZESW7iH2RH6kURC3 UGqw== X-Forwarded-Encrypted: i=1; AJvYcCVt/n9XlnY9hOGgphFALpUZ3fIKQbzbx1Xi8kGFvRQRC5UTodt4s2Ecczssmf2x2hvUEMkq1vZUSmNh1nzXRLP8NC0= X-Gm-Message-State: AOJu0YySwblGyv9rlA+2n6P1VZHkco+i5k0BY33tL+JXa3n5vOM9uHoN PslXGsp7+yedfYxkb8tBf6AgP1s6kCojyxJRWaezSJOOL6hV1s3Vvhv66gBujrFiYLjgVPiAahQ mjURQmh77aIgfl/Eq7C01xXcY4eM= X-Google-Smtp-Source: AGHT+IEvOjsZXQDGU8kRbaQAy59V/K7H1ZwkhbsU+r+qcbBiffGBSjzlXNMFzQv5WcAQE3q1OuTxf9cENGYJElH64EU= X-Received: by 2002:a17:90a:db95:b0:2c9:6514:39ff with SMTP id 98e67ed59e1d1-2cf7e5e0d2bmr10351002a91.33.1722369810016; Tue, 30 Jul 2024 13:03:30 -0700 (PDT) MIME-Version: 1.0 References: <20240724225210.545423-1-andrii@kernel.org> <20240724225210.545423-11-andrii@kernel.org> In-Reply-To: From: Andrii Nakryiko Date: Tue, 30 Jul 2024 13:03:17 -0700 Message-ID: Subject: Re: [PATCH v2 bpf-next 10/10] selftests/bpf: add build ID tests To: Jiri Olsa 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 929FE140012 X-Stat-Signature: 595czky641a8eitxgc1h5xcsjfrw16gb X-HE-Tag: 1722369811-201598 X-HE-Meta: U2FsdGVkX19A+lD1GNxDdrlCCIsTODObzAa6ue6WxnoU97ZTScq3V3xecIeg5ltGTYOeWKq/Bp18/XyJ/VtPewpDvAjVu3As6y0uARIcfJdpCv7QDU7YVth8FkZLTREGi4aHi89hnGNE58F5AXpdrDvFqMAjuZeFaroSAr/ckoyOGUKZBFpQrdNLdf/jQe1P5ZqC9UimyIkXrf7L3OaggY6OJkK0qYIknEkk+zi3GG366Yk3GMxpc9GI+T6xK/ADgmL4QNsxporJd55ki3j2MVhck4F138KeTP1hX+ZiuoapLEAFRaX1GeqoBP/RGxKED4rErglNLESdrMoAuricHS1F2Antj02lEIoArw4WNrfqZc+aZThB1TX5MII1DY9jtHs/4vobv8CJMQsYWLx6Q+yXSkDZ/EOUv1ANDvSNHmyuPEjoIcyHcWyhQLvZfGbnTACsTwxxvejnWEnzN5lc63KMykmdKCMl556C1RCaKD5OhD/wddAoyYzwMWoz/VT59BPl4s5QetMHmjlhF8H6tsp5D58Q/baHx4JLPtDkFAlm7SmZNhrkiApNHD1mzkv7Tzmz55ZNZQtxjPaB5wGSbC17e7o4/MLFONViEjDIfWnEqLu8HIwHBzfArZJVGMu/GmAYq7/40LCEO9b70EiNWKoVvjTC23aNcKM1wlCiGkCr60XNyUetu15Z0gW+Y0wveUnf+Qz4ATn9LN0YEb0d9r4c3ARHmEClk4zogWJlloCWfBrr9vI70lMv0r/+X/Qo+ZsCMTyH5pCwNcU2e4EsJzjYsNK4e/Cv/FkxNot3T1Uj7AYLcvGFfELHTIfpGrz8Q3pntQ5V8kw7IEH7X+xfqKlVaHSwwg/nQlyZcxj3YLaxnmDEYIBTW5GyxAFGheq+tqw6MEHxhthgLhZ55lrWkeIRPvAiiF+YLY6xkGEy77e9gf97IzM+hwG9CkXF8KHZ84RuXHp34lIXvjbGeII DAfhiWn4 ogAZG75wFhFDnpRJIEa7BLgfAsJjA0un72oUnqiVybHZHv53uDPooKWZHif9Ks6OTFVeF5UdfuozOEaHdHmGTMVbNt6jp44OWoRGMQVN+AJL4WgZmNzk/UcXE/kANpsFDsyMbq5rfTaA2ptkX98+ErSPA1ap6Z+Hcx7zdaYX1XvOFpsQaLWtIMdJ2k8IEIozZRjeOVHvLEudzJFDSDP9y9iRMPd9Ht2R9L7Myv3yB109skBtadGIgwFvKSsRINl+fHRu00LbnBfbErpzI9NHorwnKqRq4EchAXH1gZz+LuDU3V/gQ7yOlxlHmrXJ0EzcnDH21frQNUSipMK2vzS5fQqvYHbkIGaxQbvGANjV8ZmSJBiOfJF4o4RBLCRnpw7ZhfVVeO5l+wWSW+ObfacGbVERG7EG9ovDsWWar 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 Sun, Jul 28, 2024 at 12:38=E2=80=AFPM Jiri Olsa wro= te: > > On Fri, Jul 26, 2024 at 05:37:55PM -0700, Andrii Nakryiko wrote: > > On Fri, Jul 26, 2024 at 5:27=E2=80=AFAM Jiri Olsa = wrote: > > > > > > On Thu, Jul 25, 2024 at 01:03:55PM -0700, Andrii Nakryiko wrote: > > > > On Thu, Jul 25, 2024 at 5:12=E2=80=AFAM Jiri Olsa wrote: > > > > > > > > > > On Wed, Jul 24, 2024 at 03:52:10PM -0700, Andrii Nakryiko wrote: > > > > > > Add a new set of tests validating behavior of capturing stack t= races > > > > > > with build ID. We extend uprobe_multi target binary with abilit= y to > > > > > > trigger uprobe (so that we can capture stack traces from it), b= ut also > > > > > > we allow to force build ID data to be either resident or non-re= sident in > > > > > > 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 sectio= n, > > > > > > putting build ID data outside of the very first page of ELF fil= e. This > > > > > > will test all the relaxations we did in build ID parsing logic = in kernel > > > > > > thanks to freader abstraction. > > > > > > > > > > > > Signed-off-by: Andrii Nakryiko > > > > > > > > > > one of my bpf selftests runs showed: > > > > > > > > > > test_build_id:PASS:parse_build_id 0 nsec > > > > > subtest_nofault:PASS:skel_open 0 nsec > > > > > subtest_nofault:PASS:link 0 nsec > > > > > subtest_nofault:PASS:trigger_uprobe 0 nsec > > > > > subtest_nofault:PASS:res 0 nsec > > > > > subtest_nofault:FAIL:build_id_status unexpected build_id_status: = actual 1 !=3D expected 2 > > > > > #42/1 build_id/nofault-paged-out:FAIL > > > > > #42/2 build_id/nofault-paged-in:OK > > > > > #42/3 build_id/sleepable:OK > > > > > #42 build_id:FAIL > > > > > > > > > > I could never reproduce again.. but I wonder the the page could s= neak > > > > > in before the bpf program is hit and the buildid will get parsed? > > > > > > > > > > > > > Yes, and I just realized that I forgot to mark this test as serial.= If > > > > there is parallel test that also runs uprobe_multi and that causes > > > > build_id page to be paged in into page cache, then this might succe= ed. > > > > So I need to mark the test itself serial. > > > > > > > > Another issue which I was debugging (and fixed) yesterday was that = if > > > > the memory passed for MADV_PAGEOUT is not yet memory mapped into th= e > > > > current process, then it won't be really removed from the page cach= e. > > > > I avoid that by first paging it in, and then MADV_PAGEOUT. > > > > > > ok, I triggered that in serial run, so I probably hit this one > > > > > > > you did it with v2 of the patch set? I had this bug in v1, but v2 > > should be fine, as far as I understand (due to unconditional > > madvise(addr, page_sz, MADV_POPULATE_READ); before madvise(addr, > > page_sz, MADV_PAGEOUT)). At least I haven't been able to reproduce > > that anymore and BPF CI is now happy as well. > > yes, it's with v2 and I can still see that.. but only for the first run o= f > the test after reboot.. so far I have no clue.. I can see the successful > page-out madvise (still not sure how much is that telling about the page > being paged out), and then the build id code sees the page just fine > > attaching my .config in case > I wasn't able to repro this, sorry. It works very reliably for me with your or my config. Given it also seems to work reliably in BPF CI, I'm still inclined to add this tests, I think it's good to have that coverage. I'll monitor, and if it becomes flaky, we'll need to reassess this, of cour= se. > jirka > > > ---- > # > # Automatically generated file; DO NOT EDIT. > # Linux/x86 6.10.0 Kernel Configuration > # [...]