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 0E14CC48260 for ; Tue, 13 Feb 2024 23:17:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9605F8D0021; Tue, 13 Feb 2024 18:17:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 90FE48D000E; Tue, 13 Feb 2024 18:17:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7B0868D0021; Tue, 13 Feb 2024 18:17:33 -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 672098D000E for ; Tue, 13 Feb 2024 18:17:33 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 398B4C099D for ; Tue, 13 Feb 2024 23:17:33 +0000 (UTC) X-FDA: 81788344386.06.4224EAF Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) by imf17.hostedemail.com (Postfix) with ESMTP id 7602A40015 for ; Tue, 13 Feb 2024 23:17:31 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fRGKnK06; spf=pass (imf17.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.215.181 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=1707866251; a=rsa-sha256; cv=none; b=rDBDru/lxSBGSp8SpjQcLSLPsQbhK9weQI9Jcz8tiE58Xq1youggqPl+GajJOCoMibJvgM SfpQ+EzgL16+QmQQdAwQSV922Wz5HSIP/c/c1kAY2QjVmLinUQTFT/s7TsIJlhB5Pugh1N Ou0regH+r8G4DqyVq0+zEx2kZ5dhDtY= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fRGKnK06; spf=pass (imf17.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.215.181 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=1707866251; 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=AXNoXahJgKT3A9li3QVZA0LVVCdDAN77s3vwawloBlI=; b=firg8pIsm5rwKU9T4sk5sDaGUD1DS3ocBZHFzQesSzCaZXhWyLp5km8MVKjDOOFn6JBd9P 1pwyBKZoV3BrvQoHO/EuPLWDQMIfN6wIBbyRQ7aLrIRBBzFZJV7PAbyf5sdrLvNIALGfc9 j0FVIK7tGl69i/hjXa6Um+7H/qSbmY0= Received: by mail-pg1-f181.google.com with SMTP id 41be03b00d2f7-5d8df2edd29so1058708a12.2 for ; Tue, 13 Feb 2024 15:17:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707866250; x=1708471050; 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=AXNoXahJgKT3A9li3QVZA0LVVCdDAN77s3vwawloBlI=; b=fRGKnK06gyKoXRklSa9fJlkRVM+wXvlG22YyVWQEVlNe/jDuapSOwAFfaB9TOcaBXi sEp5ObfdrGQIHOg1StNTyAS8T3h+CRQ/liEXsxnseDKfibnlEVdXPM0eMMOF+d7cUp8M 72rXBz1UquUphuPHzJqF6P+pmxWKOwPPVq6wExoSZJNFgg0rA2v4BXt+iVlxIymkPU7m fymvgPibcQVd8nHzdntLjt2ikHV/QpMOu+NBwjYU+wCYXRxWnn5FH+eWasHiuxQOmO5/ EGbTh1FuI0PPZstyrHw9jvPrvKMu7NGSRg4zfx1P1Y+4HyztfscbgXxmuVHsUnvFHeA8 VWPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707866250; x=1708471050; 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=AXNoXahJgKT3A9li3QVZA0LVVCdDAN77s3vwawloBlI=; b=tUv3Cbttsz/S3sHn1fUb1iW0dPPCaZGbK3OsoRMEsI+2pfybbdfF40LXleKIw2laN8 dZX9DH1d0OjsZYOQf/yP7slaXwcU33JKsUAxzLdi6nskO6H88GVX27V1ftdlUxbzpY3y YVuVZWMSMjoWGmRfwcw7ghkCI/rnpz5qMYRRj9ylbuJ74VZuNvXulWFd2wWj0K5TbU3/ bTqwlknrDPn2+N3HEfIIXz9s/pf5YU58bKy8NpALuaKj4P4uhBgsngkf+92Uf2vcjasE tVHFyWhHbiJabrREkCuZPv6atVXfFb1UaWXDqN/IPFq/2IiAhqieCmNPfP2j88Ui+zRI TRQg== X-Forwarded-Encrypted: i=1; AJvYcCVZ8GMmEHQbCWYKmxaSUmI8KOGuwjkO6Ue8leroEssCULyyzBWi6e897Ejvu8CY79649d32W9b4e38hQw0Gy3qK6+g= X-Gm-Message-State: AOJu0YwlRv4DU8NAb0dcBQzcwCPKHBxGm/1+JIOmpbgzq8D8ciB8MSnk BAq8p1zvPdGYWkPzNBq0UrwrmG57ifVvK13TKSaI7AgeccOX6YHrqeQs+kpL2PIu0Dygv30JGbC uf832flLA6vgueGONg1VlU4ZZX+8= X-Google-Smtp-Source: AGHT+IEjLkPcDBgJzniEjGPo/UJ0TkVCEgtlS++HdbCsP+Uop+HDjAQFrkEagfmJL1NP7IUiGfv4PM+1FKpaq/uP3I4= X-Received: by 2002:a17:90a:c4:b0:298:cbf3:3016 with SMTP id v4-20020a17090a00c400b00298cbf33016mr968245pjd.18.1707866250335; Tue, 13 Feb 2024 15:17:30 -0800 (PST) MIME-Version: 1.0 References: <20240209040608.98927-1-alexei.starovoitov@gmail.com> <20240209040608.98927-15-alexei.starovoitov@gmail.com> In-Reply-To: From: Andrii Nakryiko Date: Tue, 13 Feb 2024 15:17:18 -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-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 7602A40015 X-Stat-Signature: w6pzbpzjh7xd7a58wge4rymz3qrqjmg6 X-Rspam-User: X-HE-Tag: 1707866251-712297 X-HE-Meta: U2FsdGVkX1+Wsq7mAkXIV+kKVayIoNYyWsNvemG4PqnQvQn7BPRzKBFw0rav/0BLNC8a29Eqgu7GlN+JD7/S+yotqlVQ/thc8DIs5KiU6Ru6IaQ5JnRBpcmlwfQvpDxfmapF/85GzE3wUuhIO3es2ivWRfEzPtiBeaDgRoKDrylOyfuDOWtOc+Ye90+5omoK9UtyD6uvFqAStwKVGMTPeQF96SeTzkeE731qfUag0kaDV0qW1FD4Tuw9NjNnOvO9d5M1j2758dtLxESaG3qZXw70U2Y6JXzy+ENO+72gICt4/ZeeqvDr56kthNVUMlNv0Tl8UAHgrLPVpvJk08EB6BofvXyp14yE2nSfPqouVa1LRWHVdtnEVduXtZ+LNTAkzTxYwCTzhy07lDYsH9/JhE3f70pLjH8hLlsQHc84b5v7kbZCaf+wa4kMEjJe3QSw9ZpT9ZxYwVqEAPdZ+m39rACb1QpIwqXP1X7EJpcRQfuWgRaBEI29kKQzFy4GqwQS1mv0wP2njE36jPg1F/B5KBhuEUjvYLcULmHsnUcrMs7/sRMrGXNzAiAy+2sOVC+jRp6lWbJh5vlKgGhwBqBi2lE0sB2XilKWwI+ywhETJmvBCNARRGNgWVTLWq2UhuBbw9yQRnEI43zGqo0CSroCtp2xElKq97v3ZSw5lfN9XICtq+fTpyJOpCfT8PRZ4ydVKY7+0UhaPoF2pZGeMb1GIlMf2X5HXudLVsoFaTlVIy/vlHC62oECoGm8RZ2PhXcl3vl5IzGGEoNEXH6Vdi45ok6Kof179alwsaZJzxCmPQZU3znYOEzbQHUonYVH46+bN3ve3KkEXPhTCXL7VMyH9FSpV5zozOHy/dzzyF2zTBnB6Jf8JMKoghsLFpmwFGNgJScrKZmtqTYES7Wc/4e911si/B/kjZXAOIc5UavrOzDcrMFgVaSCoU3uuUUTi/rsDoHPMaetc5YJMRguQ8z kHxSN22Z THoe9dcksXS6IsEu6Mdf6QtI4uTchCD3z26fKoh7vjjKNktjyDeaTsj5MKkIvCRD6Xsh8zYc5PtfoYJoiblgZj58KTkNYIDrL+8Ib5LWmYhnmjgDbEGfs2vTGT2tP5cuLiAMvYQS3WUtAgF4ymidcs1+3UYocml9eKN950YLt/2vyqFKVUz/dcRw7wm/x/Mq83EunxZnRDp09BVqIl+0gf/ryx7s6FTeH9LXguyJAJgzApbfR4SRhLUeKYH4wG2Yi3UNEsJkPAqmS5TL8ADkSphm4a0oeuvjSrVKPCakEvhiOnV61gX0j0G/WUBDQnMkTP3A1bH/mTILLHuYT1LxQS817i/+rVMeuuSRE/gHBzEC24EMKBQjl17qqquRqx3Ug1dvRNfaIbmygDkxg2Xk8qS4eTGsII7lvl14F8BXm0GhItpB3ESKRLJejPyhz3drXkxeZGW59maCbHmOxCPRekOATOuRBnSsA34X6fRLktH+nGa6wYVc3yiiPtalXwOXaUpySgTAqtur2rzBVIZp5MAwgu0DcdWSwk3nAOKQpWJUBO5KUWO7pErQQPbDMO+GVNqFbTb7Yb6koK3HmVKDcfdaq0A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000060, 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:11=E2=80=AFPM Eduard Zingerman wrote: > > On Thu, 2024-02-08 at 20:06 -0800, Alexei Starovoitov wrote: > > From: Alexei Starovoitov > > > > LLVM automatically places __arena variables into ".arena.1" ELF section= . > > When libbpf sees such section it creates internal 'struct bpf_map' LIBB= PF_MAP_ARENA > > that is connected to actual BPF_MAP_TYPE_ARENA 'struct bpf_map'. > > They share the same kernel's side bpf map and single map_fd. > > Both are emitted into skeleton. Real arena with the name given by bpf p= rogram > > in SEC(".maps") and another with "__arena_internal" name. > > All global variables from ".arena.1" section are accessible from user s= pace > > via skel->arena->name_of_var. > > > > For bss/data/rodata the skeleton/libbpf perform the following sequence: > > 1. addr =3D mmap(MAP_ANONYMOUS) > > 2. user space optionally modifies global vars > > 3. map_fd =3D bpf_create_map() > > 4. bpf_update_map_elem(map_fd, addr) // to store values into the kernel > > 5. mmap(addr, MAP_FIXED, map_fd) > > after step 5 user spaces see the values it wrote at step 2 at the same = addresses > > > > arena doesn't support update_map_elem. Hence skeleton/libbpf do: > > 1. addr =3D mmap(MAP_ANONYMOUS) > > 2. user space optionally modifies global vars > > 3. map_fd =3D bpf_create_map(MAP_TYPE_ARENA) > > 4. real_addr =3D mmap(map->map_extra, MAP_SHARED | MAP_FIXED, map_fd) > > 5. memcpy(real_addr, addr) // this will fault-in and allocate pages > > 6. munmap(addr) > > > > At the end look and feel of global data vs __arena global data is the s= ame from bpf prog pov. > > [...] > > 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 really > like that either :) Can you elaborate? see my reply to Alexei, I wonder how did you think about doing this? > > The patch looks good to me, have not spotted any logical issues. > > I have two questions if you don't mind: > > First is regarding initialization data. > In bpf_object__init_internal_map() the amount of bpf_map_mmap_sz(map) > bytes is mmaped and only data_sz bytes are copied, > then bpf_map_mmap_sz(map) bytes are copied in bpf_object__create_maps(). > Is Linux/libc smart enough to skip action on pages which were mmaped but > never touched? > > Second is regarding naming. > Currently only one arena is supported, and generated skel has a single '-= >arena' field. > Is there a plan to support multiple arenas at some point? > If so, should '->arena' field use the same name as arena map declared in = program? >