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 6E075C4829A for ; Wed, 14 Feb 2024 00:09:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E650B8D0011; Tue, 13 Feb 2024 19:09:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E14D98D000E; Tue, 13 Feb 2024 19:09:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CDD9A8D0011; Tue, 13 Feb 2024 19:09:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id BA2E48D000E for ; Tue, 13 Feb 2024 19:09:44 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8AA50140CD8 for ; Wed, 14 Feb 2024 00:09:44 +0000 (UTC) X-FDA: 81788475888.08.39F2E15 Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com [209.85.215.173]) by imf12.hostedemail.com (Postfix) with ESMTP id B7C2340011 for ; Wed, 14 Feb 2024 00:09:42 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=XhStiQxD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf12.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.215.173 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=1707869382; 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=Sc+POPRYks5/J3TytxIqeVkOxSz7LgQaDDCDvOjAMPo=; b=wgcFqSEf6BZvj5Bs+Is0RzP7wzcKjeSEBioo6bG0XParPVBVzb5l0gz1iCJ8rMr5z6Z4TN 1FY9MFbzlffRdTdmWrxbDKFazVRTrZI7/lZROxS9LyeswsrLs2CvmDf9F8Un04yXyDyJAD 0ilsEqvDE+5q9gS6sNzX/RmNny+V464= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=XhStiQxD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf12.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.215.173 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707869382; a=rsa-sha256; cv=none; b=McSkOlV/cJEGVAUlvBnQxBwnGBo/tSii48/+rJ0m8MuW9DXhz3iFagSJVU/iUgDZ5mhl+p 6XHvtZlUBoYcEr6yI1fbn73RCkCP6M9UvTAzhAjM9nHC9dyF7jvlIyPBPdUkQfyfRFLQXI lAw4e1PDuIv4ZUGOwAcMGZRuGdpfsto= Received: by mail-pg1-f173.google.com with SMTP id 41be03b00d2f7-5dbd519bde6so3738562a12.1 for ; Tue, 13 Feb 2024 16:09:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707869381; x=1708474181; 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=Sc+POPRYks5/J3TytxIqeVkOxSz7LgQaDDCDvOjAMPo=; b=XhStiQxDNnk4tg+wwixhrbanDCn9WSMpniZxoZWZ1H4C3O/pvPCHA3hi83ttzAavYR 2jCGTcqFhBl7XUxr5RRSFIIL1SkqNWss3Z4LDFIGZuF5GL+aczXNPQtcTJ/NzfevsAaH PqAil68Afdh0yYKLkd+zrytDOZ9ZJZ+JfKkwSwjGENLJ+v5jTdtQWoSU/7tFg8jJRjUj ZTSI0NY8Grpy0iJ9ttYfGcyG6B6TW2z4meEJG2rcclN3m4NrgyUih/hBLiCR/gG/1T3G mNrNPENOwsOHErBXkpRaCdBi6VXZvZ7VuRw1kgMVBiTQDuzPwkvArPKMUm/4ttwshP1M VBfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707869381; x=1708474181; 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=Sc+POPRYks5/J3TytxIqeVkOxSz7LgQaDDCDvOjAMPo=; b=eWzOAsWNAuuOp/xAkw1JP3PlgMR0FdffhFXu3wG6r90oKXHCMPl+UUQ2NY/y0iajVE x8zd6yr2m1YB3PGJchaPUflre/yr0zeWECy+97eNRdIH5m8GgsZnOrSK4kRbFIGyKYLj Q99hlCUONQq51Ist+Q95CBmnPGSK1fqdv8zXWY8MgFhgGDyea+KC3iUR7S1hbMLlXMcx JhI5oBGlSCHgdqxoXe4ynpXnHyaf+u+wGggn0D1e+qJuKIB1rSYpdVcBU5z2Z+c1ZjKH LuRWG1Lf/tTxSSBJ7sqDfQDBUFY0PxPxq9RUIWYGeJ5DZ+gX61fJNJDdDWXptjGlIJDA y1Yg== X-Forwarded-Encrypted: i=1; AJvYcCVLu6ARi91Tk0Z1nC9qIhH21JlQFxxFGoZQ+ZCCwmb0REqGm4OloR4OOHkisGC197WdRWc1ctbbDOVjcNwf7B+ocnw= X-Gm-Message-State: AOJu0YzrmOCSUHNO7arNKrq4vufGM4a0wFdexnsf8nMgBE8oV68G9oBD PAqeBzsfcQwQOrfQkIiBeYaFD2FzYpnlrGcO76CimldL+K3iZ5B3dBphKR7Xw3rfPB17bpp1QRo hbtY4IynaamP27a8Xy6SouJWW+yo= X-Google-Smtp-Source: AGHT+IE+7bYy9St15MqHari1f1GMjYtMZQSxQrmJBDuCNm9gYVDVpqgJpBYAw9MRFCzBMhmnSH0tx2TiJkX6J3OlKlM= X-Received: by 2002:a17:90a:c90f:b0:296:111b:9f54 with SMTP id v15-20020a17090ac90f00b00296111b9f54mr1013278pjt.19.1707869381563; Tue, 13 Feb 2024 16:09:41 -0800 (PST) MIME-Version: 1.0 References: <20240209040608.98927-1-alexei.starovoitov@gmail.com> <20240209040608.98927-15-alexei.starovoitov@gmail.com> <7af0d2e0cc168eb8f57be0fe185d7fa9caf87824.camel@gmail.com> In-Reply-To: <7af0d2e0cc168eb8f57be0fe185d7fa9caf87824.camel@gmail.com> From: Andrii Nakryiko Date: Tue, 13 Feb 2024 16:09:29 -0800 Message-ID: Subject: Re: [PATCH v2 bpf-next 14/20] libbpf: Recognize __arena global varaibles. To: Eduard Zingerman Cc: Alexei Starovoitov , bpf@vger.kernel.org, daniel@iogearbox.net, andrii@kernel.org, memxor@gmail.com, tj@kernel.org, brho@google.com, hannes@cmpxchg.org, lstoakes@gmail.com, akpm@linux-foundation.org, urezki@gmail.com, hch@infradead.org, linux-mm@kvack.org, kernel-team@fb.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: gx56sww3znrjicjemh63fgid8gqwt4h3 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: B7C2340011 X-HE-Tag: 1707869382-979107 X-HE-Meta: U2FsdGVkX18BUj3oD9XCZWinM90LFTHUxBMbnVoOGFLld7W2AisGlTVRzWBnFl9GjoL0eyWA3ucx/nTuftXpJkby9WIWzG09gupJFAVSMCtEo3Ws3dF2xwcmRgGTBw+WJZMtnGgpZH+sOGmjAs5ndtWWEmRP5JlLk0B79Z2pwmOLtO3UgPm56WAztKGq8bRivMm/jnsW84iQqNeSucGU/sNZw0Lx1YgZuACdPAWKBuk4I2iOy68iw0ZlU32y9hgw/Mr2zT/uX96S648SIyl7X8l3QzUADpyfvmbBRCqOQ9shF0gd87qCBc+dUYOQdY5mxAidkeqelLB5wJeX9Zs79KufeKvP3wXgdFPZid2stx3jNbk8fGf7ISjA0el0bE2SqsYiIShTFxQzaTRxJUYwsu97Int/DEitJpYYDhFyXzP4J4jPRHcfnf7bOtS+W0vS6weK4984tvlheJoAdHYWBjB+as8f4Dmq33+0Ax+gpcnQs53XVHh0RBUmis6nnX7UWV2Mq9SaX8vQKxKYF1X9/1vll/RF4tpYTR179Uv/WEd2BG7byHKjXwkQAPTpx5e6l7GhXUPRRNMDa1KNov99LIS08xMNxiVpTknvSgJjzL0yQyFyjxiJ3+6HgHc3anF0pbFZM2hqouFUZZ6sM6l/VJbj/33Bvy6cETmq8D45ijozqNL9epgTg//+9LVfp46+zrRwjyx8M1zkyzftZESPPadNTkToV+ASf0odsIW0DooP9CgZTmSVDGx2ixtFiz49qBz8pC7eXEpI5Dn+swXK670Ln35ZFFLoGGjXEJel90mWYfq0N1PKQfKrvWJDBIxHlHVIn25+Hd9STbTrsgr2jvXc+isQNiXt4Ib6S2BDP767iVxSyb2rBkLx2AI81k+pHqAgXvArq+uul2FhmrmfkKL/dD61+x7LhPQaZ+iAjRJXVM+voxOZmmQcO9pxR2B2ndDCvbwihm0vU4nRIHT gVd5acMB eYrJV91zLGp/xDo0IB8F8RndRdKCPYmqAFtfLu9gpzMWSWhP2ECkydurjO5iCRGjqii/Iiw+2EJPFKleGZlZFnrbCvJsXw3fc4gUPvXpk8BmLQL5oOULwaVfYIqbc8vq/DRH5Gwh3zYQeNGGVLDJliS+FNzwFNd8SRrTYRtwwY1zzrdnvsTmi1LGpwG3Dru5xVe8KkuTnDJ/nBiDcpS+oQeuEo8SrKOiHUgwl67ANoInK/SfGkJZCD8Yo1n0m4K0ql8VTC9F8Eb4nHhd27kCs3nu7dLVO+kCrXPRxOWHkyersKkmxDfQ3Deki5WJjrbZTrqdS3dIPB8xVXfLuTG1QpvBJ5u6BrihSRG0Nw1GUtp0MScfh0vIJXc2m62iZN4dOMWJLWQtZVPlPd7rdJtZfFtRcl70ntERWi6DM2YRIncKEtJQnG4RiA6OFsP+qkDP8P9o2mOgSUc2TOTnQp0Q0yXxmogJDsKU51ha4Xbnwv4v/tuymq7et4cUUj1+4zyMBjmW+dGw+HePiuoA2oJ9tr3IQcg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.023470, 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 Tue, Feb 13, 2024 at 3:37=E2=80=AFPM Eduard Zingerman wrote: > > On Tue, 2024-02-13 at 15:17 -0800, Andrii Nakryiko wrote: > > [...] > > > > So, at first I thought that having two maps is a bit of a hack. > > > > yep, that was my instinct as well > > > > > However, after trying to make it work with only one map I don't reall= y > > > like that either :) > > > > Can you elaborate? see my reply to Alexei, I wonder how did you think > > about doing this? > > Relocations in the ELF file are against a new section: ".arena.1". > This works nicely with logic in bpf_program__record_reloc(). > If single map is used, we effectively need to track two indexes for > the map section: > - one used for relocations against map variables themselves > (named "generic map reference relocation" in the function code); > - one used for relocations against ".arena.1" > (named "global data map relocation" in the function code). > > This spooked me off: > - either bpf_object__init_internal_map() would have a specialized > branch for arenas, as with current approach; > - or bpf_program__record_reloc() would have a specialized branch for aren= as, > as with one map approach. Yes, relocations would know about .arena.1, but it's a pretty simple check in a few places. We basically have arena *definition* sec_idx (corresponding to SEC(".maps")) and arena *data* sec_idx. The latter is what is recorded for global variables in .arena.1. We can remember this arena data sec_idx in struct bpf_object once during ELF processing, and then just special case it internally in a few places. The "fake" bpf_map for __arena_internal is user-visible and requires autocreate=3Dfalse tricks, etc. I feel like it's a worse tradeoff from a user API perspective than a few extra ARENA-specific internal checks (which we already have a few anyways, ARENA is not completely transparent internally anyways). > > Additionally, skel generation logic currently assumes that mmapable > bindings would be generated only for internal maps, > but that is probably not a big deal. yeah, it's not, we will have STRUCT_OPS maps handled special anyways (Kui-Feng posted an RFC already), so ARENA won't be the only one special case