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 A23C0C48297 for ; Fri, 9 Feb 2024 19:09:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 30AEA6B007D; Fri, 9 Feb 2024 14:09:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 294086B0080; Fri, 9 Feb 2024 14:09:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 111296B0082; Fri, 9 Feb 2024 14:09:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id EE9B96B007D for ; Fri, 9 Feb 2024 14:09:44 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BB0651607CC for ; Fri, 9 Feb 2024 19:09:44 +0000 (UTC) X-FDA: 81773204688.20.AC937BA Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) by imf25.hostedemail.com (Postfix) with ESMTP id DFFB0A0015 for ; Fri, 9 Feb 2024 19:09:42 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=KlEbXtxN; spf=pass (imf25.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.216.45 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=1707505782; 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=Gfi9NXSP27W7xzdgjy1gcdrDzfjGK7X9xfN2JFwj2uk=; b=6vlV5hZm3aBMTUYC+6ElfGfEOfMqZiFeDPjnARNtwwEG66CzWfuB/k4PFmkb5kWxnuoXnd rtpl65dFJX85J1vDByClkJ7Zhp/UAP/rAKLBOliKPoxEVWkVoDy55oMX2cHsu2n+ijMEhw 5dgqRfBPf7vcDui4A5o1FU0DLUDbT+M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707505782; a=rsa-sha256; cv=none; b=2JauzycPgMp6r+yf2KnGnsbX/77BY0eLvCqKsSyagIN32PGAHaJ2zv/aQMJ5VkNL5JKTEQ m5PPAb2DYkOs7e1S+5eGjsv3IoRf+Hklohz/s79IC5WAkChTA8+W1kK5b2Zdv1u1MTYFnt wkiTjIIoM2VHz6CBnv2IDjdj4xZ7xjY= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=KlEbXtxN; spf=pass (imf25.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.216.45 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-f45.google.com with SMTP id 98e67ed59e1d1-297108e7001so444234a91.1 for ; Fri, 09 Feb 2024 11:09:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707505781; x=1708110581; 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=Gfi9NXSP27W7xzdgjy1gcdrDzfjGK7X9xfN2JFwj2uk=; b=KlEbXtxNKk+OE1TEpHujxm/ZC/mZ9U55xP6RMC41MZfeiGL7ib8N9VFv8VMAQn3heJ rX9Wr3p8esgvfiFP1y210ZJYbgmHAPyIlzbpl3qvReKtG6ssA+KOdM/9qiuCtiuvvFAl C1uZFWWo9c7Ay5MXRp4yft3y6Tw+D+WKNRKa8i4+RiM3LZa0b3VtEnJ0VPk0vrhIY8Kl ohK41Ufh/SZahPUvLdk1nfgW39QK4m2dVfgYVV8STFRdQSWkKE1/dn4f/bUF7Ie/kQtH 4B6c4uZ3dvub0wDHRu2+Y151uQD3mfW187oVjzIdcMnYMMF0PuclHlUc08RVZu1BZZVF 2gyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707505781; x=1708110581; 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=Gfi9NXSP27W7xzdgjy1gcdrDzfjGK7X9xfN2JFwj2uk=; b=U8iTnsICf89pH3WTkLEo3YvJA9trQLOpivwXrpR8/lfsYvPlW03fs3cJAAb7hr/38t nJ/bH/pr3V5FXID4O5FVgQh0zMWhOg78AbtF5mUCMzeswgJpCRUjwBZJIRiQ1ImW0D3W mRvhWQYYfTNoEnVTd6h2K41fa181p0WAdQBb7lwWOhKkWDZn1tOdOAMDOrapUhlY9pEn dWBMPczojwTjOYGU4DBuSvITGTqyLAjOGdXXFGaFt1pz6wVMSrlapN5AOYOT+Z0NS8vS JQDygnfKwUOxk/hy2K6OIAuYCXWe5Bl5+13Uf4yneaQtOq6Egs3mtP0d57MJDco7f6uy ovOQ== X-Forwarded-Encrypted: i=1; AJvYcCUf46cKzPM+tZAvA83PCNPvKufPY19F48rssvm3qyrFE8Ibq13AcSj+4Of+y9olFQd7xVNz95w0qPUB71AFcIQZ0RM= X-Gm-Message-State: AOJu0YwDrbStaZ2ECqj69rWZP4Idf4oweAaj/8xexHK+wVn1xQ9bG0zt TbRRrYHSWcR5Ys/oU9qwZSjFf4Kah36vYUgZaPFhWoOGFMZ4BYIjxDDi/NOvnG7WVplMjhVXxof H070WLiYFYayWXTE04Lw0RGd+DrM= X-Google-Smtp-Source: AGHT+IFzmz8WoILBUQoONQ4F3W0O90FWBRmiPit92qs2VqwRYgnsWDmtrGAlcAIgOGvVUbEQ36BzA3+t0iLnDzpcCvc= X-Received: by 2002:a17:90a:b111:b0:297:bb2:b25 with SMTP id z17-20020a17090ab11100b002970bb20b25mr2130537pjq.16.1707505781473; Fri, 09 Feb 2024 11:09:41 -0800 (PST) MIME-Version: 1.0 References: <20240206220441.38311-1-alexei.starovoitov@gmail.com> <20240206220441.38311-2-alexei.starovoitov@gmail.com> In-Reply-To: From: Andrii Nakryiko Date: Fri, 9 Feb 2024 11:09:29 -0800 Message-ID: Subject: Re: [PATCH bpf-next 01/16] bpf: Allow kfuncs return 'void *' To: Alexei Starovoitov 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: DFFB0A0015 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: uq5qphirc1uxb5qt8mrfuef88b9fxsj5 X-HE-Tag: 1707505782-431033 X-HE-Meta: U2FsdGVkX1+r6CFr1+IK0y8lLErl1CmRYhR4PkVRHZIl+dDA2jLps1FQwZic5Ji5u7aCNFsXPEiKhizZFnhzXo8rBaRmiu/3Oabh1XxlRQus2P6WUTbf9QX6wg8isHBHHM9O2kmM+jXyqjGEQvnThFgvxAX/cmD2otcjI3aSQadLvat45NANNjJgWuQg4TzNiAYYlUO/PmTf/0yNWMxkjhL5Br6S7sp9nBzeka+DNJfGMUHtpn4DFXEKe98Sj8utDEos/cntjv70Xn0PiOHzP3vvFOul+LU1cpoNaIIS7FzOlaILs9+bgxzbb1wv31hiLCf1Vdn4ZQlaKU3412rVziL/RCIPU9gKW7j0h+KP50ZEx0gpS06W9kw9PWuwzlBZn1wT9+0dFRvGOXRzc3bZerqvnyA7Qem5CHqS/M8WCpFl4zwlQ9jnLz0vT9gAESQZPjizpSPmfGzgml74a4W4IQT85rhMpD9ZXCp21Fpi2zfnxtLvk9Y4ahaHeU0PwBxmVr90E/hQg9dckkcYZv/4mRYcPQFzHm8wAQauSixIlbZRDgKhZic7JvvRMJgAVFOFQeUvbmAygssuP1xnPK8OvO2h7HaJGx9mSWZU8IFiga1ZOEmvVBCJMfYZxMbXNm9FjT/Zj0GkGKQtjwPFPPBDQ/0UE3OZh7qi1PZCxvpbYqiU1Q/K68EsHwtZ3r22EFzzr9khwB6DJn1K8S8o0EoqpIoBHKxLFF0ahI3QfJ9TzYP/z2wqwkERwXbX6/KFQkxWWw+cYGF2BWO1Vggbx3gl+S0ZMjnECPUONASP9pBP0uGN6seqNLOHV3ezUAPWEwFnbMEo8KNoHrcfLN0qcmgHf9gj1PCGlifh/HEmMi8CJAHnFe92uPO1jp6MIN31iY2maqDxW4dK5W/6tZi+H9la7/EDc/4kFtMnAOc+0Xg/6Hkg/kcsaZsW8mp7muIuQf+5lDO+I4MEvaU1Wb4Wg/N kCswZegX pGhFhKhqrmABuqoPpk5cVKnluz5KJOyLBMA/u4md2n5NHf+G125UB1cypzRrTvHzhYTkEts+H16tSDlFsFiq+HcRJWwkCb5pqBIv6I6DZyFWHXmQhndkZd5uYCyriIlqJihwKc+10FsYj5lioOTTyDkSEHz73lb8CEgWpKuC8GwR9wV5SCux4KQ2iZXcybATG9QRe88yvaBqNRbZZnIA1XF53pFRCi9n7VbixdHVBwD+AjI12rw5mWhgrgyVsYiOgmRM/J2WIzcyRfiNT7qVIROk0+BulVk29tvkmgWFKs/7D6GcItcDg5he9nMgnkaAJBwErL9+4gE0ZPvrigJe6O9CIqtLltynV4DvX6Re3L9novS3HO0KtUmFBGBFh8wX/nB+ZIUu2wuCI64B7a8gMTSL06Qvt7Tqzm+iQTsn0+OSOCsMBvdVvs4ocwP/UYb4Gh8asY2ndr52ugmV7uYw3bHI5ag3p0xmCpD2LqNfpx/eSAQoyzPrhPGnqA+YCk/7rm/5AHksGM7rWhFaHJiJgFa/+OnnRVgRcsIND 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 Thu, Feb 8, 2024 at 4:09=E2=80=AFPM Alexei Starovoitov wrote: > > On Thu, Feb 8, 2024 at 11:40=E2=80=AFAM Andrii Nakryiko > wrote: > > > > On Tue, Feb 6, 2024 at 2:04=E2=80=AFPM Alexei Starovoitov > > wrote: > > > > > > From: Alexei Starovoitov > > > > > > Recognize return of 'void *' from kfunc as returning unknown scalar. > > > > > > Signed-off-by: Alexei Starovoitov > > > --- > > > kernel/bpf/verifier.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > > > index ddaf09db1175..d9c2dbb3939f 100644 > > > --- a/kernel/bpf/verifier.c > > > +++ b/kernel/bpf/verifier.c > > > @@ -12353,6 +12353,9 @@ static int check_kfunc_call(struct bpf_verifi= er_env *env, struct bpf_insn *insn, > > > meta.func_name); > > > return -EFAULT; > > > } > > > + } else if (btf_type_is_void(ptr_type)) { > > > + /* kfunc returning 'void *' is equivalent to = returning scalar */ > > > + mark_reg_unknown(env, regs, BPF_REG_0); > > > > Acked-by: Andrii Nakryiko > > > > I think we should do a similar extension when passing `void *` into > > global funcs. It's best to treat it as SCALAR instead of rejecting it > > because we can't calculate the size. Currently users in practice just > > have to define it as `uintptr_t` and then cast (or create static > > wrappers doing the casting). Anyways, my point is that it makes sense > > to treat `void *` as non-pointer. > > Makes sense. Will add it to my todo list. > > On that note I've been thinking how to get rid of __arg_arena > that I'm adding in this series. > > How about the following algorithm? > do_check_main() sees that scalar or ptr_to_arena is passed > into global subprog that has BTF 'struct foo *' > and today would require ptr_to_mem. > Instead of rejecting the prog the verifier would override > (only once and in one direction) > that arg of that global func from ptr_to_mem into scalar. > And will proceed as usual. > do_check_common() of that global subprog will pick up scalar > for that arg, since args are cached. > And verification will proceed successfully without special __arg_arena > . Can we pass PTR_TO_MEM (e.g., map value pointer) to something that is expecting PTR_TO_ARENA? Because there are few problems with the above algorithm, I think. First, this check won't be just in do_check_main(), the same global function can be called from another function. And second, what if you have the first few calls that pass PTR_TO_MEM. Verifier sees that, allows it, assumes global func will take PTR_TO_MEM. Then we get to a call that passes PTR_TO_ARENA or scalar, we change the argument expectation to be __arg_arena-like and subsequent checks will assume arena stuff. But the first few calls already assumed correctness based on PTR_TO_MEM. In short, it seems like this introduces more subtleness and potentially unexpected interactions. I don't really see explicit __arg_arena as a bad thing, I find that explicit annotations for "special things" help in practice as they bring specialness into attention. And also allow people to ask/google more specific questions.