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 842D9C3DA7F for ; Tue, 13 Aug 2024 03:12:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 04FB46B008C; Mon, 12 Aug 2024 23:12:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F1C6D6B0092; Mon, 12 Aug 2024 23:12:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D94606B0095; Mon, 12 Aug 2024 23:12:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id B76986B008C for ; Mon, 12 Aug 2024 23:12:10 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1A20D4059F for ; Tue, 13 Aug 2024 03:12:10 +0000 (UTC) X-FDA: 82445748420.14.D3E911D Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by imf19.hostedemail.com (Postfix) with ESMTP id 44B581A000E for ; Tue, 13 Aug 2024 03:12:08 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Dz7kzPdj; spf=pass (imf19.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.208.54 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=1723518693; 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=rTtnXF99PTHPF2ZHz6+Yl/cT93BFrIKnjBWBmoxYJ1c=; b=mpkw4Ze+m20/glfltiKBwGIhgyaTYG6xufRuZyEp36e4MFUj+rbdYZG+5tkxgMb71tjk7C ib8zXO6UCKX/DE/3qW/sA5983pxPgcBzpI2/0UG9AUtK47TI/oDUNAdvA0RmA3aa45PcPr wCWG+MBnsNziGPsmhst0fXjFSUz7Uxw= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Dz7kzPdj; spf=pass (imf19.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723518693; a=rsa-sha256; cv=none; b=oOrnbkZ/SgjBOFGudiKDdqiyy5gBzoBUmI58OmqpVdBgG5mRxnpH3F7vkefyXcVKa4EGQM fPEI1BTU1yi0Uidv8KG6/mfmXOXSSbUppt7xf9tdXml+eyx3jIUfrvdD/R6pphFQVJ4gZJ M/QVycqkMplQ+2vyCYIfhakVHBEazQA= Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-5af6a1afa7bso5910076a12.1 for ; Mon, 12 Aug 2024 20:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723518726; x=1724123526; 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=rTtnXF99PTHPF2ZHz6+Yl/cT93BFrIKnjBWBmoxYJ1c=; b=Dz7kzPdjk3Do3h3800pjxj8S3kIfDInHwc/cId1rUSt9u3rmM5W++Gu2+0ELjdE4nK 3MjCx8cGcfZ8L/AEDXndibhHAxJRrw3S8MXUzYuUPvO3PTIZJwOuhMmujLcjwaPkINqd XbKeutUweYuYKv5KE873EIHUgwQlEJ+m8sh+QgkjZRXWNcvgHcfRRM/sbS8qU+KDP+Xt Nqb33JEQeEvu/8+ORKLueS2EdnxHghgnkNM+94WIVZgDxIs8AQ44WgaJ3rSh5XyqqVIx k5/SxOh9aK0GDdzHWaQk03OUmikjBKWVb916qFzGArPXoKdRPDL40XCAfR7PNxwvk6R1 IxKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723518726; x=1724123526; 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=rTtnXF99PTHPF2ZHz6+Yl/cT93BFrIKnjBWBmoxYJ1c=; b=QJZmdjNYYj2Jb5fAn4LiBqUaPYxHE/zBi6QQ6yddHV0vD/cu/hjnwWxjWh71+HAjcX MztJlxXetspvQXLzcVzSlTI5m4RcM5a3HfQjVn1bBOv8Mkr7byzH1yLXJXnEvqSWNtel CUHLNgbIhOSiVxpVrS6sG56W5Wt5zeXHnN4gFp1YGJN0MGS2waEeLAGK2F0E3xFZ0FHX kZmDiTxWfgKAirWkYSU3q0ctDYvPyykMFYRH59cHX7j86PWsPNEP4zhgC4ELr6noJ2Pk VT25/1seS56XdQnpcaQtAR21u8wDYI4VZKuMBeqzKkng0pYH++zDfWG/Hna0vNoTQUM4 N/cg== X-Forwarded-Encrypted: i=1; AJvYcCX8d9XbYnNl21g4aU3yy1nGLAdi2pNflpMHyJjhphPKwmMj3zdou4yZTMMBFHRn00Db3nu4xQxA3J5n0XxdnHzRxHU= X-Gm-Message-State: AOJu0YyOa1DMMC+WP1ndLydoEo18Q2Rc6bVuO/e4nmPiGUQW5J2fvGqL WQFOgs1G5qTRqCOvhfIXY9ZZrpmwgqAmPbgqpx9zqngiKgiXS1Z6w6EOi+cwj7gx0QN2FEtAWFD L0GAbMWOGfcxFZM7arXKY5GM0NhQ= X-Google-Smtp-Source: AGHT+IGryIF97jL72LtObexbretu1TBnT67f9tiepatQNyfk+8+b+X25SMytGgrA2Qx65P6YIFaHKS/Oh3kTbZktFJw= X-Received: by 2002:a17:906:794f:b0:a7d:c148:ec85 with SMTP id a640c23a62f3a-a80ed2d1de8mr142537866b.62.1723518726153; Mon, 12 Aug 2024 20:12:06 -0700 (PDT) MIME-Version: 1.0 References: <20240813002932.3373935-1-andrii@kernel.org> <20240813002932.3373935-10-andrii@kernel.org> In-Reply-To: From: Andrii Nakryiko Date: Mon, 12 Aug 2024 20:11:51 -0700 Message-ID: Subject: Re: [PATCH v5 bpf-next 09/10] bpf: wire up sleepable bpf_get_stack() and bpf_get_task_stack() helpers To: Andi Kleen 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, 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-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 44B581A000E X-Stat-Signature: ax3tj96yqpbmq9fn1i1sm7ek6xt3yzc1 X-HE-Tag: 1723518728-866102 X-HE-Meta: U2FsdGVkX1/RdUfCu3iwz4iy7lGGXUC+Z1sdTpB/c1+itYLHJiF7Cs8hia5iaWWEFedLPfE0DAM2EcriNPPkiy/7NMWQG4kHlQ8qmQT2PGRSKNWRGA1LWFwrrxgIl0MaJEp+J3+gisL1QE8slRkCXWg4KFjAo+yfr6wa7J0yE1TNTH+mCv+Kd0Bl+Q/ClpEpFfg1gNUhAJFaTWGSr5BxJBlgnObC/sUV3CTNu8fCd1ZmagEqXlCQ2+vjjtq81T1zfY51Gl6SJQ9SPRgcFNOWwq15VrCn6qfG/DDHZAxtsJhPRMtH8ia/zt7Y/NusZgKzWs2Xi9VfjC98EuV1y745S9k97LHlZCflE1NTBRyZtVdUKIO0tLlVq/wEEImiYjHhrK/gdFl4JO8jk53ItrOfjVIr88QHeG7Ia2H12HseLZYpg4WU/nPENebjUZ04wGCH7E35ImFrP3ScDmphjTycUF1Nzz+Xk3ZyNe9C1fc9Xih7UbFsP1VtSDBf6Ad6LB68W6C8mi9bwWnZ8ZuqhIfNGRVT3F5mcBoFj7Fp917I9UBXgKrGgLSDFwCM9QJzjBGOvdvHrq/S+4jxx9VdSBZgosAPH6ZeiobXyAlTZZdkgEregjLfEa5bivnCUA4rsM7MVepGPUlDfVbpGUlg70H2y2EEeuHPwB1ULKmX8fCFYnWLlOvjyjtTBckMCzIg9qxdWPN8/RkvaDtxn/muPdbLW6CImzkalLCkDF14xeRP6sBSKqI0BODoz3EcGH5L1Rz6KmyA+pfaXy+gFtcsWrk1tZMsh7t6Ud9fDA02cdW2PBKkbKkGoZcn/bKTrUqgBCKmdHR1JE6jWCpJ44qevg4o5/vGck3pb6INN3fyfEE4OxkehcfEH0EZmmw/pkYgU5kGVdPpfkb/m8MmE9QzQGaiPnTRe02s/usdtMuJiHor/Br0pJ8WaZRyo+3MeLK14ZxoHZvBUOF84lC9hnJktV/ yZAFlBHG fBepbEnFDq3xwYFxuOiiG8F+RPXRfBwxk0Spwl0+yO3oHjrGbQP8kMBqbsqCv6tc4tqa8j0fCBZ4vgncNsMfLdQt3lVCsdMNkHNBR+FvZX7YkRCfXmIropCbJOEmiicTr8XdDr+N91W9iX5tjJR+HhGmhU1qfqf5Xy+daVXbu76VlJrjFAUO5Sap0tV9uY1o7We0zQ3LLJYlkSXMYU+fQtP9NUomeCcZJcxpsY87XwYZ7XJ4MVcKLfHkAZpBu7S11clzJSFMK2G65UrO8E3c4FQhTW5nMpPZAmBkvxEOojmB1gwyern7P5wh/DZGjD6B2KWYA62T+Z5dTNNF2E/KUMZUYvaTn7NjMy/oIda7IvYs+ZD8vm1x0/HNpIjmjvUkysvYaVGgL7ngOmii0GSZ/dHHjhA== 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 Mon, Aug 12, 2024 at 6:05=E2=80=AFPM Andi Kleen wro= te: > > On Mon, Aug 12, 2024 at 05:29:31PM -0700, Andrii Nakryiko wrote: > > Add sleepable implementations of bpf_get_stack() and > > bpf_get_task_stack() helpers and allow them to be used from sleepable > > BPF program (e.g., sleepable uprobes). > > Is missing the header actually a real problem you saw? It's hard to quantify this from production data, because there are multiple possible reasons to fail to get build ID in BPF program. All of which will result in "no build ID" condition. But more generally speaking, failure to read some piece of memory from non-sleepable BPF programs is a real problem for a meaningful percentage of cases, so being able to do that more reliably in sleepable context is important. In this case, given this build ID fetching code is used from PROCMAP_QUERY ioctl() on top of /proc//maps, it's good to have a guarantee that if underlying file is a proper ELF file with valid build ID, that API will return it. It allows applications to avoid overhead of retrying it through other less reliable and more cumbersome means. > > I presume the user tools do have a fallback to read the > build by themselves if it happens > It's all best effort, strictly speaking, but the percentage of successful cases matters across the entire fleet, so anything that can be done to improve the success rate is helpful. Retrying is possible, but comes with extra complications, which are not always acceptable. E.g., it's just racy (application might exit by the time we retry), or will require extra privileges (because user space will be accessing entire ELF file contents), etc.