Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp10456pxb; Tue, 12 Jan 2021 18:23:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJwkdIIBv0wbPr1mYQe0Yqi6qmrOLwZk+nWGIa6gWZmuC9vxkOXe9KkOUqYR5TxsdNGQe5+P X-Received: by 2002:a50:fb85:: with SMTP id e5mr1598915edq.153.1610504595507; Tue, 12 Jan 2021 18:23:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610504595; cv=none; d=google.com; s=arc-20160816; b=RGH5QPHj3WbVprKkIf9IQhX0FGBddNfXhUW3I/M6dNafMeREWj8gCcW08deUQerxAg e/Je8k1MnveKeT1cFkXqrnVz4OW94dTPOBAroglHFWfc3SICDfwlTGGjAMmaza6S4uZE oNn/EMDXA0A8bn234s1KPeao0xUyGNEkV5Fhj3wUMbxyHMYW2+hfywri8H1shFR+hite cOY5Zoqs0SFk73jT5p1GHxiUgVtmjRlYa5JRXSYZ4jEuWzC1crosPxidau9eP2/iJ0uu LfQ3wkXxY5QR9SZ1rnWD56UkPyGV/9iGvuYNCfQdhhivz7T+DKfJUHjtyTADlJcadq64 XGoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=d2tvB8L4ukV5eiLmhra8tQf6n0L3OOx6LccTNawLkQ8=; b=WjQY362VOpooFpsbleh47wdq/xnWZ/jogO++YRZvniKVSQMlK9ugMK1b6+2huzS8fF Qj459kboyGcdDWIUhVY3X2qlgTOYp/lxaw1BAco/8GNmyZFoDWPupBSyrTDRq01jG8fZ OgYBCQ2Ikeh0/XwDqaJA6ygAvE55Th2vLlNZC6GUiuaGbdlGygweC3Uus2B9ltYrupGd sRMe9jJWrAtPkzg3TWF6wljo+qAOSsaWnlonZ9IznHrRpC9lEzq9382GZgRM1R2VAtyJ Me4dhjDhLtNu7IdDmUXhc97kN5u3OpAD15SL8OPx4FhNngorF0W4EzHx7KvHgb0cmiog 2l1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=dC4KpxGN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m13si338691edi.155.2021.01.12.18.22.52; Tue, 12 Jan 2021 18:23:15 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=dC4KpxGN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405518AbhALQyA (ORCPT + 99 others); Tue, 12 Jan 2021 11:54:00 -0500 Received: from mail.kernel.org ([198.145.29.99]:43206 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405515AbhALQyA (ORCPT ); Tue, 12 Jan 2021 11:54:00 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id D86D22312E for ; Tue, 12 Jan 2021 16:53:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610470399; bh=QD1QJEfLDth6VGUjNynnB2WirA8KnKteRRZBlSzAYQQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=dC4KpxGNTjgHWv6D/zGJS03x5DTdOmLutnM9zThNp1p5Giv42ldU5wInwlBeQQ/tW h9byiy4KvPw3TE0Tjqv4GJydJB+eB0huzKK+jprtlO2yH14/g3nubKGO91UfYKriZi EjgkYOybfVNMHJ6yX2r+L8q6/aNqMWzU+YrJkkrk49sj22JGKoIa4OCfJlJGySHalx nb4KTo52OKv+Wz76NBzz1lR6ZABQZeWm7Z02Tl8kBLLLbHecO9sVQsLI5qoJL/D43h LwPuyinJV39WsvPJghAYaTPqpMiBjchkRzT00YDwPuWa+LXz1iQDhcDxz9dtkCAE5r O4ah3TkWlyhvw== Received: by mail-lf1-f51.google.com with SMTP id x20so4338435lfe.12 for ; Tue, 12 Jan 2021 08:53:18 -0800 (PST) X-Gm-Message-State: AOAM531HVERibVBE2RPuS+yx0jf2i6f2LnD01ecA5lmIubNcpOWCWsU4 tiCl/dU8cVBxvwEufqrAuLC5Ij9YcEbO72OP7ldkEw== X-Received: by 2002:a19:cbd8:: with SMTP id b207mr2602394lfg.550.1610470396912; Tue, 12 Jan 2021 08:53:16 -0800 (PST) MIME-Version: 1.0 References: <20210108231950.3844417-1-songliubraving@fb.com> <20210108231950.3844417-2-songliubraving@fb.com> <20210111185650.hsvfpoqmqc2mj7ci@kafai-mbp.dhcp.thefacebook.com> <20210111215820.t4z4g4cv66j7piio@kafai-mbp.dhcp.thefacebook.com> <9FF8CA8D-2D52-4120-99A5-86A68704BF4C@fb.com> In-Reply-To: From: KP Singh Date: Tue, 12 Jan 2021 17:53:06 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH bpf-next 1/4] bpf: enable task local storage for tracing programs To: Yonghong Song Cc: Song Liu , Martin Lau , bpf , Networking , open list , "mingo@redhat.com" , Peter Zijlstra , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , John Fastabend , Kernel Team , Hao Luo , kernel test robot Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 12, 2021 at 5:32 PM Yonghong Song wrote: > > > > On 1/11/21 3:45 PM, Song Liu wrote: > > > > > >> On Jan 11, 2021, at 1:58 PM, Martin Lau wrote: > >> > >> On Mon, Jan 11, 2021 at 10:35:43PM +0100, KP Singh wrote: > >>> On Mon, Jan 11, 2021 at 7:57 PM Martin KaFai Lau wrote: > >>>> > >>>> On Fri, Jan 08, 2021 at 03:19:47PM -0800, Song Liu wrote: > >>>> > >>>> [ ... ] > >>>> > >>>>> diff --git a/kernel/bpf/bpf_local_storage.c b/kernel/bpf/bpf_local_storage.c > >>>>> index dd5aedee99e73..9bd47ad2b26f1 100644 > >>>>> --- a/kernel/bpf/bpf_local_storage.c > >>>>> +++ b/kernel/bpf/bpf_local_storage.c [...] > >>>>> +#include > >>>>> > >>>>> #include > >>>>> #include > >>>>> @@ -734,6 +735,7 @@ void __put_task_struct(struct task_struct *tsk) > >>>>> cgroup_free(tsk); > >>>>> task_numa_free(tsk, true); > >>>>> security_task_free(tsk); > >>>>> + bpf_task_storage_free(tsk); > >>>>> exit_creds(tsk); > >>>> If exit_creds() is traced by a bpf and this bpf is doing > >>>> bpf_task_storage_get(..., BPF_LOCAL_STORAGE_GET_F_CREATE), > >>>> new task storage will be created after bpf_task_storage_free(). > >>>> > >>>> I recalled there was an earlier discussion with KP and KP mentioned > >>>> BPF_LSM will not be called with a task that is going away. > >>>> It seems enabling bpf task storage in bpf tracing will break > >>>> this assumption and needs to be addressed? > >>> > >>> For tracing programs, I think we will need an allow list where > >>> task local storage can be used. > >> Instead of whitelist, can refcount_inc_not_zero(&tsk->usage) be used? > > > > I think we can put refcount_inc_not_zero() in bpf_task_storage_get, like: > > > > diff --git i/kernel/bpf/bpf_task_storage.c w/kernel/bpf/bpf_task_storage.c > > index f654b56907b69..93d01b0a010e6 100644 > > --- i/kernel/bpf/bpf_task_storage.c > > +++ w/kernel/bpf/bpf_task_storage.c > > @@ -216,6 +216,9 @@ BPF_CALL_4(bpf_task_storage_get, struct bpf_map *, map, struct task_struct *, > > * by an RCU read-side critical section. > > */ > > if (flags & BPF_LOCAL_STORAGE_GET_F_CREATE) { > > + if (!refcount_inc_not_zero(&task->usage)) > > + return -EBUSY; > > + > > sdata = bpf_local_storage_update( > > task, (struct bpf_local_storage_map *)map, value, > > BPF_NOEXIST); > > > > But where shall we add the refcount_dec()? IIUC, we cannot add it to > > __put_task_struct(). > > Maybe put_task_struct()? Yeah, something like, or if you find a more elegant alternative :) --- a/include/linux/sched/task.h +++ b/include/linux/sched/task.h @@ -107,13 +107,20 @@ extern void __put_task_struct(struct task_struct *t); static inline void put_task_struct(struct task_struct *t) { - if (refcount_dec_and_test(&t->usage)) + + if (rcu_access_pointer(t->bpf_storage)) { + if (refcount_sub_and_test(2, &t->usage)) + __put_task_struct(t); + } else if (refcount_dec_and_test(&t->usage)) __put_task_struct(t); } static inline void put_task_struct_many(struct task_struct *t, int nr) { - if (refcount_sub_and_test(nr, &t->usage)) + if (rcu_access_pointer(t->bpf_storage)) { + if (refcount_sub_and_test(nr + 1, &t->usage)) + __put_task_struct(t); + } else if (refcount_sub_and_test(nr, &t->usage)) __put_task_struct(t); } I may be missing something but shouldn't bpf_storage be an __rcu member like we have for sk_bpf_storage? #ifdef CONFIG_BPF_SYSCALL struct bpf_local_storage __rcu *sk_bpf_storage; #endif > > > Thanks, > > Song > >