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 41404C4829A for ; Wed, 14 Feb 2024 01:02:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B06A86B0095; Tue, 13 Feb 2024 20:02:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AB7A46B0098; Tue, 13 Feb 2024 20:02:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 956846B0096; Tue, 13 Feb 2024 20:02:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 80FC66B0093 for ; Tue, 13 Feb 2024 20:02:53 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 41A71C0605 for ; Wed, 14 Feb 2024 01:02:53 +0000 (UTC) X-FDA: 81788609826.17.56927A9 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) by imf09.hostedemail.com (Postfix) with ESMTP id 69C97140005 for ; Wed, 14 Feb 2024 01:02:51 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VhBQ9pGx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.128.53 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707872571; 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=ys+FQv4cHhRTNkKNZnsImn3WYfc3yYQguCKdDIqBhDY=; b=FW46jqVH2FPrKXEPv7RZFNbYbXqMVcNheiel+DisPSfi2tBKcZDzwgwK4I+LbrT5V2oYM5 kGfDl3c9HTdUKa3Iox3J4kuRwAwlHp3F5YdDOUGt6lSVuI5OL8a4xbpKolwLeOjdeAtyg4 ALNgxNP9ecg11A/cwxZz5sEBR1HpVsk= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VhBQ9pGx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.128.53 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707872571; a=rsa-sha256; cv=none; b=jDZdG6CP+Lil1GF5k4aXflgB94zcaRq4ZroxEq57ELQOgWHvbVYGRNIQcQA2Z5b56Doj8T uMaUGdsZvFpQOZtyys0rIlKRxe+XptIHiwJZgzNAWrbHDcX/oMG7e3EQIqQm40XMRmg+zC dvOHd6hhGqxkCVbTkq/4YJXwcU2ZJC0= Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-411c93e1cd8so1574675e9.0 for ; Tue, 13 Feb 2024 17:02:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707872570; x=1708477370; 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=ys+FQv4cHhRTNkKNZnsImn3WYfc3yYQguCKdDIqBhDY=; b=VhBQ9pGxB5W1HvyoXFFp8CTbsiHNIFsQ94W0Ks7EgG7chy8qIyywnFXHBoq+wmc3Y3 ff2l5VdMj2n/e3Vtpvkhf+o500YbOwHNd2iKQlgHZ2o4Vp+K2XFwR0C/sI39biuR/HMI pyzA1PpBXYKpbYeeJcdpi/FFwAffELYCOYfWtPmNvGJ+q/nKfk3vGbstAJuZ8Vk4mtjQ 3jYu/nIzIt16U6Vl0/25OBHasJdoprBdMYLm5aY0r6lMPa+BFO2C+dei2dKX+LADHGbR lfA/etxhtN5E/DahTYvRgVpYxmbzstO1idpbnjBDOdWDmefLbwgE+tajk9jjk0XxoY9a 63ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707872570; x=1708477370; 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=ys+FQv4cHhRTNkKNZnsImn3WYfc3yYQguCKdDIqBhDY=; b=I7JfFRcKEF3u3riEsqtO1N31kjZDzt6ZSN9WZ2yj36n2HzFTAQAXMj563Uasto/udp a6Det8mc9d7az1MBD2BSuyeo3q3iYmjY5RANmHS0zPmaDQbWZa4h/bWNUBQ2Sb0qfPDM qrvUphH7rXiJL8tdsgx+QjoikrShNAIVKUwSDE7CaHiwkZ3i4HNKDCc5Zli6R3/2h1pk 4Me5sFxLEfhYm+ThFwX7qjzgv1xsn9nS2/IkjU5admM7dtbCUj74ZtaqmkDvjAXX7KrZ 9rpTtk558pHPOAGeGzGXObFcIDKSnpC6j2Q4g9YzMTcQzwsRAIfXIsNmVBFSXdjFY/Ft D7pw== X-Forwarded-Encrypted: i=1; AJvYcCUJCEhpdtkacq2pNy4jYX25s94s27l3Ly5dE9R9aaCnvlm0esVADUOHEIjD6i4PkZBlpjZWSAxCS0qVgKir061U0s8= X-Gm-Message-State: AOJu0Yz8UJGQp4fzyP3lis1hhAfKXVzWLcd5mdO1pz4Ce4LMf/rpWRL9 T96qbjpjqmK+9oTVyqUrmBT2TkPQ08vylEAxWVD0qmWW374zM+Z1ZnFJiXRdxBZwlPHM4dRaI3R WMMDesE9dO00/KYw+yv0rpPfnAho= X-Google-Smtp-Source: AGHT+IHV+SVGA5NF/7QPEK4Ttn1/8o7VyqCtO5vXBmdGha6JCjy+FpATDjyvLQVHjcbRzgIle2TYS79aytqxb77ELV4= X-Received: by 2002:a05:600c:5107:b0:411:c8a7:7b6e with SMTP id o7-20020a05600c510700b00411c8a77b6emr320022wms.10.1707872569949; Tue, 13 Feb 2024 17:02:49 -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: Alexei Starovoitov Date: Tue, 13 Feb 2024 17:02:38 -0800 Message-ID: Subject: Re: [PATCH v2 bpf-next 14/20] libbpf: Recognize __arena global varaibles. To: Eduard Zingerman Cc: bpf , Daniel Borkmann , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Tejun Heo , Barret Rhoden , Johannes Weiner , Lorenzo Stoakes , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , linux-mm , Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 69C97140005 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 4wh79zj64x1ggmao57ht49cgr95yjjxh X-HE-Tag: 1707872571-353612 X-HE-Meta: U2FsdGVkX1+udIMvN3wqcKrLL7XCE+P08yoqUuq9KKSiNq6ADNJu6w5bWmTlCgkbfJatGYdnRgl7Q+4fuBMdF9mULEl6p/RVJFtLoYgJLsXpNJMOl0TxpCNMLSED7TVa/Cp6E0TADrIALdLFiFSc9z8ui0H0Jl/5Q49hLFCEYH7fGB21y+mJFsbjrMWKJeBIFzWbap2R11RJgPmsunyie4PBSy4mhT1JVJXbx8+3yMu++2gqtk2l/QOYgYajNoyppHDXiuXBZi2fKmMhUWmlaajjWdxrkWLQiU+mHFZUwx3IgU7IKrKvCkj+FL2/SwuFVk/pPSN0SlA76bwJOVRB8FzjkBloAjeIJoAgqbWdccsynM2aajnjKM5VvGCfhiGC5nbEnJAdYnevX6d4mSWI1bvU00AncNJOU7JIu4vvU/q/af4WLa7uadJi8LscNI6qVU981cMTHxZdmJW/2gkUYV/f/toyk4UgdInPkj4rsmObdWjmrv35rtYwuaPmFMsYK35JKySjsxdF+Dh8EqcxRMEpitmRmdxglvAyR8ilSPIRFMGux+kJrLchS/1AYDhADqWWy6XKYVQVmGKMDjfSBQHS4wn3tVHTBRWRxM54Wa7UWUMOy6IRDN+hH4Kc6UqVQrgZu2XBGvoSqbWISvFKyEWfgi2mdsLUP/e2nl7pfYOzm4yP3UogxQ2qp4BRzW7M0Hmu4NiiaTNtCKCzNl2ofMnOQJy8j3smvqHry976uuq+Mc617VgtyN2+Ez9u6b/Dy3Yd7zDz2PlXr3VJiVsdm8HoEjzf5TQBJASYererbeEvoVeO7L+S5BMkvPOH+vOBpcm5QUfurgNbX4/1y+FCwp0VHtCv613kYTPOdw9TrxMUm68dQE5qRshVKqLGJdA46HiahbgBwLSvlcmoLwTcv5bekAga/AfuoAn6Y0N3uQy2gelb7LEAvP+x+5j1y16ICk7KFkFKTjDxlJh0F/t MRTg/h+V DjS8BpGk0iGGHbWZQVwCCmf6vikS7h6Cgc+4K28a4pF7PH0hkWmj5HEpYTI8L6pKLySJRIkdSkxQYEp7upGFV4ZlEb7Sa3xcbO6ChdgTuhIzzQwiRqbr+CSkiqYJRud+Fq0UkjMgG0nsSDT+YmcGAhHcxG5Dnsg+OlhmPpeSqF2ka8twkCTTL4NAX0YkgSp9jLWs0bNFKRbyjKa9QblCncbCU8XviTm2QgvI2/zNzeozZDdSaMwFS4wDM5d5nMICp1KqvS4LmO/PmkCGcye9GbXu5oB/fd9ZhWsO1b4ALzk0b7X17jL1HjOt8n9Q2b00elGMtu9NWWpt3q6Y5RzthVf966u/FmYTPSfGWKmBs4wm8ZeYF1oqKaWQ0olfSc55ghJt0Dkpf8NwgV0//C7d9c/pP+F3l86Hg4Jtc5Exb94+lsjeNAVZBlJHAwMn1fD5Ik/JFZOVMm3XZ0vqWDbgBmHc1HBuuGSEBClEqW2sVITtGKwHfPluuw2/golQhrwKlRbvg8UQ1TBrpvzA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.005693, 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. > However, after trying to make it work with only one map I don't really > like that either :) My first attempt was with single arena map, but it ended up with hacks all over libbpf and bpftool to treat one map differently depending on conditions. Two maps simplified the code a lot. > 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? kernel gives zeroed out pages to user space. So it's ok to mmap a page, copy data_sz bytes into it and later copy the full page from one addr to another. No garbage copy. In this case there will be data by llvm construction of ".arena.1" It looks to me that even .bss-like __arena vars have zero-s in data and non-zero data_sz. > > 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? I wanted to place all global arena vars into a default name "arena" and let skeleton to use that name without thinking what name bpf prog gave to the actual map.