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 1C784C43334 for ; Mon, 11 Jul 2022 06:49:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4E6928E0001; Mon, 11 Jul 2022 02:49:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 496786B0073; Mon, 11 Jul 2022 02:49:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3859F8E0001; Mon, 11 Jul 2022 02:49:20 -0400 (EDT) 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 2A1106B0072 for ; Mon, 11 Jul 2022 02:49:20 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E0ED3B2C for ; Mon, 11 Jul 2022 06:49:19 +0000 (UTC) X-FDA: 79673892438.29.5214B23 Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) by imf21.hostedemail.com (Postfix) with ESMTP id 696581C006B for ; Mon, 11 Jul 2022 06:49:19 +0000 (UTC) Received: by mail-vs1-f41.google.com with SMTP id 189so4103841vsh.2 for ; Sun, 10 Jul 2022 23:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HM30YiM9pQyDXmYdcEyIYm/O7MQh9WDuXiJXjN1Po/c=; b=kOB5AXL+FfElHAGeNd+SHXoky92ZmYO7DpVDBUcARq56dLUyoFpy/ZtwZ5WfH7k4uy Tjb12A22uXbe7ouWzLC4LrlHRv4AJwciWp8enMbbXF4BpZiqkcYZYeJkPbimiqE2WaVC PC0MMgcxEuoIlRZmbwJFYwgW6JwG3L5ogdC95zt1leBtB+YS676RCbfCqAak8GjfCJ3H k6GSn0vyO16SFntjo7RsecYS6A/4QYbM6yx5+9zkwGCMmabhnbPRW1TmbWbHakHsUo8o YzJ5GLQE2gKx6aoxROtrM9t5LMKvk0/wzlVfhSNO01OO6CXP7hu/sb0cE04dW3qAdJEC wJxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HM30YiM9pQyDXmYdcEyIYm/O7MQh9WDuXiJXjN1Po/c=; b=ON306NIPNmRm8rIZFU9IyEVCgOROg255rqbVGQO9WlI8KdoHZYDtnfKAigAnC2X9wH NjIi77Maosg2v177EciszQOikNwZ8fMkPD9gxIdkr0njCfDX6JrssvdTtQCxig3o2/Db 2wcWYWzgNG6xCxfwpaMG0pizz6JbJVeMDqxk2D18NaM0rAxGSWNFO6gJUPfYkWqs/P7s 8CyXHLfinvK+oqn7dvOXIwIQ8KMGHYiMiKaMjcF1Vsz8nyD1D1FsYFGE/JRVANl+V5ja mdK03OnX1SeiNU37mfUW6r0RifdTXOTRoVvRqZjR3HWxeWNMACJ78K2rBC3Xrci0t953 z0SQ== X-Gm-Message-State: AJIora+w0I4EI9QnhMDbUPELWMIx1YdgYKR5jd6F0pN7ynFpIAdRPupG eEpn6TMS0RJ7FNl5JwTkt6KW+2hs9B01E3Pbmd0= X-Google-Smtp-Source: AGRyM1tetmQuMCf339/rDXTiJF/6uxrGBJ8TjG8IHt1tFgKBAWSsPbWi+EdTHRTuJM8A8E4w6yKMw7D93DUgX6kRvD4= X-Received: by 2002:a67:af11:0:b0:357:5b18:d7b9 with SMTP id v17-20020a67af11000000b003575b18d7b9mr1253200vsl.35.1657522158605; Sun, 10 Jul 2022 23:49:18 -0700 (PDT) MIME-Version: 1.0 References: <20220709154457.57379-1-laoar.shao@gmail.com> <20220709154457.57379-3-laoar.shao@gmail.com> <05e5931e-98a7-d7b4-4775-7c17fad57450@fb.com> In-Reply-To: <05e5931e-98a7-d7b4-4775-7c17fad57450@fb.com> From: Yafang Shao Date: Mon, 11 Jul 2022 14:48:42 +0800 Message-ID: Subject: Re: [PATCH bpf-next v3 2/2] bpf: Warn on non-preallocated case for missed trace types To: Yonghong Song Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin Lau , Song Liu , john fastabend , KP Singh , Quentin Monnet , Roman Gushchin , Hao Luo , Shakeel Butt , bpf , Linux MM Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=kOB5AXL+; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.217.41 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657522159; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=HM30YiM9pQyDXmYdcEyIYm/O7MQh9WDuXiJXjN1Po/c=; b=aZFgpfggBi1f/FoCJLFBtausI1dP/0rS+8m983EuTvqjd/+9XHdtjJng24RZcjqRE43ren 0NxoFqTuahlAX+uJAeTcB7sBkmkgVRX+VqOZA442HY8AWjFeqNBGgooyMd79WUamg9LUpp /JnJXBmQZm9ZHjUjtbILwp/Z2MHkY+M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657522159; a=rsa-sha256; cv=none; b=H7rB8wBKE0bipSoYcJJ6KPXM5G/nVLbNqgKOoJtqbar5PFCAEgK4VUaGPYmH96DMwFCpLJ LRqX84mkYrJZ772vz+TuaWTVfmy0TvO39JFzln6PpncvJTimWyNZkoA9GnzORQePEvnnsi h64HHaWnku9i46UM9amydRvKvLL3Bn4= X-Stat-Signature: 4651mn9xgez4k1sey1ji588dpxne9agx X-Rspamd-Queue-Id: 696581C006B Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=kOB5AXL+; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.217.41 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1657522159-178664 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: On Mon, Jul 11, 2022 at 1:51 AM Yonghong Song wrote: > > > > On 7/9/22 8:44 AM, Yafang Shao wrote: > > The raw tracepoint may cause unexpected memory allocation if we set > > BPF_F_NO_PREALLOC. So let's warn on it. > > Please extend raw_tracepoint to other attach types which > may cause runtime map allocations. > Per my understanding, it is safe to allocate memory in a non-process context as long as we don't allow blocking it. So this issue doesn't matter with whether it causes runtime map allocations or not, while it really matters with the tracepoint or kprobe. Regarding the tracepoint or kprobe, if we don't use non-preallocated maps, it may allocate other extra memory besides the map element itself. I have verified that it is safe to use non-preallocated maps in BPF_TRACE_ITER or BPF_TRACE_FENTRY. So filtering out BPF_TRACE_RAW_TP only is enough. > > > > Signed-off-by: Yafang Shao > > --- > > kernel/bpf/verifier.c | 18 +++++++++++++----- > > 1 file changed, 13 insertions(+), 5 deletions(-) > > > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > > index e3cf6194c24f..3cd8260827e0 100644 > > --- a/kernel/bpf/verifier.c > > +++ b/kernel/bpf/verifier.c > > @@ -12574,14 +12574,20 @@ static int check_map_prealloc(struct bpf_map *map) > > !(map->map_flags & BPF_F_NO_PREALLOC); > > } > > > > -static bool is_tracing_prog_type(enum bpf_prog_type type) > > +static bool is_tracing_prog_type(enum bpf_prog_type prog_type, > > + enum bpf_attach_type attach_type) > > { > > - switch (type) { > > + switch (prog_type) { > > case BPF_PROG_TYPE_KPROBE: > > case BPF_PROG_TYPE_TRACEPOINT: > > case BPF_PROG_TYPE_PERF_EVENT: > > case BPF_PROG_TYPE_RAW_TRACEPOINT: > > + case BPF_PROG_TYPE_RAW_TRACEPOINT_WRITABLE: > > return true; > > + case BPF_PROG_TYPE_TRACING: > > + if (attach_type == BPF_TRACE_RAW_TP) > > + return true; > > As Alexei mentioned earlier, here we should have > if (attach_type != BPF_TRACE_ITER) > return true; That will break selftests/bpf/progs/timer.c, because it uses timer in fentry. > For attach types with BPF_PROG_TYPE_TRACING programs, > BPF_TRACE_ITER attach type can only appear in process context. > All other attach types may appear in non-process context. > Thanks for the explanation. > > + return false; > > default: > > return false; > > } > > @@ -12601,7 +12607,9 @@ static int check_map_prog_compatibility(struct bpf_verifier_env *env, > > struct bpf_prog *prog) > > > > { > > + enum bpf_attach_type attach_type = prog->expected_attach_type; > > enum bpf_prog_type prog_type = resolve_prog_type(prog); > > + > [...] -- Regards Yafang