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 E728CC48297 for ; Fri, 9 Feb 2024 19:00:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 573606B0072; Fri, 9 Feb 2024 14:00:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 523236B0074; Fri, 9 Feb 2024 14:00:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C5586B0075; Fri, 9 Feb 2024 14:00:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 2742C6B0072 for ; Fri, 9 Feb 2024 14:00:15 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9CC9EA2873 for ; Fri, 9 Feb 2024 19:00:12 +0000 (UTC) X-FDA: 81773180664.20.0E2E4F7 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by imf20.hostedemail.com (Postfix) with ESMTP id E4AFD1C0013 for ; Fri, 9 Feb 2024 19:00:10 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kt7hHxVy; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.43 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=1707505211; 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=smNwYLt+u1Cm9MC8hNC+SwZPa650eVtwDGnMkvsD+dc=; b=H8CD5bx4KINVc0vvYJQ80Vtxz9Xa5FnBm5Td2tLv+zLSkCbIkCDh03FZ4/sEB5sNRqTMdM eOzZG/gXxus1xHJSTEcRmzrtFLuFpxK+aUo8w8JrKrPcxK/E9HdbUddRCFVwMnUduzbwXs c7SMxeBi3HpHMLcbArxrGv/Vy3P6gL4= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kt7hHxVy; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.43 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707505211; a=rsa-sha256; cv=none; b=yWsbYYhekgYuqNYVkcrbKyb4OFkmvO+E5+sFJbTx2b9oHBj4EPl2LOS3RUni6aKlz+TTqt aiBqsxOcVp9ZwGj/O3x/+D/wLXFellsJ8EthUlIori4xNFcAraKVSKzK9o6z0L6u3G8Pnp b83l0i6FTxNCviZaq1AYjUoOeujvLyQ= Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-33b29b5eab5so627321f8f.2 for ; Fri, 09 Feb 2024 11:00:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707505209; x=1708110009; 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=smNwYLt+u1Cm9MC8hNC+SwZPa650eVtwDGnMkvsD+dc=; b=kt7hHxVyFXR5UXvF/GPr4VsdpMEHj+s6NRvcf9ZCZjqpmmuHnqvNCa5pvoRvvvI7Zt hHfjQUQaGMdqhLveCfzARYd0GKuxKNh/lv+79VuxQfpP5tGS3pWxyRrJFMPoA24uMDmV V1aF5ua6LzZhTeBvkNhg4xtWYSoo13v++FyJ2d0QatRgFRtiwUTdwz0MikT7hPFF1hrM ZWCa3/oZw4onGluBk9ckUmWQNEPjkyRtcYqwkX2rTkYyF8iqrTA3XhSNIgkyKbzXjpvO xTWbVB+ZFu9QO6NHt5cREjGMdfFpdFqaJR6o5/gha1ww8ZdRYuJHgCXzQS+ghGhOruMs 6FgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707505209; x=1708110009; 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=smNwYLt+u1Cm9MC8hNC+SwZPa650eVtwDGnMkvsD+dc=; b=hkA+4IbCS8KUwLWWHzJSELXUxL/j71qndCDSHgd2sOo6RENuywpQ5o/3x+2r4Qxk0Z KYeXxsyamg5kfXc+QkzbE+dIR5eBFwFGdHZh8YNtfFoGjG8s5/rFfwCqyjYnI2WJwpjn m7ROO5+ttEsKX+ywEIk7oI/O+1zrXdhMzoRNaQug/fcOVmOH64ZMdGsaoRIb6/euvCrC GsH9kxYWnlQwytFNBVoFbk6uGDx3J1BvU2HEu/aMFMZNu6noaZRnUBVIzcZkM5kJU2Uy qtASvQX4E+pDneBvoiMIC1T//UB7JzYvWnyGvbNv/UEFEvs9c8JVdTuhdriIGGWCzshl Nszw== X-Gm-Message-State: AOJu0YwLdQrTg87C3/k8VO98UEj8CP7YRw8RVuobsMAPSa5c5UkBq1nM wwDyjg1H3Sy8lJnfkRwdMJYD+gjxnJh9BYxoF0f7ZlLu4POT/e51RLwpfOPwAns1D3ostBU/kDM pcyLCy6l73DgqPedsMOL2vWDy9C0= X-Google-Smtp-Source: AGHT+IGI7oxTbV992uv5aSPiXKCc8DxS+VIVKigmITHg3SGGFhAZXsOeyex5sH/m4hTtfSlUcM7dTV54S5ZIm2nPuNc= X-Received: by 2002:a05:6000:1aca:b0:33b:68a1:c71 with SMTP id i10-20020a0560001aca00b0033b68a10c71mr879070wry.18.1707505209000; Fri, 09 Feb 2024 11:00:09 -0800 (PST) MIME-Version: 1.0 References: <20240206220441.38311-1-alexei.starovoitov@gmail.com> <20240206220441.38311-3-alexei.starovoitov@gmail.com> <20240209165745.GB975217@maniforge.lan> <20240209181136.GD975217@maniforge.lan> In-Reply-To: <20240209181136.GD975217@maniforge.lan> From: Alexei Starovoitov Date: Fri, 9 Feb 2024 10:59:57 -0800 Message-ID: Subject: Re: [PATCH bpf-next 02/16] bpf: Recognize '__map' suffix in kfunc arguments To: David Vernet Cc: bpf , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Kumar Kartikeya Dwivedi , Eddy Z , Tejun Heo , Barret Rhoden , Johannes Weiner , linux-mm , Kernel Team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: E4AFD1C0013 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: ai9dxxn1bcf7u4s4fqdecqq51e9yr45b X-HE-Tag: 1707505210-713766 X-HE-Meta: U2FsdGVkX19sBcMEcb4Tuyle4PHPFthCJOO79tCXQ4O1rK3BO7usIYSWm4Vl4FK3TqcMS+73RalE9GZRbKcCe3h87q4mMOTxTo6wjGYb/BXmhxsqEv5q/9GQHBSqnG+6xI4CLjczHckGKrX0O/73GvlnJojeviAZBG+6iejNua9a2etxXAychjbF9oqGuN4RNVx9oZIaFuBvAJ8M7OLhLfG/O9GxFTjSW859OcmOy0JUNT5Uk3x4BY17vi2MAx/CqHfakPPjTxpfxB2fgiNehzPWXcTd5aC2JxbkeCvGXjy6ukSb1rrqe2OfhvhgkGuibElfi7uVxHk0inBE7Z4wwc5BEE6KD9qYbD5kV9xHoK/cp9MSO10k5YBEOuUXwtkOyVcBizNu0f0K0IriE/oNK1YY+qj7wsAp/Dr2G0xx0mSEa44tiULsMTDaaYpTtvGvKBa+Xwl+NpzitozTYCwnG263FpQYI/obZxlagePRoZRnXUpbEt8VlD/wtFfz7VOeOS6iKZ7a1gA6XnuGcn5Aa08SS5UpYyaTsI2/VvjUEfhnjvM0OjmST2IcNYomqqiU4DY+8Ao03sQhuz56OPlxfhjsH0h9JS5hlL1ygY7WVUEaGUGXqFT+HyPSkrsaUoDBMagtTqKe7u2ofGaNmgE+iTRxFcuKomntVhqZJc4RCg/NjOyIOaSG6rNRtGTFQCCJT51GnMenpvZjJPO6pki0uBF/Ho6xUca5BVfw7ivK54eH6YZr0TocstOcPleT8yNGMWg3yKNz/nRMRJZ+PVRWePBIHI60SgLrN2x9yoGw+NMJGAI6aiVfDLuD82/sjjUWAm7TgTyJD+XvT1mjM50AOGPtI9BtltOhX8P8mFVkhYhTZr/2rH7o+ZhFrW8qlZq5Drf7DnJ80ayJSRNrb41A/+UE2oRZhN8lV3wd6Daf4fPs3HkS5Kx2zgKorrbt+xoXL2vmOfBpSD07qUtG5kd od4vbln+ 10CB6TMIlD1KENUNhKSS/y3Z9v7+mFnOxe7iSXRo/ZNwmlkBUdK2wran9fS5yyaTEPJmYaL3BfzpvXNLKOyQ0E6NHG6QPyuieiyk9IreIWZ2mvDVGio971zwcww== 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 Fri, Feb 9, 2024 at 10:11=E2=80=AFAM David Vernet w= rote: > > > > Makes sense, but then should I add the following on top: > > > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > > index e970d9fd7f32..b524dc168023 100644 > > --- a/kernel/bpf/verifier.c > > +++ b/kernel/bpf/verifier.c > > @@ -11088,13 +11088,16 @@ get_kfunc_ptr_arg_type(struct bpf_verifier_en= v *env, > > if (is_kfunc_arg_const_str(meta->btf, &args[argno])) > > return KF_ARG_PTR_TO_CONST_STR; > > > > + if (is_kfunc_arg_map(meta->btf, &args[argno])) > > + return KF_ARG_PTR_TO_MAP; > > + > > Yeah, it's probably cleaner to pull it out of that block, which is > already a bit of a mess. > > Only thing is that it doesn't make sense to invoke is_kfunc_arg_map() on > something that doesn't have base_type(reg->type) =3D=3D CONST_PTR_TO_MAP > right? We sort of had that covered in the below block beacuse of the > reg2btf_ids[base_type(reg->type)] check, but even then it was kind of > sketchy because we could have base_type(reg->type) =3D=3D PTR_TO_BTF_ID o= r > some other base_type with a nonzero btf ID and still treat it as a > KF_ARG_PTR_TO_MAP depending on how the kfunc was named. So maybe > something like this would be yet another improvement on top of both > proposals that would avoid any weird edge cases or confusion on the part > of the kfunc author? > > + if (is_kfunc_arg_map(meta->btf, &args[argno])) { > + if (base_type(reg->type) !=3D CONST_PTR_TO_MAP) { > + verbose(env, "kernel function %s map arg#%d %s reg was = not type %s\n", > + meta->func_name, argno, ref_name, reg_type_str(= env, CONST_PTR_TO_MAP)); > + return -EINVAL; > + } This would be an unnecessary restriction. We should allow this to work: +SEC("iter.s/bpf_map") +__success __log_level(2) +int iter_maps(struct bpf_iter__bpf_map *ctx) +{ + struct bpf_map *map =3D ctx->map; + + if (!map) + return 0; + bpf_arena_alloc_pages(map, NULL, map->max_entries, NUMA_NO_NODE, 0)= ; + return 0; +} verifier log: 0: R1=3Dctx() R10=3Dfp0 ; struct bpf_map *map =3D ctx->map; 0: (79) r1 =3D *(u64 *)(r1 +8) ; R1_w=3Dtrusted_ptr_or_null_bpf_ma= p(id=3D1) ; if (map =3D=3D (void *)0) 1: (15) if r1 =3D=3D 0x0 goto pc+5 ; R1_w=3Dtrusted_ptr_bpf_map() ; bpf_arena_alloc_pages(map, NULL, map->max_entries, NUMA_NO_NODE, 0); 2: (61) r3 =3D *(u32 *)(r1 +36) ; R1_w=3Dtrusted_ptr_bpf_map() R3_w=3Dscalar(smin=3D0,smax=3Dumax=3D0xffffffff,var_off=3D(0x0; 0xffffffff)= ) ; bpf_arena_alloc_pages(map, NULL, map->max_entries, NUMA_NO_NODE, 0); 3: (b7) r2 =3D 0 ; R2_w=3D0 4: (b4) w4 =3D -1 ; R4_w=3D0xffffffff 5: (b7) r5 =3D 0 ; R5_w=3D0 6: (85) call bpf_arena_alloc_pages#42141 ; R0=3Dscalar() the following two tests fail as expected: 1. int iter_maps(struct bpf_iter__bpf_map *ctx) { struct seq_file *seq =3D ctx->meta->seq; struct bpf_map *map =3D ctx->map; bpf_arena_alloc_pages((void *)seq, NULL, map->max_entries, NUMA_NO_NODE, = 0); kernel function bpf_arena_alloc_pages args#0 expected pointer to STRUCT bpf_map but R1 has a pointer to STRUCT seq_file 2. bpf_arena_alloc_pages(map->inner_map_meta, NULL, map->max_entries, NUMA_NO_NODE, 0); (79) r1 =3D *(u64 *)(r1 +8) ; R1_w=3Duntrusted_ptr_bpf_map() R1 must be referenced or trusted