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 6B1BEC4829A for ; Wed, 14 Feb 2024 00:51:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E5E9C6B008A; Tue, 13 Feb 2024 19:51:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E0D356B008C; Tue, 13 Feb 2024 19:51:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD4C86B0092; Tue, 13 Feb 2024 19:51:55 -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 BFBD56B008A for ; Tue, 13 Feb 2024 19:51:55 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 46A34406D7 for ; Wed, 14 Feb 2024 00:51:55 +0000 (UTC) X-FDA: 81788582190.27.E854585 Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) by imf28.hostedemail.com (Postfix) with ESMTP id 7A8F0C000C for ; Wed, 14 Feb 2024 00:51:53 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jor2h1d8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.215.175 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=1707871913; 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=DC1nMc7pTknOKkwzDFTIRsHpNbe/6K187I4SurZ5w94=; b=nwVMOLWBKxBkO6s8RlH4QAAVKBGmdhZmKzz3RrQywa3Tg1MO6YRl05pUrwK6uyHwi9UoAg /TSMIeEMTccPf/h+S+WHBSX9iBD+37vMDGR7fXAxAVIn4oUZZ9oVZ2pKLGgVCMnTFb1YOm 0xbBPciaNlXk2yK3jOaZLmgbRqFpImA= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jor2h1d8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.215.175 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707871913; a=rsa-sha256; cv=none; b=PWwsal8cAa7GL7XwtCZ9CgUdgH53C9//PwYf3E9cJFFSQVBJ2vh1r4LulQFsDKB0650Fvm IgYyyLvnxe22FR6wLTpCIfWZkyOk4/R7Ggm52jbRE+5JsSbS4SBf8kCz8yNyPkFJRAlV2/ TFwo+eHZgw5bW5+OcRbl/u3KKWCR+6A= Received: by mail-pg1-f175.google.com with SMTP id 41be03b00d2f7-53fbf2c42bfso3708194a12.3 for ; Tue, 13 Feb 2024 16:51:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707871912; x=1708476712; 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=DC1nMc7pTknOKkwzDFTIRsHpNbe/6K187I4SurZ5w94=; b=jor2h1d86OqPiF/vaku8XmqN3DAQ4VsAEtgsq2AGauey76uOAAbovQDyWYQjZI12Bf CC1lbl2q7WRBqC7MsZiZuS2IjHJslKUV2RM1py/lq0XWr55Moy5ViBLi2OpvYbxEMjLJ Y7T0Wc/zBAXFLASKwOmzMYx3t/84p+Q3TWx3ULhfuQ5NvIVs3EN6ShAr6mgY00Vm7NZ3 Md1z18D8ZXSTftR7nrwrAMOYIbM56PUhmXy7c2xUmkn5P2nFzCoAi2AXnlIr8bqDbDzJ a8BylN3E2zCBTFaQnBivP6zYY9/uHrIRDV/ukj2LB+SO4wqBmwqT4bNE9bvbEFLQpGei iVxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707871912; x=1708476712; 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=DC1nMc7pTknOKkwzDFTIRsHpNbe/6K187I4SurZ5w94=; b=jgUrPzARSkVev/rizVvuZBHyXOI2/+L2MarIwiIoq0DiXCDVXCwhMPG/diNBH3OK9G aaezIAOX9rAiDQt9a+PLhOKzeEVkn2L/KJhtiQO1HAOGMZh5VnPF5TdvWm3clmcXU4C8 rLU3yN0YcvzlnT62iXQ466stKCI/VW5WdUPNblAqN6sEutLLlEfTnxyukcX+EuOA0Bjb YzoVEwEQKgbYIGF1tj0wwinCPG9Wr27DW03P7mp4wwADnm72XE2a8I5iwZHXLvqX0ASz bW/Qjx14Wv46urjSNqiVClUP+ere5Zh5l/coNIJypqKXkEy5L6qfpv6WzMlUF2NVhm5J T2hw== X-Forwarded-Encrypted: i=1; AJvYcCUH+C2BeQMVJ685qlQOAeWqRtlc4OJiITINyYujMlJBScUfmZO4ACLA8yAy9mHcNaDmA2beWQ2A2kYzf0YVfg2SX7Q= X-Gm-Message-State: AOJu0Yw8/3y3te/w3rwCAqMEbfWQt3tbGKHreIRu+meteDw2tzogGRrk GOvYq6DPxYtisSLDO/WZOkP/KFpicYyDrn8RNt2ifmha0fAvVd7gqFEvpxMSkzYMNv+rCKDmYvf vkhRIiTrdgeubWhKMOsturqQEjro= X-Google-Smtp-Source: AGHT+IHhACzmU3aQSLzC8/ggDCQIWh1793NT5PEgliUAYx9/pkD8SJ81Uqqc5deCHSGZXPeyHxcnllORnbLSfrWbjTk= X-Received: by 2002:a05:6a20:c68e:b0:19e:4e58:5026 with SMTP id gq14-20020a056a20c68e00b0019e4e585026mr1349286pzb.4.1707871912163; Tue, 13 Feb 2024 16:51:52 -0800 (PST) MIME-Version: 1.0 References: <20240209040608.98927-1-alexei.starovoitov@gmail.com> <20240209040608.98927-14-alexei.starovoitov@gmail.com> In-Reply-To: From: Andrii Nakryiko Date: Tue, 13 Feb 2024 16:51:40 -0800 Message-ID: Subject: Re: [PATCH v2 bpf-next 13/20] libbpf: Allow specifying 64-bit integers in map BTF. To: Alexei Starovoitov Cc: bpf , Daniel Borkmann , Andrii Nakryiko , Kumar Kartikeya Dwivedi , Eddy Z , 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: 7A8F0C000C X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: c6jmqmzk37cpjth4z9rexno61fx9ht3n X-HE-Tag: 1707871913-592697 X-HE-Meta: U2FsdGVkX19gdwUAu5YuG3KDgcLspqhXlw4sGk91Yz8w6s1/YaOiTmq3TRm9OpzQPOHJoyeXn4ZsqOZ+QwclWjQhV60ZRsHUcsO87mpMmbxhCqtp4jwYaQ5P69gaa2jupsSovHTtF5xpOsvVMkltAyIbpQUgMxJ+vcRt4y4j8TT9gKjqwLKqe3rfLGYaqE4OQeU60fA6sMdtgzE+37KpBrRxY6gCTvzz2leS1GbBDq9+td11Y3M81t2jI+rVPKrdHnCv8+TCevecF8xvANhY+u3RKKqOWfjcqBZPkjvtISZ1e0Qeq7gP0dtMpDV1aK9WT2UWZSfHTv+OE86U+pxeWZegvc7zBgPImjwYHC6jDn0I8Y1d1QeskE0f5abtfifVLiZm1CDmpGTRgnl4wsMX/sIV5lgULld0yN4MrRarKtUG0ERtQh6fadHD3DoP26kh62CAl2Rg8r6N0Ngtrdw2A/65I1u9ZBwPEhJjdjpxsuYSQcURuw6U3/aD0Gv9hC4GwnDDW1cqUb/KCFCHwTwNPgc93623EaH3OfCHaFGokA/q9hZVp9S0oQTqBHNbEwMHd9MXZTSSmLacz0e0LLKQ42hXGGtuR9b7UAHqrvo/uHLXvRI0vaw728C67ai5TZp8MDnRxZvYCyYR8iSL9idFMz/tWKaj9cjDo+/LqaJwinZWDGIskoDDm77Gj7VcRdQVyG3Lunx5W5Ex8snQdXl42hOmz3GQpKvXYA7TBfDMyUUCwJEHBsW4kFqJtLjyuHVL8OPKoDdtiMAdNbekpjNxPO/sBwR7eF6l0cMuu8JTjDa8lvYtVqxUGNRuM8KSWQoTZW/nhuIZ+QcUGR/oBhsYO5NWaJC0SHoc6hLSC8hb4M0qN+I1wE6v/0wUuwkShYVF68kFKRRkBUBxo4rgJbNtZdwGM1ZqCrs5RxZk1MZTjZB704dBhBiYcTxo/7h8Rpni5PEdRW+L5XRCv71r6/S dA8w2yXR Zc9mrUNNozMQuDXQ8X6/jdhnaoDdI+h0bFfMaIvjTXeIXGIseE80Wdv/ys1IrbjSq+Xw7xxEiCDL0SsaaeaapUnGag4d5HF/LVDo9aNVNWQ/+DCzLNLv6/pVGZqVTik2NHY+hgKlhKpd1badcgPXTYQ33IdIPmzM6vMSeprKiziDSc9Ws3KPvF8wv0XsdE9ZhIwOH+4gAyKFLvdKgghYE/qLffkQldXkWkWED4Nat9tykTuBUp3fvwclFbv8ih1DPfUuz4CuULs2gb/vp1ekIr2uoQOOkT7oo0TIphUx319NBljtOX3aIbNHrb2ojCAWewvvmvCgBxxAIBy1cUHeMOVXBvI8EDOblXiTyBAMN+OJsDNPuO6MYnH7LUiqBfyDy5/grsSi+Vwk8POmLE+B2FGQErKjDB2ddBcIEaF34gUp9YHEpJUMqQCfWjZFnXW1VwOny7SOwZVNGee3uHpqmaEXY6WSFxPbbYltPoo2Y8elNAoBYVeXRI2gWO7CVMnPJcMxRmnr5J5i4zCjhyNpq97tZ8cIXbmognee6 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 Tue, Feb 13, 2024 at 4:47=E2=80=AFPM Alexei Starovoitov wrote: > > On Tue, Feb 13, 2024 at 3:15=E2=80=AFPM Andrii Nakryiko > wrote: > > > > On Thu, Feb 8, 2024 at 8:07=E2=80=AFPM Alexei Starovoitov > > wrote: > > > > > > From: Alexei Starovoitov > > > > > > __uint() macro that is used to specify map attributes like: > > > __uint(type, BPF_MAP_TYPE_ARRAY); > > > __uint(map_flags, BPF_F_MMAPABLE); > > > is limited to 32-bit, since BTF_KIND_ARRAY has u32 "number of element= s" field. > > > > > > Introduce __ulong() macro that allows specifying values bigger than 3= 2-bit. > > > In map definition "map_extra" is the only u64 field. > > > > > > Signed-off-by: Alexei Starovoitov > > > --- > > > tools/lib/bpf/bpf_helpers.h | 5 +++++ > > > tools/lib/bpf/libbpf.c | 44 ++++++++++++++++++++++++++++++++++-= -- > > > 2 files changed, 46 insertions(+), 3 deletions(-) > > > > > > diff --git a/tools/lib/bpf/bpf_helpers.h b/tools/lib/bpf/bpf_helpers.= h > > > index 9c777c21da28..0aeac8ea7af2 100644 > > > --- a/tools/lib/bpf/bpf_helpers.h > > > +++ b/tools/lib/bpf/bpf_helpers.h > > > @@ -13,6 +13,11 @@ > > > #define __uint(name, val) int (*name)[val] > > > #define __type(name, val) typeof(val) *name > > > #define __array(name, val) typeof(val) *name[] > > > +#ifndef __PASTE > > > +#define ___PASTE(a,b) a##b > > > +#define __PASTE(a,b) ___PASTE(a,b) > > > +#endif > > > > we already have ___bpf_concat defined further in this file (it's macro > > so ordering shouldn't matter), let's just use that instead of adding > > another variant > > Ohh. forgot about this one. will do. > > > > +#define __ulong(name, val) enum { __PASTE(__unique_value, __COUNTER_= _) =3D val } name > > > > > > /* > > > * Helper macro to place programs, maps, license in > > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > > > index 4880d623098d..f8158e250327 100644 > > > --- a/tools/lib/bpf/libbpf.c > > > +++ b/tools/lib/bpf/libbpf.c > > > @@ -2243,6 +2243,39 @@ static bool get_map_field_int(const char *map_= name, const struct btf *btf, > > > return true; > > > } > > > > > > +static bool get_map_field_long(const char *map_name, const struct bt= f *btf, > > > + const struct btf_member *m, __u64 *res= ) > > > +{ > > > + const struct btf_type *t =3D skip_mods_and_typedefs(btf, m->t= ype, NULL); > > > + const char *name =3D btf__name_by_offset(btf, m->name_off); > > > + > > > + if (btf_is_ptr(t)) > > > + return false; > > > > It's not great that anyone that uses __uint(map_extra, ...) would get > > warnings now. > > What warning ? > This specific check makes it fallback to ptr without warning. > We have a bloom filter test that uses map_extra. > No warnings there. ah, right, forget about the warning, you exit early. But still makes sense to handle ulong vs uint transparently > > > Let's just teach get_map_field_long to recognize __uint vs __ulong? > > > > Let's call into get_map_field_int() here if we have a pointer, and > > then upcast u32 into u64? > > makes sense. > > > > + > > > + if (!btf_is_enum(t) && !btf_is_enum64(t)) { > > > + pr_warn("map '%s': attr '%s': expected enum or enum64= , got %s.\n", > > > > seems like get_map_field_int() is using "PTR" and "ARRAY" all caps > > spelling in warnings, let's use ENUM and ENUM64 for consistency? > > done. > > > > + map_name, name, btf_kind_str(t)); > > > + return false; > > > + } > > > + > > > + if (btf_vlen(t) !=3D 1) { > > > + pr_warn("map '%s': attr '%s': invalid __ulong\n", > > > + map_name, name); > > > + return false; > > > + } > > > + > > > + if (btf_is_enum(t)) { > > > + const struct btf_enum *e =3D btf_enum(t); > > > + > > > + *res =3D e->val; > > > + } else { > > > + const struct btf_enum64 *e =3D btf_enum64(t); > > > + > > > + *res =3D btf_enum64_value(e); > > > + } > > > + return true; > > > +} > > > + > > > static int pathname_concat(char *buf, size_t buf_sz, const char *pat= h, const char *name) > > > { > > > int len; > > > @@ -2476,10 +2509,15 @@ int parse_btf_map_def(const char *map_name, s= truct btf *btf, > > > map_def->pinning =3D val; > > > map_def->parts |=3D MAP_DEF_PINNING; > > > } else if (strcmp(name, "map_extra") =3D=3D 0) { > > > - __u32 map_extra; > > > + __u64 map_extra; > > > > > > - if (!get_map_field_int(map_name, btf, m, &map= _extra)) > > > - return -EINVAL; > > > + if (!get_map_field_long(map_name, btf, m, &ma= p_extra)) { > > > + __u32 map_extra_u32; > > > + > > > + if (!get_map_field_int(map_name, btf,= m, &map_extra_u32)) > > > + return -EINVAL; > > > + map_extra =3D map_extra_u32; > > > + } > > > > with the above change it would be a simple > > s/get_map_field_int/get_map_field_long/ (and __u32 -> __u64, of > > course) > > so this logic will move into get_map_field_long. > makes sense. yep, seems good to not care about int vs long here > > I thought about making get_map_field_int() to handle enum, > but way too many places need refactoring, since it's called like: > get_map_field_int(map_name, btf, m, &map_def->map_type) > get_map_field_int(map_name, btf, m, &map_def->max_entries) yeah, not worth it